Storyly 에는 두 가지 매우 다른 React 프로젝트가 있습니다. 하나는 "대시보드"이고 다른 하나는 "스튜디오"입니다.

이 두 프로젝트는 기술적 과제뿐만 아니라 목적도 다릅니다. 대시보드는 사용자가 앱, 인스턴스, 스토리 그룹, 설정 및 통합을 관리하고 분석을 보는 CMS 프로젝트입니다. 반면에 Studio 프로젝트는 디자인 도구입니다. 이를 통해 사용자는 사전 정의된 요소를 사용하여 빈 캔버스에서 스토리를 디자인할 수 있습니다.

기술적인 수준에서 짐작할 수 있듯이 대시보드는 주로 서버 측 데이터이고 스튜디오는 주로 클라이언트 측 데이터입니다. 그래서 분류할 때 기술적 측면보다는 프로젝트의 목적에 초점을 맞추고 있습니다.

우리는 프런트엔드 개발자로서 순전히 기술적인 측면에서만 기술적인 결정을 내려서는 안 됩니다. 팀, 현재 및 가능한 사용자, 프로젝트의 의도된 미래 및 회사 문화를 포함하여 고려해야 할 다른 많은 측면이 있습니다. 이 모든 것은 의사 결정 과정에서 근본적으로 기술 솔루션에 영향을 미칩니다.

귀하의 작업이 프로젝트에 대한 상태 관리 솔루션을 선택하는 것이라고 가정해 보겠습니다. 서로 다른 단점과 장점을 가진 많은 제품이 있습니다. 프론트엔드 생태계의 상태 관리 주제는 "프레임워크" 주제 다음으로 가장 많은 솔루션을 제공한다고 해도 과언이 아닙니다.

기술적 장단점만 고려한다면 성능 수치, 솔루션의 사용 용이성, 솔루션의 커밋, 별 및 문제 수를 확인하게 될 것입니다. 그리고 이것들은 모두 라이브러리를 선택할 때 유효한 포인트입니다.

기술적인 관점에서 두 코드베이스에서 사용할 상태 관리 솔루션을 보면 Zusstand 또는 Jotai를 사용하는 경향이 있습니다. 잘 관리되고 사용하기 매우 쉬우며 성능이 뛰어납니다. 쉬운 결정이었죠?

음, 우리는 상태를 관리하기 위해 두 코드베이스 모두에서 전능한 Redux를 사용하고 있었고 프로젝트의 이 부분이 필요 이상으로 확장되었기 때문에 단순화해야 했습니다. 많은 버그의 주요 원인이었습니다. 저는 즉시 "오 훌륭합니다. 두 프로젝트 모두에 Zusstand를 사용해야 합니다. 놀랍기 때문입니다!"라고 생각했습니다. 하지만 한 걸음 물러서서 조금 더 반성했습니다.

마이그레이션 프로세스

처음에 설명했듯이 두 코드베이스는 매우 다릅니다.

대시보드는 서버 측 데이터에 대한 매우 미묘한 변경 및 업데이트와 함께 서버 측 데이터를 사용자에게 보여줍니다. 분석 데이터, 목록 및 계산된 통계가 포함된 페이지가 많이 있습니다. 이 프로젝트의 미래도 비슷할 것입니다. 많은 통계와 목록이 있는 CMS와 유사한 대시보드. 그래서 데이터 캐싱, 캐시 무효화, 네트워크 워터폴, 실시간 데이터 업데이트, 낙관적 업데이트 등을 고려해야 했습니다. 이러한 주제를 염두에 두고 상태 관리 솔루션(Redux)을 변경할 필요가 없다고 결정했습니다. ); 어떤 상태도 "관리"할 필요가 없기 때문에 대시보드에서 제거하기만 하면 되었습니다.

그런 다음 SWR , TanStack Query 및 RTK Query 와 같은 데이터 가져오기 솔루션을 살펴보았습니다 .

SWR은 안정적인 변이 흐름이 없고, RTK Query는 Redux Toolkit과 너무 결합되어 있으므로 TanStack Query로 진행했습니다.

TanStack Query는 캐싱, 무효화 및 변형 흐름으로 서버 측 데이터 관리의 오버헤드를 제거합니다. 항상 관리할 상태가 있지만 항상 직접 관리할 필요는 없습니다. 우리는 이 무거운 작업을 TanStack Query에 제공했고 뒤돌아보지 않았습니다. 우리는 Redux와 TanStack 쿼리를 병렬로 사용하고 Redux 상태에 아무것도 남지 않고 안전하게 할 수 있을 때까지 Redux 상태를 하나씩 TanStack 쿼리로 이동하고 있습니다 yarn remove.

