Memoization : '이미 계산해 놓은 값을 메모리상에 저장해놓고 필요시 다시 재사용하는 기법' 이전에 (시간이 좀 흘렀지만..) 컴포넌트를 최적화 하는 과정에서, 전달하는 props 의 변화가 없을 경우 다시 렌더링 되는 것을 막아주는 기법으로 리엑트의 메모이제이션을 이용한다고 언급한적이 있고, 그에 대한 방법으로 React.memo 에 대해서 포스팅 하였다. 당시 예시를 통해서도 설명하였겠지만, props 로 함수 객체가 전달이 되었을 때는, 그 함수에 변화가 없더라도 매번 랜더링 시 새로운 객체로 생성되어 전달됨을 알 수 있었고, 그에 따라 React.memo 가 제대로 작동하지 않음을 알 수 있었다. 그 당시 같이 활용해 주었던 hooks 이 useCallback 이었는데, 이에 대해서 좀 ..
리엑트의 컴포넌트 상태 관리에 빼놓지 않고 등장하는 개념이 useCallback 과 useMemo! 데이터를 메모이제이션 하여 불필요한 re-render 를 막아준다고 알고 있다. 다만, 공부하는 입장에서 이 두가지 hook 이 어떠한 차이점을 가지는 지 명확하게 알지를 못하고 있어서 공부하던 중, 역시나 햇갈렸던 개념인 React.memo() 를 학습하게 되어 정리할 겸 포스팅을 해보려 한다. 근데 정리하면서도 계속 햇갈려서... React.memo() 2가지 훅과 함꼐 자주 거론되는 React.memo 를 먼저 살펴보는게 좋을듯 싶다. 특히, useCallback 과 React.memo 의 경우 거진 함께 사용되는 경우가 많기 떄문이기도 하다. 리엑트는 컴포넌트를 렌더링한 뒤 기존 렌더상태와 변경된 ..
이제 실제로 숙소 데이터에 필터를 적용해야겠다 앞서서 가격범위, 숙소유형 등 우리가 검색을 할 때 필요한 필터링한 부분을 state 에 저장하는 부분까지 다뤄보았다. 이제 우리가 어떠한 체크박스나 가격 범위등을 설정하면, 그에 따른 설정 값들이 useState 에 의해 저장되어있다. 뭐 침대는 몇개여야 하고, 침실은 몇개에, 개인실이어야 하며 최대 10만 미만인 등등.... 사실 원래 같았음, 이러한 조건들을 한데 모아서 최종적으로 검색 버튼을 클릭할 시 navigate 를 활용하여 URL 을 변경해주고, 메인페이지에서 변경된 URL 을 통해 백엔드 API 에 요청을 하게 되면 된다. 그러니깐 원래 계획은 그냥 사용자가 어떻게 필터를 하던 마지막에 가서 최종적으로 검색을 눌렀을 때의 필터값들을 전송하려고..
앞서서 가격 범위를 결정하는 부분에 대해서 살펴보았고, 이제 나머지 유형들을 필터하는 과정을 살펴보자. 숙소 유형 숙소 요형은 총 3가지로 나뉘게 된다. 전체를 아우르는 집 전체와 개인실, 다인실로 구현하였다. 다만 어떠한 숙소는 개인실로도 사용이 가능할 것이고 다인실로도 사용이 가능하게 된다. 따라서 중복 체크가 될 수 있도록 해야하고, 필터링 결과는 체크된 조건들을 모두 포함하는 숙소를 나타내야 할 것이다. 기존 에어비엔비 사이트의 필터창과 동일하게, 그리고 가장 직관적인 표현방법은 역시나 체크박스를 이용하는것이다. 체크박스는 실제로 로서 구현할 수 있었지만, 위에서 metarial UI 를 활용하였으니 이번에도 같은 라이브러리를 사용해보기로 하였다. 연습할겸 편리하기도 하니 사용하는 게 좋을것이라 ..
매번 다시 리뷰한다고 하면서도 안하고 있는 내모습... 2차 프로젝트에서는 1차와 달리 전체적인 컴포넌트들의 연결들을 담당했던 것을 제외하자면(라우팅 등) 크게 Nav 부분과 더불어 검색 부분의 Filter 를 담당했었다. 사실 원래는 검색 상세페이지를 담당하는 쪽으로 가고있었다가, filter 부분을 담당할 사람이 딱히 정해지지 않아서, 검색과도 연관이 깊은 부분이니 조원들에게 같이 담당을 하겠다고 얘기를 했었다. 스프린트 계획대로라면, filter 를 마무리하고 마지막으로 예약페이지 혹은 마이페이지를 작성하려고 하였으나, 2주라는 프로젝트 시간관계상 벅찬것도 사실이었고, 무엇보다도 나 자신이 생각했던 것보다 Filter 컴포넌트를 구현하는 데 애를 먹었던 기억이 난다. 당시에 뭔가 정리도 잘 안되는것..
클라이언트 사이드 렌더링과 서버 사이드 렌더링의 장점을 모두 가져오기 위해, 앞서서 Next.js 라는 프레임워크를 이용할 수 있다고 설명했었다. 다만 한번도 세팅을 해본적은 없어서, 공식문서 상 learn more 부분을 참고하여 초기 세팅을 해봤고, 간략하게 설명을 해보고자 한다. 시작하기.. 프레임워크인 Next.js 는 프레임워크인 만큼 첫 세팅때부터 말그대로 하라는 데로 잘 따라서 사용을 하면 된다. Next.js 가 가지고 있는 장점은 많은데, 리엑트보다도 좀 더 직관적인 페이지 기반 라우팅 CSR, SSR, SSG 페이지 단위로 지원 더 빠른 페이지 로드를 위한 자동 코드 분할 prefetch 를 통한 Client-side routing 대부분의 CSS-in-JS 라이브러리 구현 가능 등등 ..
많이 듣던 단어인데.. 자바스크립트를 처음 공부하고 있을 때, 남들이 리엑트를 쓴다고 하고 또 리엑트를 활용하면 좀 더 쉽게 화면단을 그릴 수 있다고 해서 약간 조급한 마음으로 자바스크립트를 공부했던 기억이 난다. 당시에 리엑트에 대해서 잘 몰랐으니, 사람들이 왜 리엑트를 사용하는지 잘 알 수 없었고, 그냥 전세계 사람들이 가장 많이 사용하는 라이브러리 라는 정보만을 가지고 있었다. 무엇인가 편리한 것이 있게지 싶어 넘어갔었을 때, 이해도 못하고 넘어갔었던 부분이 바로 SPA이다. 물론 지금도 완전히 이해한것은 아니니, 다시 돌아보는 지금 시점에서 한번 더 알아가보자 라는 마음으로 블로그를 작성해야겠다 마음먹었다. SPA(Single Page Application) 우선 왜 SPA 가 나오게 됬는지 파악..
이제 하위 컴포넌트들을 관리하는 최상위 컴포넌트 Nav 를 정리해보자. 처음 Nav 를 설계할 때, 생각 이상으로 상위에서 props 로 전달해주어야 할 변수 및 함수가 많을 것이라 예상되었다. 그도 그럴 것이 실시간으로 조건에 맞는 Nav 를 랜더링 해야하며, 그 각각의 Nav에 대해 따른 모달 컴포넌트도 정상적으로 랜더링 되어야 하기 때문이며 또한 사용자가 편리하게 사용할 수 있도록 신경써야 하였기에 Nav 가 유기적으로 움직이기 위해 좀 더 체계적으로 설계했어야 했다. 이로 인해 Nav 의 코드는 직관적이지 않게 코드가 짜여졌다. import React, { useState, useRef, useEffect } from 'react'; import LoginModal from '../Modal/Lo..
