목차

<aside> 💡 typescript, vite, zustand, react-query, yorkie, code mirror, sockjs, stomp, react-arborist, xtermjs

</aside>

Vite

<aside> 💡 역할 빌드 툴

</aside>

<aside> 💡 선택 이유

• **사전 번들링, Native ESM**을 이용해 소스 코드를 제공

  ⇒ 서버 구동 속도 향상

• ESM 활용으로 빠른 소스코드 갱신 </aside>

상태관리 [ zustand + react-query ]

→ 상태관리를 나눠서 사용하는 이유 : 서버 상태와 클라이언트 상태의 분리

1. zustand

<aside> 💡 역할

• 컴포넌트 외부에서의 상태 관리 </aside>

<aside> 💡 선택 이유

https://npm-compare.com/@reduxjs/toolkit,zustand,recoil,jotai,valtio/#timeRange=THREE_YEARS

• 간단하고 직관적인 API: redux와 기능이 똑같지만 훨씬 문법이 쉽고 간단해 빠르게 배우고 프로젝트에 사용할 수 있다, 상태를 생성하고 업데이트하는 것이 직관적이고 복잡하지 않다.

• 훅 기반: React 훅을 기반으로 하기 때문에, React의 최신 기능과 잘 통합된다.

• 불변성 유지: 상태의 불변성을 유지. 이는 상태 업데이트가 예측 가능하고 디버깅하기 쉬워진다.

• 작고 가벼움: Zustand는 매우 작고 가벼운 라이브러리로, 번들 크기에 큰 영향을 미치지 않는다. → 성능에 민감한 애플리케이션에 적합.

• 중간자(미들웨어)와의 통합: Zustand는 다양한 미들웨어와 쉽게 통합될 수 있다. 이를 통해 로깅, 지속성, 비동기 작업 등 추가적인 기능을 손쉽게 구현할 수 있다.

• 컴포넌트 재렌더링 최적화: Zustand는 필요한 부분만 재렌더링되도록 최적화되어 있어, 불필요한 리렌더링을 줄여 성능을 향상시킨다.

• TypeScript 지원: TypeScript와 잘 통합되어, 타입 안전성과 함께 개발할 수 있다. </aside>

• React Query 사용이 적합한 경우 / 덜 적합한 경우

• 웹 기반 IDE 프로젝트에서 Zustand 사용 적합?

<aside> 💡 회의 후 최종 결정([프론트] 기술 스택 최종 선정 회의 )

웹소켓을 통해 실시간 데이터 통신을 하는 상황에서는 React Query 상태가 덜 적합 Web IDE 플젝에서 상태관리할게 많진 않지만 학습 측면에서도 간단한 상태 관리 툴 Zustand을 써보기로 결정!

</aside>