코딩연습장

이번주는 런칭한 결과물에대해 피드백을 받고, 구글애널리틱스를 통해 쌓인 데이터와 함께 결합하여 페이지를 개선시키는 작업을 하였고, 인증번호 관련 작업을 진행했다. 유저가 캠핑장을 예약하는 기능이 우선인 사이트여서 사용자에 대한 정보가 믿음직한지 신뢰도가 필요했다. 하지만, 결제 시스템도없고, PASS를 도입하기에는 시간적 여유도 없어서 간단하게 전화번호 인증을 구현하는 방향으로 진행했다. 인증번호를 서버로부터 받아오고, 발금하는 버튼을 작동하지 않게 처리한다던지, 인증번호를 발급받으면 아래에 만료시간 타이머가 작동한다던지, 재발금시엔 어떻게 작동한다던지 하는 섬세한 작업이 필요했다. 클라이언트 단에서 인증번호를 생성하고 그걸 비교해야하나? 라고도 생각했지만, 그렇게 한다면 보안적으로 올바르지 않다고 생각..

프로젝트가 거의 다 끝나간다. 어짜피 다음주에 정리를 해야하지만 먼저 간단하게 어떤라이브러리를 왜 사용했는지 정리를 해보려고한다. 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를 주소값에 담아 카카오가 준비한 주소로 이동한다..

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

이번주는 클론코딩 주차였다. 솔직히 crud를 한번 더 해서 연습량을 늘려보고싶었지만, 한분이 웹소켓을 해보는 것은 어떻겠냐는 말에 웹소켓을 하기로했다. 웹소켓은 클라이언트와 서버의 통신방법이다. http통신은 클라이언트에서 request를 보내면 그에따른 response값을 서버로부터 클라이언트가 받게 되는 형식이었다. 하지만 웹소켓은 클라이언트가 서버와 처음 handshaking을 하면 접속이 끊기기 전 까지 계속해서 통신을 주고 받는 것이다. 이 때 서버는 클라이언트의 특정 req가 없더라도 res를 보내 줄 수 있으며, 클라이언트 또한 연결이 되어 있다면 따로 제한 없이 데이터를 보내고 받을 수 있다. 우리는 다양한 웹소켓 툴 중 socket.io를 사용했다. 웹소켓을 통해 방을 만들어 채팅방을 ..

처음으로 백엔드 분들과 협업을 했다. 백엔드 분들은 주특기 3주 내내 crud를 하셔서 조금 질리셨다는 이야기는 들었지만 다행히도 너그럽게 이해해주셔서 스코프를 작게 잡고 시작할 수 있었다. 다른 조에 비하면 너무 작았기 때문에 실제로 일찍 끝났고, 정상적인 범위의 스코프로 확장 할 수 있었다. 물론 그거까지 하더라도 너무 기능이 적긴 했다. 하지만 이번 프로젝트를 하면서 서버에 이미지파일을 보내야 할 때는 formdata를 사용해야 함을 알 수 있었다. base64로 인코딩하여 보내려 했지만, 서버에서 저장할 수 있는 문자열의 길이가 제한이있고, 그걸 따로 설정하려면 피곤하기 때문에 백엔드 분께서 이미지파일을 위한 s3서버를 열어주셨고 자동으로 백엔드에서 전송하도록 설정해주셔서 편하게 할 수 있었다. ..

이번주는 json-server을 만들어 해당 서버와 통신하는 과제를 진행했다. 이번주에는 개인과제가 아닌 같은 FE끼리 팀으로 한 프로젝트를 만드는 것이었다. 일단 토요일부터 코로나때문에 건강이 좋지 않았다. 요새 항상 하루종일 늦게까지 코딩했었고, 실수로 하루 창문을 열고 잤는데 그때 면역력이 확 낮아져서 코로나가 빠르게 발현된 것 같다. 어쨋든 풀스택 이후로 처음으로 협업을 해서, git으로 브랜치를 나누는 방법도 몰라 좀 고생했다. 뼈대를 잡고 그것을 main으로 뿌리고, 개인 branch를 만들어 개개인의 작업을 하고 main에 merge한다. 겹치는 파일이 있을 땐 conflict가 나지 않도록 조심해야한다. 그리고 처음으로 axios도 사용해보았다. 서버와 통신하기위해 사용하는 것 인데, 이번..

이번주는 리덕스를 활용하여 입문주차때 했던 Todolist를 만드는 것이었다. 분명 props를 사용해 state를 내려주는 것 보다는 전역상태관리가 더 효율적이라는 것은 알겠지만, 공부하는데 너무 고통스러웠다. 전에 사용했던 props는 내가 직접 내려주고 받아서 사용하다보니 뭔가 직관적이어서 이해가 쉬웠는데, 중앙store에서 state를 관리하고 그것을 뿌려주는 형식이다보니 이해가 어려웠다. 클래스, 함수형 컴포넌트 각각의 lifecycle은 예전에 정리했었다. https://codingpracticenote.tistory.com/62 Hook이란? component의 lifecycle이란? component가 리렌더링되는 조건은? Hook이란 기존 class바탕의 코드를 작성할 필요 없이 상태 값..