프로그래밍 공부 노트

Prettier와 ESLint에 대해서 간단히 설명하자면 Prettier는 코드를 정리해주는 도구이며 코드 정리 방식을 세부적으로 설정할 수 있다. ESLint는 문법을 검사해주는 도구이며 다양한 옵션을 작성하여 원하는데로 문법을 검사하도록 설정할 수 있다.(코드 포맷팅 효과도 있긴하다) 이 두가지 도구를 사용하는 가장 큰 이유는 여러사람이 코드를 작성하더라도 한사람이 작성한것과같이 효과를 주어 협업시 효율을 극대화 하기 위해서이다. Prettier와 ESlint Airbnb 코드 스타일 적용, 설정 하는 방법 1. 두가지 도구는 간단하게 VSCode에서 Extensions로 ESLint와 Prettier를 다운받을 수 있다. 2. 이렇게 다운받은 두가지  Extensions 는 global로 설치되어있다.  그러므로  프로젝트별로  ESLint와  Prettier를 설정하기 위해서는 해당 프로젝트 root 디렉터리에 devDependencies에 eslint와 prettier를 다운받아야 한다. $ npm install -D eslint prettier 3. Airbnb 구성 설치하기 $ npx install-peerdeps --dev eslint-config-airbnb 위 명령어를 통해 관련 구성을 한번에 설치할 수 있고 하나씩 설치할 수도 있다. " devDependencies " : { " eslint " : " ^7.25.0 " , " eslint-config-airbnb " : " ^18.2.1 " , " eslint-plugin-import " : " ^2.22.1 " , " eslint-plugin-jsx-a11y " : " ^6.4.1 " , " eslint-plugin-react " : " ^7.23.2 &q

git add 취소하기 파일 상태를 Staged => Unstage로 변경하기 $ git reset HEAD <file>  명령어를 통해 git add를 취소할 수 있다. 뒤에 파일명을 작성하지 않으면 add한 파일 전체를 취소한다. untracked 파일 삭제하기 git clean 명령은 추적 중이지 않은 파일만 지우는 명령어이다. 즉, .gitignore 에 작성한 무시되는 파일은 지우지 않는다. 디렉터리를 제외한 파일들만 삭제 $ git clean -f  디렉터리까지 삭제 $ git clean -f -d ignored 된 파일까지 삭제 $ git clean -f -d -x git commit 취소하기 commit을 취소하고 해당 파일들은 staged 상태로 워킹 디렉터리에 보존 $ git reset --soft HEAD^ commit을 취소하고 해당 파일들은 unstaged 상태로 워킹 디렉터리에 보존 $ git reset --mixed HEAD^ // 기본 옵션 $ git reset HEAD^ // 위와 동일 $ git reset HEAD~2 // 마지막 2개의 commit을 취소 commit을 취소하고 해당 파일들은 unstaged 상태로 워킹 디렉터리에서 삭제 $ git reset --hard HEAD^ commit message 변경하기 $ git commit --amend git push 취소하기 * 주의할점 이 명령을 사용하면 자신의 local의 내용을 remote에 강제로 덮어쓰기를 하는 것이기 때문에 주의해야 한다. 되돌아간 commit 이후의 모든 commit 정보가 사라지기 때문에 주의해야 한다. 특히, 협업 프로젝트에서는 동기화 문제가 발생할 수 있으므로 팀원과 상의 후 진행하는 것이 좋다. 가장 최근의 commit을 취소한다. (기본 옵션: --mixed) $ git reset HEAD^ Reflog 목록 확인 (브랜치와 HEAD가 지난 몇 달 동안에 가리켰었던 커밋) $ git reflog 또는 $ git log -

useCallback React에서 이벤트 핸들링을 해야할 때 보통 컴포넌트 내부에 함수를 선언하게 된다. React 컴포넌트는 컴포넌트 내부의 상태값이 변경될 때 리렌더링이 발생된다. 상태값이 변경되면서 리렌더링이 발생될 때 컴포넌트 내부에 선언한 함수 또한 새로 호출되게 된다. 이렇게 되면 불필요하게 메모리가 낭비되어 최적화에 좋지 못하다. 왜냐하면 특정 상태의 변경과 아무 상관도없는 함수도 계속해서 새로이 만들어지기 때문이다. 이러한 문제점을 방지할 수 있는것이 useCallback 이다. useCallback을 사용하면 지정한 특정 상태값(의존성)이 변경되지 않는한 컴포넌트 내부에 선언한 함수가 리렌더링시 새로이 생성되는것을 방지할 수 있다. const memoizedCallback = useCallback ( () => { doSomething ( a , b ) ; }, [a , b] , ) ; 공식 문서를 보면 메모이제이션된 콜백을 반환하며 그러한 콜백은 의존성이 변경되었을 때에만 변경된다고 나와있다. 즉 메모이제이션된 콜백을 반환한다는 말은 이전에 생성한 함수를 캐싱해둿다가(기억해 뒀다가) 재사용할 수 있는 콜백함수를 반환한다는 말이고 두번째 인자인 deps 배열 내부에 작성한 상태값(의존성)이 변경되지 않으면 리렌더링시 함수가 새로이 생성되는것을 방지한다는것이다. useCallback을 사용하면서 주의할 점은 useCallback 내부에서 사용되는 상태값(의존성)은 모두 useCallback의 두번째 인자에 의존성으로 모두 작성해 주어야한다. 그러지 않으면 초기의 상태값을 기억해 기존 상태값을 계속해서 반환하게 된다. 마지막으로 useCallback을 꼭 사용해야하는 때는 부모 컴포넌트에서 자식 컴포넌트에 props로 함수를 전달할 때 이다.  그 이유는 함수가 객체로 취급될 수 있기 때문에 자식 컴포넌트에서는 이전에 props로 전달된 함수와 다른 함수라고 인식하여 리렌더링이 발생할 수 있기

      client_max_body_size 의 크기 제한 설정을 너무 낮게해놔서 발생한 오류였다.  즉 전달 받을 수 있는 파일의 크기가 제한 설정을 너무 낮게 작성했었다. 100k( 100kb) 였던 제한을 100M(100Mb)로 변경해주었더니 오류가 없어졌다. nginx.conf 파일에서 해당 부분을 수정하고 난 후 재시작을 해줘야지 잘 적용된다. $ sudo service nginx restart 재시작 한 후 잘 돌아가는지 확인 $ sudo service nignx status 참고 https://stackoverflow.com/questions/19917401/error-request-entity-too-large

어느 페이지에서 현재페이지로 왔느냐에따라 다르게 처리하고 싶은 경우가 있다. 이때 react-router-dom의 history.push()로 간단하게 처리할 수 있다. 일반적으로 react-router-dom으로 라우팅할 경우 아래와 같이 많이 작성한다. history . push ( ' /payment Page ' ) 하지만 간단하게 아래와 같이 작성하면 어느페이지에서 현재페이지로 왔는지 props를 넘겨주어 현재 페이지에서확인할 수 있다. history . push ( { pathname : " / payment Page " , state : { _id : " 0001 " , name : " detailPage " }} )  경로를 받아올 때는 history.location을 사용해서 pathname 값과 state값을 현재 페이지에서 받을 수 있다. 위 코드에대한 결과는 아니고 프로젝트에서 사용했을때 console.log()로 history.location을 확인해보면 아래와 같이 해당 페이지에서 경로와 값들을 받을 수 있는것을 확인할 수 있다. 나의 경우 프로젝트에서 결제페이지로 넘어오는 경로가 장바구니 목록에서 온것인지 아니면 상품을 바로 선택해서 결제페이지로 넘어온것인지에 따라 다르게 처리하는데 사용했다. 참고: https://stackoverflow.com/questions/44121069/how-to-pass-params-with-history-push-link-redirect-in-react-router-v4

프로젝트를 진행하던 중 특정 Collection에서 데이터가 정상적으로 저장되지 않는 문제가 발생했었다.  자세히 설명하자면 videos Collection에 사용자가 업로드한 영상에 관련한 데이터들을 담아야하는데 따로 업로드 횟수 제한등을 설정하지 않았는데도 불구하고 한명의 유저가 여러개의 영상을 업로드 하더라도 단하나의 Documents만 생성되는것이었다. DB에는 사용자가 업로드한 영상이 제대로 들어와서 저장되었지만 mongoDB Atlas에서 videos Collection에 Documents가 유저별로 단 하나씩만 생성되고 추가로 업로드하는 영상에대한 Documents가 생성되지 않는 문제가 발생했었다. 따로 에러코드가 발생하지도 않아서 내가 코드를 잘못 작성해서 그런가 싶어서 프론트에서 넘긴 데이터가 백엔드쪽으로 제대로 전달이 안되고있는건가 콘솔을 다 찍어보면서 확인해 보고 인터넷에 검색해 봤지만 몇 시간 동안 해결방법을 못 찾았다. 그러던 중 무심코 지나쳤던 MongoDB Atlas Collection에  탭들이 보였다. 그 중 indexes 탭을 눌러봤는데 mongoose로  schema model을 작성할 때 초반에 nickname에 실수로 unique 속성을 작성한것이 그대로 mongoDB Atlas에 저장되어있던것이었다.  schema model에 unique가 작성되어있는 상태에서 이미 데이터가 하나 저장되어있었고 그 후에 내 코드 편집기에서 unique 속성을 수정했지만 이미 데이터를 하나 저장하면서 MongoDB Atlas 에는 해당 unique 속성이 적용되어있었기 때문에 유저별로 하나씩의 Document만 저장되는 것이었다. 옆에 Drop index를 눌러 unique 속성을 지우고 다시 시도해보니 내가 원하던데로 저장이 되었다. 이미 수정을 모두 마친뒤라 위에 users Collection으로 사진을 대체했다. 아래는 User.js 모델 const mongoose = require ( " mongoose "