-
Notifications
You must be signed in to change notification settings - Fork 3
2020 11 26 데일리 스크럼
Kwon soon won edited this page Nov 26, 2020
·
1 revision
- 쓰레드 불러와서 뿌려주는것 구현 (saga 써서!)
- 프론트 + 백엔드 api
- 컨디션 굿
- 로그인 관련 기능 구현
- access token 블랙리스트 제거
- 로그인 유지 기능 구현
- 로그인, 로그아웃에서 사가 로직 디테일하게 작성
- custom hook 생성
- redis 가..?
- 채널 불러와서 화면에 뿌려주는것 구현
- 채널 토글 기능
- hover
- clicked된 채널 표시
- div를 react를 사용할때 onClick을 쓰면 lint가 뜬다 -> 해결
- 이따 3시 멘토님과 미팅
- (순원) 리펙토링 해서 PR 날리겠습니다
- (순원) 쓰레드 지금 그냥 thread 테이블 값만 가져오는데, FK 애들 가져와서 뿌려줄 수 있도록 쿼리 작성
- (순원) 약간의 CSS 첨가
- (현준)
- 로그인 페이지 디자인 넣기
- 헤더 만들기
- 유저 프로필 표시
- 유저 프로필 수정
- (상욱)
- 채널 추가 기능 만들기(서버와 클라이언트 포함)
- 채널 쿼리 작성
- 사가/썽크 둘 다 request/success/fail 같은 액션이 생길수 밖에 없지않는가
- 썽크는 저런 액션들을 단위단위로 만들어서 쓰진 않는다.
- 썽크 특성상 dispatch를 actioncreate로 바로 받아서
- 액션 이후에 콜백을 받고 싶을때, A라는 이벤트를 발생시키고 그 A라는 이벤트에서 B가 발생되고 그 결과값을 처리해야하는 그런 케이스.
- userInfo를 local storage에 저장해도 좋을까? 어차피 토큰도 암호화 안된건 마찬가지니까?
- 서버에 전화번호도 그냥 저장하면 안됩니다
-
emoji json으로 어떻게 넣는게 좋을까요? 계속 고민하다보니 결국 mongoDB를 쓰는것과 같아지는 느낌인데
-
이모지 목표
- 클릭을 하면 사용자 리스트가 보여야함
- 사용자 정보가 변경이 되면, 이모지에 반영되어야함
- 동일한 사용자가 클릭 하면, 이모지에서
-
그래서 이걸 JSON으로 하려니 너무 복잡해서 다시 테이블로 만들어 연결하려고 합니다.
-
3가지 선택지
- JSON으로 넣고 관리
- N대 N
- 아예 몽고디비로 넘어간다
-
그리고 이런 경우에는, subthread의 이모지 까지 전부 갖고와서 있는게 좋을까요? 아니면 reply를 들어갈때 가져오는게 좋을까요? thread 목록에서 reply 정보를 보여주기때문에 다 가져오는게 좋을것 같긴 한데.
- 확인해보니 실제 슬랙은 replay-info 같은걸 thread에서 가져와서 보여주고, reply를 클릭했을때 sub-thread를 보여주는 식으로 동작해요
-
아래처럼 연결해야됨
- 근데 사이사이에 n:n 테이블 필드도 들어감.😨
=> 백엔드 설계할때 프론트꺼도 보면서, 이 api는 이미 정보가 가서 있겠구나 하는것들을 고려해서 구현하는게 좋다.
{
threadList:[
{
thread_id: 0,
content: '',
subthread: [
{
thread_id: 1,
content: ''
}
]
emojis:[
{
emoji_id: 0,
emoji_url: 'url~~',
users: [
{
user_id: 0,
nickname: 'a'
},
{
user_id: 1
nickname: 'b'
}
]
},
]
},
{
}, ...
]
}
setTimeout을 써서 만료
JWT를 쓰는 이유?
- 일반토큰을 쓰는것과 뭐가 다를까
- 유저 정보를 확인할때
- 만료시간을 체크할때
- interceptor request에서
접속 실패 (alert), timeout으로인해 요청 실패(다시 보내는 것 retry : 보통 사가로직으로 처리하진 않고, axios에서 처리)