TIL

20210901~20210910 TIL in Goorm

1. 코드리뷰 관련

1-1. 스타일링 관련

  1. 리액트스트랩
    • 부트스트랩 기반으로 만들어진 컴포넌트 → 부트스트랩 하나하나 가져올 필요 없이 통째로 사용 가능
  2. 부트스트랩
    • 뭉뚱그러진 css 스타일링 가능 → 리액스트렙으로 통째로 불러오는 것이 아닌, 세세한 부분

1-2. git flow

  • master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
  • develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
  • feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
  • release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
  • hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.

1-3. src, static 폴더 역할

  1. src 폴더
    1. 소스코드를 나타냄 →컴파일 이전의 원시코드
    2. 빌드 → 컴파일 → 실제 프로덕션 사이트에서 사용하는 코드는 dist폴더로
  2. static 폴더
    1. 웹팩을 통한 패키지화 없이 바로 참조됨

1-4. 함수 내부에서 require호출 시 성능 이슈

  • 함수 내부에서 require이용시 성능 이슈가 있다고 한다 -> 전역으로 빼내서 요청하기 !

1-5. slice 기능과 같은 기능 구현 가능한 라이브러리

1-6. 서버의 initial 데이터

  • SSR 특징과 관련 ) 보면 좋을 글
  • https://d2.naver.com/helloworld/7804182
  • SSR: 서버에서 페이지의 내용을 다 그려서 브라우저로 던져줌 → 페이지를 그릴 때 initialProps를 보냄
  • next.js에서는 getInitialProps를 통해 이를 불러온다
    1. Next Server가 GET 요청을 받는다.
    2. 요청에 맞는 Page를 찾는다.
    3. _app.js의 getInitialProps가 있다면 실행한다.
    4. Page Component의 getInitialProps가 있다면 실행한다. pageProps들을 받아온다.
    5. _document.js의 getInitialProps가 있다면 실행한다. pageProps들을 받아온다.
    6. 모든 props들을 구성하고, _app.js > page Component 순서로 rendering.
    7. 모든 Content를 구성하고 _document.js를 실행하여 html 형태로 출력한다.
  • 주의할 것
    • getInitialProps 내부 로직은 서버에서 실행된다. 따라서 Client에서만 가능한 로직은 피해야 한다. (Window, document 등)
    • 한 페이지를 로드할 때, 하나의 getInitialProps 로직만 실행된다. 예를 들어 _app.js에 getInitialProps를 달아서 사용한다면 그 하부 페이지의 getInitialProps는 실행되지 않는다. 다만, 다음과 같이 커스터마이징을 하면, 최종 결과를 pageProps에 담을 수 있다.
  • 보면 좋을 글 : https://velog.io/@cyranocoding/Next-js-구동방식-과-getInitialProps

1-7. propTypes 사용하기

  • JS 프로젝트에서 props 점검 위해서 propTypes 라이브러리 적극 사용하기
  • 서버 데이터 들어오기 이전 defaultProps 지정 가능, 들어오는 타입에 따라 렌더링 과정에서 에러 발생 → 리액트가 렌더링하는 과정에서 잘못된 속성값 타입들 검사해주기 때문에 가능 ) 이 연산의 성능상 이유로 개발 모드에서만 확인됨

2. 에러 해결 관련

2-0. 전제

  • 원인을 정확히 파악 → 기본적으로 내가 원하고자 하는 기능이 실행되기 위해선 어떤 조건이 필요한지 명확하게 파악하기 !

2-1. 웹소켓 namespace에러

  • default namespace 와 path를 각각 지정해줘야 한다! (둘의 개념을 혼동하는 순간 서버와 클라가 매칭이 안된다)
  • 서버
    • const io = socketIo(server,{ path:"/socket.io" });
  • 클라
    • const socket = io('/', { path: '/socket.io', reconnectionDelayMax: 10000, transports: ['websocket'], });

2-2. svg, png 관련

  • svg → 화질 매우 좋지만, 때때로 그거 유지 위해서 원하는대로 이미지 제어 안될 수도 있다
  • background-image 비율 깨트려야하는 상황에서도 svg는 이미지 비율 유지

3. 프로젝트 관련

3-1. MVC패턴을 따름

Model, View, Controller

  1. Model : DB
  2. Controller : Server
  3. View : Client

3-2. lodable설정

  • 코드 스플리팅을 위한 설정
  • 추후 웹팩 빌드과정과 함께 제대로 공부해서 벨로그 포스팅 하기!

3-3. AWS 사용 방식

  • s3에 이미지 등을 업로드 → 우리 자체 서버의 자원을 아낄 수 있다
  • s3 앞단에서 클라우드 프론트(CDN)를 사용하여 사용자의 위체에 따라 edge server를 따로 둔다
    1. 클라이언트로부터 Edge Server로의 요청이 발생한다.
    2. Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부를 확인합니다.
    3. 사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답합니다. 
       사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Origin Server로 요청이 포워딩됩니다.
    4. 요청받은 데이터에 대해 Origin Server에서 획득한 후  Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생합니다.
  • 주의할 것 ) 이미지 수정할 때 캐싱 서버도 바꿔줘야 한다는 것을 주의해야한다!