Ubuntu 18.04 .env 파일 생성, 숨김 파일 확인

이미지
  .env 파일 생성 명령어 $ sudo vim .env 숨김파일을 포함한 모든 파일 목록 확인 $ ls -a vim 에디터로 들어가지 않고 명령어로 파일 내용 확인하는 명령어 $ cat "filename" ex) $ cat .env

Redux-Saga effects(이팩트) 정리

이미지
delay 설정된 시간 이후에 resolve하는 Promise객체를 반환한다. put 특정 액션을 dispatch하도록 한다. take 1회만 실행하고 이벤트 삭제   takeEvery 들어오는 모든 액션에 대해 특정 작업을 1번만 처리해 준다. 이벤트 계속 유지   takeLatest 기존에 진행 중이던 작업이 있다면 취소 처리하고 가장 마지막으로 실행된 작업만 수행한다. 또는 동시에 들어오는 여러 요청들 중 마지막에 호출된 작업만 수행한다. 클릭을 연달아 3번 했을때 앞에 두번의 이벤트는 무시하고 마지막 이벤트만 실행한다.  이미 완료된 경우에는 실행하지만 세번 클릭 중 앞의 두번의 클릭이 pending 상태인 경우 마지막 요청만 실행한다. * 프론트 단에서 연달아 2번 클릭하여 요청을 2번 보내게 되면 백엔드 단에서 response는 한번 보내지만 백엔드 단에는 2번 요청이 갔으므로 정보가 2개(중복) 저장될 수 있다. * 두번째 인자로 들어온 콜백함수는 제너레이터 함수가 아닌 일반 함수로 작성해야 한다!! throttle 일정시간이 지날때까지 추가적인 요청을 수행하지 않는다. 함수가 호출된 후 지정해둔 시간동안 함수를 호출하더라도 실행하지 않는다. takeLatest의 문제점을 해결 가능. debounce 동일한 함수가 연속해서 호출될 때 첫번째 또는 마지막 호출만 실행하는 기능 * debounce와 throttle의 차이점 throttle은 지정한 시간마다 정기적으로 기능 실행을 보장한다. 반면에 debounce는 수많은 이벤트가 발생해도 모두 무시하고 특정 시간 사이에 어떤 이벤트도 발생하지 않은 경우에만 딱 한번만 마지막 이벤트를 발생시키는 기법이다.  그러므로 지정한 ms(초)가 지나기 전에 계속 이벤트가 발생할 경우 콜백에 반응하는 이벤트는 발생하지 않고 계속 무시된다. call 동기 함수 호출(api 호출 후 return까지 대기), fork는 비동기 함수 호출(기다리지 않고 return 다음으로 이동) * api 통신할때는 무조건 call을

Next.js에 styled-components 적용하기

이미지
Next.js에서 styled-components를 작성해도 ssr시 제대로 적용되지 않는 문제가 발생하였다. 이를 해결하기위해서 몇가지 설정이 필요하다. 1. babel 설정 Next.js는 첫 방문한 최초 페이지를 ssr방식으로 렌더링하고 이후에 페이지 내부에서 라우팅을 통해 다른 페이지로 이동하게되면 csr방식을 이용하게 된다. 이때 서버에서 생성하는 해시값과 브라우저에서 생성하는 해시값이 서로 달라서 문제가 발생하게 된다. 이를 해결하기위해서 바벨 플러그인 패키지를 설치한다. $ npm i -D babel-plugin-styled-components 바벨 플러그인을 설치한 뒤 root 디렉토리에  .babelrc 파일을 생성하고 아래 코드를 작성한다. { " presets " : [ " next/babel " ], " plugins " : [ [ " babel-plugin-styled-components " , { " ssr " : true, } ] ] } 공식문서 참고 https://github.com/vercel/next.js/blob/master/examples/with-styled-components/.babelrc 2. _document.js 설정 pages 폴더안에 _document.js 파일을 생성한다.  ssr시에 실행되는 파일인 _documents.js에 styled-compoents의 스타일 코드를 추출하는 로직을 작성한다. 공식문서 참고 https://github.com/vercel/next.js/tree/master/examples/with-styled-components import React from ' react '; import Document , { Html , Head , Main , NextScript } from '

[Express.js] 더이상 body-parser를 사용하지 않아도 된다.

body-parser는 유명한 라이브러리이다. 그 이유는 body-parser를 사용하면 클라이언트측에서 보내는 요청과 데이터에 대해서 서버측에서 특정 라우터에서 req.body객체로 데이터를 쉽게 전달 받을 수 있기 때문이다. 사용방법: const express = require ( ' express ' ) ; const bodyParser = require ( ' body-parser ' ) ; const app = express () ; // parse application/x-www-form-urlencoded app . use ( bodyParser . urlencoded ( { extended : true } )) ; // parse application/json app . use ( bodyParser . json ()) ; app . post ( ' /profile ' , ( req , res ) => { console . log ( req . body ) ; } ) ; 만약에 body-parser를 사용하지 않는다면 req.body의 반환값은 undefined가 될 것이다. 그런데!! 이렇게 body-parser를 설치했어야했는데 이제는 더이상 body-parser를 사용하지 않아도 된다. express.js에서 body-parser 기능을 추가했기 때문이다. 참고:  https://expressjs.com/en/4x/api.html#express-json-middleware 앞으로는 body-parser 대신에 아래와 같이 미들웨어를 작성하면 똑같이 req.body 객체로 클라이언트 측에서 보낸 요청과 데이터를 받을 수 있게 되었다. const express = require ( ' express ' ) ; const app = express () ; app . use ( express . json ()) ; app . use ( expres

Prettier와 ESLint 그리고 Airbnb Style Guide 설정

이미지
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] git add, commit, push 취소하기

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 -

[React] useCallback, useMemo, React.memo 사용하여 최적화하기

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