D'story

오늘 한 일

• 오늘 하루 일과 시작과 함께 어제 밤늦게 날린 PR에 리뷰가 달렸다. 어차피 통신하는 서버 url은 고정이고, 거기에 withCredentials 설정도 기본으로 넣어놓는 게 좋겠다는 말씀이었다. axios는 http 통신을 처음 접했을 때부터 알았지만 이렇게 다시 공식문서를 보게 되니 한편으로는 반갑고 또 한편으로는 새로웠다.
• 미로 챗에서 API 문서화 관련한 세훈님의 설명을 들었다. 나는 전후 상황은 잘 모르지만 단편적으로나마 들은 단어들 검색해서 찾아보기도 하고미로 보드에 있는 내용들을 살펴보기도 하고, 재밌는 시간이었다.
• 언제부터였는지는 모르겠지만 얼마 전에 알아챈 거였는데, 이상하게 vscode에 깔아놓은 GitLens extension을 통해서 에디터 내에서 커밋 데이터를 띄우면 author의 프로필 사진으로 왠지 모르게 소름 끼치는 로봇이 나왔다. 다른 사람 로봇은 좀 괜찮은데 유독 나는 더욱 더... 꿈에 나오면 그게 바로 악몽... 며칠 전에도 구글링 하다 하다 포기했었는데 오늘 갑자기 너무 꼴보기가 싫어서 다시 찾아봤다. 다행히 금방 찾았다! vscode Settings에 들어가서 GitLens: Default Gravatars Style을 robohash(default)가 아닌 걸로 바꾸면 일단 그놈의 로봇은 안 나온다ㅠㅠfreedom...
• 로봇을 처치하고 나니 또 욕심이 생겼다. 나는 왜 깃헙 프로필 사진이 안 나오지? 없는 것도 아닌데? 그래서 찾다가 무심코 눌러본 버튼이 곧 해결책이었다. GitLens 커밋 데이터가 나오는 창 하단의 Connect to Github(?한번 연결하고 나니 이 버튼이 다시 안 떠서 문구가 정확히 이건지는 모르겠다..) 버튼을 누르면 깃헙으로 연결되면서 정상적으로 모두의 프로필 사진을 볼 수 있다.
• 로그인 페이지에서 특정 버튼을 누르면 dialog를 띄워야 해서 결국 vuetify를 깔았다. vue add vuetify 명령어를 입력하면 vue create와 비슷하게 설치 옵션을 선택할 수 있는데, 거기서 무심코 default(recommended)를 선택한 나는 App.vue를 비롯한 여러 파일들이 제멋대로 엎어지는 것을 목격했다. 이 파일 저 파일 열심히 수정하다가 차라리 예전으로 되돌아가서 다른 방법을 찾아보라는 상현님의 말에 힌트를 얻어 git stash를 해두고 다시 설치를 시도했다. configure(advanced)를 선택하면 될 일이었다. 허무

오늘 배운 것

• 메인 브랜치 git pull은 브랜치 컬러가 초록색일 때 하자
• 잊어버릴 때쯤 한 번씩 보게 되는 axios 공식문서

오늘 한 일

• 어제, 로그인 시도하면 자동으로 새로운 페이지로 리다이렉트 되어야 하는데 그게 안 되고 끝났었다.
• 그걸 해결하시는 과정에서 승진님이 전체적인 플로우를 바꾸셨고, 오늘 출근했을 때는 이미 내 코드에서도 그 부분을 고쳐주신 상태였기 때문에 나는 사실상 플로우 변화에 큰 영향을 받지 않은 거나 다름없었다. 다시 그려주신 다이어그램과 수정해주신 코드를 하나씩 비교하면서 실행해보니 이해하는 데 큰 어려움은 없었다.
• 변경된 플로우에 맞춰 그 외 다른 코드들을 조금씩 변경한 후에는 다시 로컬에서 뷰로 동일한 내용의 작업을 진행했다. 언제 리액트랑 바꿔치기 해야 될지 알 수 없으니 미리미리...!

오늘 배운 것

• 서버가 응답 헤더에 쿠키를 넣어서 보내주려면, 앞단에서는 그 직전 요청에 withCredentials 옵션을 보내줘야 한다. axios를 쓰는 경우로 예를 들면 이렇다. 헤더에 따로 넣을 필요 없이 config 부분에 그냥 바로 넣어주면 된다.

axios.post('http://server.url', {body_key: body_value}, {withCredentials: true});

• 아래 링크에 따르면 서버쪽에서도 쿠키를 넣을 때 헤더에 Access-Control-Allow-Credentials 옵션을 함께 넣어줘야 한단다. 그러면 헤더에 쿠키가 실려온다. 이후 이 쿠키는 같은 서버로 요청을 보낼 때마다 자동으로 헤더에 들어가게 된다. 정말 놀라운 사실은, 나는 이 쿠키를 서버에서 생성해서 넘길 수 있다는 것 자체를 처음 알았다. 항상 앞단에서 자체적으로 생성하곤 했었는데... 하나만 알고 둘은 몰랐구나ㅠㅠ

오늘 한 일

• 출근해서 맞닥뜨린 가장 첫 이슈였다. 댓글을 삭제하기 위해 서버로 DELETE 요청을 보내는데, 분명 형식에 맞춰 보냈는데도 왜인지 자꾸만 400 에러가 뜨고 오류의 원인은 쉽게 찾아지지가 않았다.
• 400이 뜨는 만큼 내가 뭔가 잘못한 것 같기는 한데 명확한 에러 메시지도, 가늠해 볼만한 단서도 없어서 일단 구글링을 시작했다.
• 찾아보니 DELETE에 request body를 보내도 되느냐를 가지고 제각기 말들이 많았다. 아니 근데 나도 body 보내는데...!?
• 이것과 관련한 문제가 맞을 것 같은 예감이 들었고, 그러던 중 스택오버플로우에서 해결책을 찾았다.

오늘 배운 것

• request body를 data라는 키를 붙인 객체로 만든다. {key: value} 이었다면 {data: {key: value}} 이런 식으로. 단순히 이걸로 해결된다니...