React Hooks를 사용하면 병렬로 사용하고 점진적으로 논리를 이동할 수 있습니다.

그러나 스튜디오에는 서버로 전송하기 위해 생성된 순전히 클라이언트 측 데이터가 많이 있습니다. 미리 정의된 요소로 스토리를 완전히 디자인할 수 있습니다. 캔버스에서 이동하거나, 크기를 조정하거나, 필요에 따라 콘텐츠를 변경하거나, 스토리 배경 이미지를 변경하거나, 배경에 비디오를 넣을 수도 있습니다. 그리고 저장을 위해 최종 데이터를 서버로 보내기 전에 가능성은 무궁무진합니다. 이러한 모든 기능은 저장할 때까지 클라이언트 측 데이터입니다. 그리고 저장하고 돌아가서 편집하면 다시 서버 측 데이터에서 파생된 클라이언트 측 데이터가 됩니다.

가능한 기능에 대해서도 생각해야 합니다. 변경을 실행 취소하는 기능, 손으로 그린 ​​그림 만들기, 스토리 간 디자인 전환… 가능성은 무한하지만 가능한 모든 기능은 클라이언트 측 대용량 데이터입니다. 따라서 최대의 유연성을 위해 여기에서 상태를 "관리"해야 합니다.

Studio의 경우 이미 상태 관리 솔루션인 Redux를 사용하고 있었습니다. 그래서 저는 팀원들에게 "상태 관리를 수정하기 위해 무엇을 사용해야 합니까?"라고 질문했습니다.

모든 응답 후에 경로는 명확했습니다. Redux Toolkit을 사용할 것입니다 .

RTK(Redux Toolkit)는 개발자의 삶의 질을 향상시키기 위한 Redux 팀의 도구 세트입니다. 슬라이스를 사용하여 상점의 구성 및 여러 상점의 관리를 단순화합니다 . 그래서 우리는 이전 Redux 상태를 새로운 RTK 아키텍처로 마이그레이션했습니다. 우리는 이전 아키텍처와 새 아키텍처를 나란히 실행하고 상태를 리팩터링하는 동안 새 아키텍처로 이동하고 있습니다. 이 모든 것이 제품의 워크플로우를 방해하지 않으면서 빠르고 점진적으로 움직일 수 있게 해줍니다.

우리는 Redux 공급자에게 맞춤형 React Context를 전달하여 이 이전 아키텍처와 새로운 아키텍처를 병렬로 실행하고 있습니다 .

react-redux사용자 정의 컨텍스트를 Redux 공급자에 전달할 때 제공된 생성기로 모든 관련 Redux 후크를 생성하고 패키지 에서 직접 가져오는 대신 코드에서 사용해야 합니다.

우리의 장기 목표는 대시보드 프로젝트에서 Redux를 완전히 제거하고 Studio 프로젝트에서 "오래된" Redux를 제거하는 것입니다. 우리는 새로운 기능을 개발하고 버그를 수정하면서 만져야 하는 모든 파일을 리팩토링함으로써 이 목표를 향해 나아가고 있습니다.

이러한 중요한 기술 전환은 주로 두 가지 이유로 원활하고 점진적이어야 합니다. 첫째, 팀의 일상 업무를 점검하고 있습니다. 그들은 이러한 변경 사항을 기꺼이 받아들여야 합니다. 그렇지 않으면 성능이 크게 저하될 것입니다. 반면에 구축에 사용하는 도구를 좋아하고 도구를 방해하는 대신 도움이 된다고 한다면 성능이 크게 향상될 것입니다. 둘째, 제품은 계속해서 만들어져야 합니다 . 쇼는 계속되어야 합니다. 새로운 기능이 있어야 합니다. 앞으로 나아가야 합니다. 따라서 기술 전환이 제품 개발을 방해해서는 안 됩니다. 모든 변경 사항은 점진적이어야 합니다.

요약

개발자로서 기술적 결정을 내릴 때 작업 중인 프로젝트의 모든 측면과 함께 작업 중인 팀의 요구 사항을 고려해야 합니다. 이는 단순히 이러한 기술적 결정이 개발자뿐만 아니라 팀과 프로젝트에서 작업하는 다른 모든 사람에게 영향을 미치기 때문입니다.

기술적 변화는 어떤 대가를 치르더라도 점진적이어야 합니다. 이러한 변경 사항이 제품의 파이프라인을 차단해서는 안 되며 따라서 제품의 성공도 차단해서는 안 됩니다.

개발자가 생산성을 발휘하려면 개발자를 만족시키는 도구를 제공해야 한다는 점을 항상 기억하세요.