참고)
article은 따로 테이블을 만들지 않고 comment에 넣어두었다.
comment별로 좋아요 기능만 구현하려고 한다.
comment는 각각의 작성한 author가 있다. 한명의 작성자가 여러 댓글을 가지고 있는 구조다.
comments table을 기준으로 해서 위의 모델과 같이 생각하면 왼쪽 products table에 해당한다.
중간에 likes table을 두고 첫번째 필드를 commentId로 두고 두번째 필드에 userId를 둔다.
오른쪽은 users table을 연결한다.
모든 댓글(제품)과 사용자 간의 좋아요를 추적할 수 있는 방법으로, 사용자와 댓글(제품) 간의 관계를 나타내는 새로운 모델이 likes table이 되는 것이다.
각 댓글은 많은 사용자가 좋아할 수 있으므로 하나의 userId가 모든 사용자를 추적할 수 없으며, 사용자가 여러 제품을 좋아할 수 있기 때문에 하나의 commnetId를 사용자에게 추가할수도 없다. 따라서 many to many relation으로 만든다.
단순하고 직관적인 스타일의 버튼으로 우선 만든다.
좋아요 버튼을 누르는데 귀찮지 않도록 만든다!
나중에 수정가능
색상 고려 : #33c9dc (하늘색), #e57373'(흐릿한 빨강), #ff3e4eab'(좀더 진한 빨강)
오른쪽에 버튼을 배열하기로 결정
GET public
POST authenticated user
/api/likes
create api를 만들기 위해 authorization header를 지정한다. Bearer를 앞에 붙여주는 거 잊지말자.
403이므로 create 권한을 추가해준다.
이제 생성된 Comment id 2와 User id 1 간의 관계를 delete하는 api를 만든다.
many to many relation으로 지정해주었기 때문에 기존처럼 user나 comment가 아니라 users, comment에 할당해주어야 한다!
여기서 comment id를 넘겨주고 헤더의 jwt 토큰으로 유저의 id를 넘겨주지만 기본적으로
delete는 쿼리 스트링으로 delete할 likes의 id를 요구합니다.
따라서 405에러가 발생합니다.
하지만 likes의 id를 일일이 다 기억하면서 처리하는 방식으로 하는 게 좋아보이지 않아서 POST 메서드만으로 내부적으로 처리하도록 방향을 바꾸었다.
추후 더 나은 방식으로 교체할 생각으로 구현했다.
기존에 userData를 백엔드에서 처리했던 것을 모두 body에 담아서 넣는 방식으로 변경하자.
굳이 서버에 변경 사항을 추가하지 않는 편이 낫다. 정석적인 방법으로 해결하자. 어차피 userData 내에 id를 가지고 있어서 보내는 데 문제가 되지 않는다.,.
한번 post요청으로 생성해버린 다음 다시 한번 생성 요청을 보낼 시 404가 뜬다.(오타 조심)
이렇게 코드를 짜면 post요청이 해당 데이터가 있는지 확인 후 지워주는 작업도 해준다.
이를 통해 지워준 경우를 구별하는 응답을 줘야겠다는 생각이 들었다.
테스트
post 요청 후 12가 생성되었다.
post요청을 다시 보내자 unlike가 정상적으로 반환된다.
id 12번 like도 정상적으로 삭제되어 있다.
이렇게 릴레이션이 연결되면 다른 데이터를 요청했을 때 거기서 like라는 데이터도 연결되어 접근해볼 수 있다.
이 경우 comments는 윌라~~~이고, users는 coa로 되어 있다.
comments 윌라 ~~를 확인해보자.
제목이 겹치긴 하지만 likes가 정상적으로 늘어난 것을 볼 수 있다.
이제 users coa를 확인해보자 likes를 가지고 있을까?
드롭다운을 눌러보면 likes가 13번 아이템인 것까지 알려준다. 잘 연결되어 있음을 확인했다.
이제 프론트엔드를 구현한다.
65에서 캐싱되어있는 데이터의 원본 형태를 볼 수 있다.
여기에 미리 변경시켜준다.
변경되었을 때의 형태는 맨 아래와 같아야 한다.
