코딩연습장

프로젝트가 거의 다 끝나간다. 어짜피 다음주에 정리를 해야하지만 먼저 간단하게 어떤라이브러리를 왜 사용했는지 정리를 해보려고한다. 1. @emotion/styled 기존 리액트를 배울 때 styled-components를 사용했었다. 둘의 스타일 기능은 전반적으로 동일하다. props사용, 미디어쿼리, 글로벌 스타일, nested selectors, SSR 등... 둘다 sass문법을 사용하기에 스타일 문법에도 차이가 없다. 성능상 둘의 유의미한 차이는 없지만 emotion의 퍼포먼스가 전반적으로 좋게 나온다하여 선택하였다. 러닝커브가 높다는 단점이 있었지만, 리액트를 공부하면서 계속 사용해왔어서 어찌보면 지금은 css보다 익숙해져있어 선택하게 되었다. 2. redux / redux/toolkit 처음에..

프로젝트가 사실상 거의다 끝났다. 앞으로 기능 한두개만 추가하고 런칭을 할 것이다. 이번주는 디자인 시안이 올 때 CSS작업을하고, 기능은 별로 추가할 것이 없었다. 그래서 중간중간 CSS작업을 살펴보며 필요없는 코드가 없는지 살펴보았다. 이번 디자인 시안을 적용할 때 서버에서 넘어온 캠핑장의 주요시설 문자열에따라 아이콘을 알맞게 설정해야했다. 어짜피 주요시설 문구들은 정해져있기 때문에 하드코딩으로 문자열을 포함한 배열을 만들고, 동일한 순서로 이미지를 배열화했다. 그리고 서버에서 넘어온 문자열을 하드코딩된 문자열배열에서 index값을 찾아 이미지 배열에서 동일한 index를 img태그의 src에 담으려고했지만, 코딩에서의 실수인지 src값 안에 {imgname: base64/png/~~~} 이런식으로 ..

styled components / emotion/styled 성능상 유의미한 차이가 나지 않는다. emotion의 퍼포먼스가 전반적으로 더 좋게 나오고있다. emotion이 번들의 크기가 더 크다. 동일 코드로 번들크기가 더 증가한다. 참고자료 css-in-js 장점 css파일의 유지보수가 필요없어진다. 단일파일에서 관리가 가능하다. js의 코드를 활용할 수 있다. 해당 DOM에서만 활용할 수 있는것도 장점, js와 css사이에있는 상수와 함수를 공유할 수 있다. 단점 러닝커브가 높다. (기술 또는 지식을 실무와 같은 환경에서 효율적으로 사용하기위해 드는 학습비용) 별도의 라이브러리를 필요로해서 크기가 커질 수 있고, 디자인페이지를 작업한다면 csss 모듈방식에비해 느린 성능을 보여줄 수 있다. ==>..

이번주에 http통신연결하고, 데이터주고받고, 추가데이터요청하고, 불필요데이터 제거해달라 요청하고... 사실 저번주와 다를 건 없었다. 하지만 이번주에 처음 해본 것은 하나 있었다. 바로 소셜로그인이었다. OAuth2.0을 사용하여 카카오로그인을 연결했다. 처음에는 제공된 설명을 읽어도 당최 뭔소린지 이해를 못했는데, 여러번 읽고, 저번 기수의 코드를 읽어보며 대충 어떻게 굴러가는지 이해하게되었다. 그리고 백엔드분이 준비해준 API KEY를 사용하여 연결했다. 처음부터 잘 되지는 않았다. 그 이유는 Redirect URI를 설정하는데있어, 이해도가 적었기 때문이다. 처음 사용자가 카카오로그인 버튼을 누르면 미리 설정된 API KEY와 REDIRECT_URI를 주소값에 담아 카카오가 준비한 주소로 이동한다..

api는 바뀌었고 바뀐 부분을 적용하는데 여러번 오류도 뜨고, 불필요한 데이터도 제거하고, 필요한 데이터를 추가로 요청도 했다. 아직 디자인은 안왔다. 큰일이다. 다만 백엔드와 소통하면서 확실하게 소통이 중요한 것이라고 깨닳았다. 데이터가 부족할때, 의견을 구할때, 문제가 생겼을 때 백엔드분들과 소통하면서 상황을 해결하려하면 쉽게 진행될 때가 많다. 소통을 잘하는 개발자가 되자.

오늘은 백엔드의 서버배포를 기다리면서 소셜로그인을 대충 보았다. 보고도 아직 이해를 못해서 직접해봐야할것같다 ㅋㅋㅋ 서버 배포가 저녁에 완료되어서 저녁에서야 작업을 시작했고 대략 6시간밖에 못한것 같다. 그래도 mvp로잡은 api는 거의다 완료해서 디자인시안이 도착하면 해당사항을 적용하고, apif를 다 마무리하면 검색기능을 시작하든, 유효성검사를 좀 더 마무리하든 해야겠다

일단 우리조는 리더가 사전에 신청하지 않은, 시작때 리더가 없던 조였다. 리더가 사전에 신청한 조는 어느정도 리더가 자신이 생각하는 프로젝트를 구성해서 오기 때문에 시작이 빠르지만, 우리는 사전에 정해진 것이 아무것도 없었기때문에 프로젝트 주제를 정하는 것 부터 시간이 걸렸다. 인원수는 프론트3명, 백엔드3명으로, 어느정도 큰 틀을 정하고 백엔드는 데이터구조를 정하고, 프론트는 와이어프레임을 어림잡아 정했다. 디자이너님이 디자인 시안을 주기 전에 일단 타입스크립트를 공부했다. 어려울것이라고 분명히 생각했지만, 그래도 타입스크립트는 실무에서 기본으로 깔린다는 말이 많아서 사용하기로했다. 주말간 타입스크립트를 공부하고, 월요일이 되었다. 디자인이 오지않아서 일단 뼈대작업을 시작했다. 하루종일 뼈대만 그렸다...

오늘 새롭게 추가될 api와 기능들에대해 안내받았다. 지금까지 어느정도 기초적인 api를 만들었으니 월~화에 바뀌는 api를 기준으로 또 바꿔야할 것 같다. 디자인이 너무 늦게온다. 3주안에 완성해야하는데 1주가 넘은 지금 1페이지 밖에 안왔다. 목디스크가 생긴것 같다. 툭하면 목, 두통이 심하게와서 고통스럽다.

무한스크롤 어제 적었던 오류를 수정했다. 문제는 어제 생각했던 것이 아니었다. target이 mount시점에 값이 들어가다보니, 시작하자마자 pageno가 1에서 2가되고, 따라서 요청을 두번 하게된다. 그런데 dispatch가 비동기 처리이므로, pageno가 1이었을 때 요청이 완료되기전에 pageno가 2일때의 요청도 시작되어, 데이터가 정상적으로 들어오지 못한 것이다. 따라서 target에 넣는 ref값을 삼항연산자를 사용해서 적당한 때 값이 들어가서 mount시점이아닌, 스크롤이 바닥을 칠 때 작동되도록 하였다. 오늘 api를 여러개 연결했다. 내일은 수정관련해서 만들어 볼 생각이다.