오늘 새로 배운 것
JSON
JSON은 생김새는 Object지만 type은 문자열이다.
JSON.stringify()는 Obj를 JSON 문자열로 변환해준다.
반대로,JSON.parser는 JSON을 Obj로 변환해준다.
fetch, then, json 함수
fetch() 함수는 promise 형태의 객체를 리턴한다.
promise가 가지고 있는 속성과 메서드 중에 하나가 then이라는 메서드인데, promise 객체 뒤에 .을 붙여 사용할 수 있다.
then은 비동기 동작을 다 수행할 때까지 기다렸다가 이후 값들을 response로 받아서 처리한다.
fetch(URL).then((res)=>res.json)
res는 url로부터 통신하여 받아온 모든 것이 담겨있는데 모든 걸 다 사용할 것은 아니기 때문에 res라는 객체 중 json이라는 메서드(body 부분을 때서 promise 형태로 리턴하는 비동기 함수)를
res 안에는 Body, header, status, type, url … 등의 값이 들어있는데 그중에서 우리가 쓸 것은 body.
이 body를 쓰기 위해서 뒤에 json() 메서드를 붙이면 이 body를 promise 형태로 가져올 수 있다.
Middleware
미들웨어는 dispatch 함수를 결합해서 새 dispatch 함수를 반환하는 고차함수. 이들은 비동기 action을 action으로 전환한다. action을 로깅하거나, 라우팅과 같은 부수효과를 일으키거나, 비동기 API 호출을 일련의 동기 action으로 바꾸는데 유용하다.
thunk
Redux의 미들웨어 중 하나. 비동기적 작업을 Redux로 처리할 때 사용하는 도구.
기존에 dispatch를 통해 객체를 전달했던 것을 함수를 dispatch할 수 있도록 해줌. action이 reducer로 전달되기 전 그 사이에서 실행된다.
동기적 action에는 reducers, 비동기적 action에는 extraReducer를 사용하는데 reducers로 동기 작업을 할 때는 리덕스 툴킷이 action creator를 자동으로 만들어주는 반면, extraReducer로 비동기작업을 할 때는 툴킷이 action creator를 자동으로 만들지 못하므로 extraReducer 안에서 action creator를 정의해준다.
createAsyncThunk라는 리덕스 툴킷의 API가 있는데 비동기 작업을 처리하는 action을 만들어줌.
thunk함수는 reducer에 직접 넣는 것이 아니기에 해당 메서드를 사용해야하고 진행중, 성공, 실패 각각의 케이스에 대한 동작을 구현해야한다.
(pending, fullfilled, rejected)
이 thunk를 처리할 때 extraReducer를 사용한다.
thunk의 사전적 의미는 별 뜻 없다. (푹, 턱 등 둔탁한 소리를 나타내는 의성어)
memo
컴포넌트에 불필요한 리렌더링을 하지 않게 해주는 함수. 불필요한 리렌더링은 화면에서 변경되는 부분이 없음에도 다시 렌더링되는 경우이다.
화면이 리렌더링되느 경우는
1 부모 컴포넌트가 렌더링되는 경우
2 컴포넌트의 state가 변경되는 경우
3 부모로부터 전달받은 props값이 변경되는 경우
화면에서 변경되는 부분이 없는데 렌더링되는 경우를 줄이면(최적화) 프로젝트의 부하를 줄이고 성능을 향상시킬 수 있다.
useCallback
컴포넌트가 리렌더링되더라도 생성된 함수를 새로 만들지 않고 재사용할 때 사용하는 훅.
useEffect와 마찬가지로 두번째 매개변수에 있는 의존성 배열 내의 값이 변경될 때만 useCallback 안에 함수를 생성하는 로직을 가지고 있음
useMemo
useCallback과 같은 기능을 하는 훅이지만 그 대상이 함수가 아닌 '배열'이나 '객체'일 때 사용. 사용방법과 원리는 useCallback과 같음.
최적화 hook을 사용할 때 주의할 점
단, 최적화 훅이라고 해서 남용하는 것은 오히려 성능에 악영향을 줄 수 있기 때문에 불필요한 렌더링이 일어나고 있는지, 개선이 필요한지를 확인하고 적용해야한다.
반드시 리렌더링이 필요한 컴포넌트에 적용할 경우 업데이트가 되지 않을 수 있고, 렌더링 이전 이후의 값들을 비교해 같으면 재생성하고 같지 않으면 재생성하지 않는 과정이 추가가 되기 때문에 굳이 필요하지 않는 부분에 이 과정이 추가가 되면 성능이 안 좋아지기 때문이다.
하루를 돌아보며...
오늘 강의를 따라가다가 계속 같은 경로 오류로 yarn start가 먹히지 않아서 좀 삽질을 했었는데 yarn react-scripts start로 해주니까 오류가 뜨지 않고 동작하였다. 아마 이전 server폴더와 안에 파일이 있었을 때 yarn start 명령을 실행하면 이 경로를 default로 json server를 실행하게 해놓으려고 package.json의 scripts 부분이 이렇게 돼있었는거 같은데
"scripts": {
"start": "node server",
"start:dev": "cross-env NODE_PATH=src react-scripts start",
"build": "cross-env NODE_PATH=src react-scripts build",
"test": "react-scripts test --env=jsdom",
"eject": "react-scripts eject",
"heroku-postbuild": "cross-env NODE_PATH=src npm run build"
},위의 start 부분의 "node server"를 "react-scripts start"로 바꿔주고 yarn start로 다시 실행하니 react 서버 실행이 잘 된다. 어차피 강의용 프로젝트라 다시 만들어도 상관없지만 생각보다 간단하게 해결할 수 있어서 다행이다.
글고 담에는 디렉토리 내에서 뭔가 삭제할 때 예상하지 못한 오류가 발생할 수도 있으니 깃이나 어디 내용을 옮겨적어놔야겠다.
