✨ 221209 Today I Learned ✨

오늘 한 일

---

1. BE: 알람 기능 구현 마무리
2. FE: 담당 페이지(어쩌다보니 알람 때문에 얼레벌레 맡게 되었다) 데이터 및 기능 연동 마무리
3. FE: 덧글 기능 비동기로 바꿔서 구현
4. → 비동기로 만드는 법은 알고 있었는데 반쪽짜리로 알고 있었던지라 새로고침 안 되고 어떻게 데이터를 화면에 띄우는지까지는 몰랐는데 생각보다 되게 간단했다. 단순히 저장하고 난 직후에 데이터 불러오는 함수를 다시 실행하되, 그렇게 하면 전체 데이터가 다시 붙기 때문에 이전에 뿌려놨던 데이터를 공백 처리하는 방식이었다. 알자마자 바로 알람에도 적용해서 잘 써먹었다.

channels를 활용한 알람 기능 (뿌듯☺️)

---

누군가에겐 별 거 아닐 수 있지만 내게는 너무 뿌듯한 기능 구현 오늘도 하나 생겼다~~예에

각기 다른 브라우저에서 로그인 한 뒤 실시간으로 알람 뜨는지까지 테스트했는데 잘 됐다.

• 결국 실질적 구현에 들어간 첫 날 작성한 코드가 맞았다. 하하하ㅏㅏㅏㅏㅏㅏ
• 애증의 daphne… 하하 gunicorn을 대체한댔나… 얘만 없어썽도 진즉에 수요일에 기능 구현 끝나지 않았을까? 하하하 공식문서가 짱짱이다 ㄹㅇ 이제 그 어떤 말도 공식문서보다 우선해서 듣지 않을 거다. 뼈아픈 교훈 하나 얻었다 그래도 👍🏼 솔직히 누굴 탓해 결국 선택은 내가 했는데 ㅇㅅㅇ 남탓 존나 다 자기합리화지
• 그래도 여전히 아쉬운 맘에 드는 생각이 있다면, 공부 끝내고 하루이틀이면 구현했을 기능에 사소한 것들로 인해 너무 많은 시간을 쏟은 게 아닐까 하는 생각. 다른 프로젝트도 아니고 하필 최종 프로젝트 때… 여태 했던 것 중 가장 오래 걸리고 어이없는 실수가 생기다니. 이거 때문에 떨어진 기여도도 기여도인데, 프로젝트에 도움을 덜 준 거 같아 팀원들에게 미안한 맘이 크다. 초반에 라이브쉐어로 코드 몇 번 같이 짠 거랑 내 커밋 말고는 흠… 하ㅏㅏ
• 채팅이랑 알람 어차피 원리 똑같아 보이는데 알람을 더 일찍 완성했더라면 채팅도 만들 수 있지 않았었을까 하는 아쉬움도 크다. 내가 구글링을 잘 못했던 건지 채팅 자료는 넘쳐나는데 알람 자료는 찾기가 너무 힘들었다. 그래도 공부할 때 공식문서를 통해 공부한 덕에 기본적인 기능을 구현한 이후에는 처음 생각한 로직과 다른 걸 수정하고, 이것저것 디테일한 걸 수정하는 과정에서 에러가 단 한 번도 나질 않았다. 뿌—듯.

처음에는 채팅방에 한 명만 밀어넣으면 그게 알람이지! 싶어서 한 명만 넣는다는 게 덧글 작성한 본인을 넣어버려서 본인 덧글 알람이 본인에게 뜨는 상황이 생겼다. 그걸 구현하고 깨달아서 db에 저장할 때 author에 작성자 본인이 아닌 후기 작성자의 id가 저장되게 했고, 이렇게 수정하고 나니 이것저것 디테일하게 손봐야 할 게 눈에 보여서(is_seen도 원래는 없던 필드였다) 싹 다 고치고 프론트도 그에 맞춰서 기능이랑 데이터 연동해놨다. 사진에도 있지만 크게 아래와 같이 수정했다.

1. db에 저장할 때 author에 작성자 본인이 아닌 후기 작성자의 id 저장 (author와 같은 아이디를 가진 사람에게만 알람을 띄움)
2. → 처음에 백엔드에서만 비벼보려다가 아이디가 있는 유저 테이블과 닉네임이 있는 프로필 테이블이 분리돼 있고, 백엔드에서 프론트로 넘겨주는 response를 활용하기 위해 코드 위치를 바꾸면 웹소켓 연결이 끊기는 상황이라(self.scope[”user”]로는 [아이디]lgb밖에는 ^^심지어 쟤는 후기 작성자 것도 아니고 로그인한 사용자 거…) 도저히 안 될 거 같아서 좀 헤매다가 어촤퓌 사용자의 id는(username말고 pk값인 그 id) 별로 중요한 정보가 아니니까 그냥 쿼리 스트링 써서 프론트에서 channels로 메시지 보낼 때 같이 보내버렸다. 이런 방식으로 로그인한 사용자의 아이디도 넘겼다.
3. 아직 읽음 처리되지 않은 알람만 띄우기
4. 본인이 작성한 게시글에 본인이 덧글을 달 때는 알람 띄우지 않도록 수정(애초에 db에 저장 X)
5. 프론트에서 실시간으로 띄웠었는데 백엔드랑 연동하면 두 번 띄우게 될 거 같아서 적절하게 수정해놨다. 어차피 전자는 일회성이라서… 사용자가 읽지 않은 알람을 계속 띄우려면 바꾸긴 해야 했다.
6. → 아직 읽음 처리되지 않은 알람을 기록을 남기고 읽음 처리되기 전까지 띄우고 싶어서 그대로 짜다가, 아니 이러면 channels를 굳이 쓸 필요가 있었나 똑같이 버튼 누르면 db 저장하게 하고 get으로 불러와서 띄우고 확인 버튼에 put방식으로 요청 넣으면 되지 않나 싶었는데, 아니나 다를까 튜터님 두 분 다 channels는 실시간이라 어쩔 도리가 없다고 말씀하셨다… 다만 본인이 본인 게시글에 덧글을 다는 경우가 아니라 다른 사람이 내 게시글에 댓글을 달 때도 알람이 실시간으로 온다는 거에 channels를 이용한 비동기의 의의가 있다고.
7. 읽음 처리 기능 추가

---

1. 알람은 비동기인데 덧글 지 혼자 동기로 돌아가서 아귀가 안 맞길래 덧글도 비동기로 수정했다.
2. 사실 백엔드 쪽이랑 거의 비슷한 얘기인데 백엔드에서 구현한 거 프론트에서도 되게 해놨다. 그래서 자세히는 안 적겠다.

구현하며 힘들었던 것

---

매일 TIL과 별개로 다이어리에 일기랑 하루 기록, 계획 등을 적는데 저저번 프로젝트 때부터 처음에 쓴 코드가 정답 → 이상한 걸로 시간 끎 → 계속 틀린 코드로 고치고 고치다 에러 이유 발견해 냄 → 그거 해결하고 처음 코드로 되돌림의 반복이 많다. 이번에 channels로 알람 기능 구현하는 게 역대급을 찍은 거고… 한 번 그렇게 빡세게 하고 나면 그 이후에 에러가 잘 안 나서 좋긴 한데… 꼭 프젝 때 그래야겠니 🤦🏻‍♀️