프론트엔드 개발은 화면에 보일 요소를 어떤 값을 기반으로 처리하도록(보이도록) 표현하는 행동이고 리액트에서 이 값의 성질은 props 아니면 state 으로 표현된다. 리액트가 관리하지 않지만 리액트에서 관리할 필요성이 있는 state가 한가지 더 있다. URL이다. 물론 프로덕트의 작동 방식을 어떻게 결정하는지에 따라 다르지만, URL이 상태가 될 수 있는 기획은 정말이지 많을 것이다.
유저가 iphone을 입력하고 3페이지에 있는 내용을 URL로 복사해서 공유하도록 해주세요! 라는 스펙이 결정됐다고 해보자. 그러면 URL에는 쿼리스트링으로 검색어에 관한 키와 값, 페이지에 관한 키와 값이 있어야 한다. 예를들면 다음과 같다.
https://service.xyz/products?q=iphone&page=2
어떤 라이브러리나 프레임워크를 사용해도 URL의 값을 기반으로 뭔가를 보여주려면 쿼리스트링에 대한 정보를 가리키는 값을 참조해야만 한다. 대표적으로 URLSearchParams 을 사용해볼 수 있다. 이 값은 Mutable한 객체이기 때문에 각 라이브러리가 추구하는 방향에 맞게 끼워주는 작업을 해야만 한다.
React/React-DOM에서 가장 많이 사용하는 네비게이션 라이브러리는 React-Router 이다. 만약에 SPA를 개발하면서 해당 라이브러리를 사용한다면 useSearchParams() Hook을 적극 활용해보자.
URL을 상태로 두고 라이브러리에서 이를 캐싱했다고 치자. 그러면 이 값을 토대로 뭔가를 그려내야 하는데, 그 전에 반드시 해야할 것이 있다. 각 쿼리스트링의 값이 유효한지를 판단하는 것이다. 어떤 값의 유효성을 판단하는 기준은 2가지로 생각해보면 좋은데, 하나는 자바스크립트 세상(클라이언트)에서 말도 안되는 값이 나왔는지를 보는 것이고, 하나는 서비스 세상(백엔드)에서 유효한 값이 나왔는지를 보는 것이다. 전자는 데이터 타입과 범위를 체크하는 것이고 프론트엔드 개발자가 주도적으로 할 수 있다. 근데 후자는 직접 백엔드 서버에 찔러봐야 한다. 왜냐면 그 값에 대한 유효성이나, 실제 응답 데이터가 있는지 없는지는 백엔드에서만 처리할 수 있기 때문이다. 따라서 후자의 경우 프론트엔드 개발자는 선제적인 생각을 하기보다는 응답 데이터 도출 이후 우아하게 서비스 플로우를 그리는 방법에 대해서 생각을 하는 편이 더 바람직할 것이다.
유효성 검사 말고 또 고려해볼만한 것은 데이터를 어떤 절차를 걸쳐서 수정할 것인지다. 일단 페이지네이션 버튼의 경우 인터렉션의 주기를 쓰로틀링/디바운스로 관리해볼 수 있고, 검색어를 입력할 때마다 쿼리스트링이 바뀌는지 안바뀌는지도 확인해보는게 좋은 듯 하다.
끝