- YouTube
www.youtube.com
Jotai
ver 2.10.3 ∙ 2024.11.20 업데이트됨
개요
Jotai, React에서의 기본적이고 유연한 상태 관리 라이브러리. 전역 React 상태 관리에 원자적인 접근을 채택. React 컨텍스트의 추가적인 리렌더링 문제를 해결하고, 메모이제이션의 필요성을 제거하며, 선언적 프로그래밍 모델을 유지하면서 signals와 유사한 개발자 경험을 제공
관련 게시물
모두 보기토스의 오픈소스 생태계: 한국을 넘어 글로벌로
국내 개발자로서 자부심을 불어넣는 오픈소스 생태계가 있습니다. 바로 토스(Toss)가 주도하는 오픈소스 생태계 인데요.
es-hangul이라고 하는 한글을 다루기 위한 라이브러리는 이미 1,000개가 넘는 GitHub 스타를 획득했습니다. 또한 lodash보다 2배 더 빠른 유틸리티 라이브러리인 es-toolkit은 이미 6,100개의 스타를 받고 국내를 넘어 세계적으로 많은 개발자들의 관심을 받고 있는데요. 이번 토스 모닥불 EP.4 영상에서는 토스에서 오픈소스 생태계를 운영하는 개발자들의 이야기를 만나볼 수 있습니다.
특히나 주목할 만한 점은, 패널로 참여한 토스의 오픈소스 suspensive 를 운영하고 계시는 분인데요. 이 개발자분은 요즘은 필수로 사용되고 있는 TanstackQuery 의 최상위 기여자입니다. Jotai 외에도 토스 오픈소스에도 적극적으로 기여를하고 결국에는 토스에 합류하신게 참 대단하게 느껴지네요.
또한 오픈소스 생태계 구축을 통해 기술 커뮤니티에 긍정적인 영향을 미치고자 하는 토스의 노력도 대단한것 같습니다. 한국 개발 생태계의 경쟁력을 높이고, 개발자들에게 새로운 도전과 성장의 기회를 제공하는데 있어서, 토스의 이러한 행보를 응원합니다.
https://www.youtube.com/watch?v=SdBL-p597Dw
nextjs app router
많이들 사용하시나요? 사용한다면 어느 조합으로 사용 하고 계신지 궁금합니다. 주로 궁금한거는 기존의 v13 or v14, 기존의 css-in-js 사용이 불가능한 상황에서 스타일링에는 무엇을 사용하는지, 별도의 데이터 패칭 라이브러리(swr, tanstack-query)와 전역상태도구(zustand, jotai)를 사용하는지. 음 기존 page router 쓰시던 분들은 프로덕션 레벨에서도 마이그레이션 해서 사용중인지도 궁금하네요
추가로 특정 조합에 장점이 있는지도 궁금합니다
감사합니다!
관련 개발자 Q&A
모두 보기react에서 복잡한 상태를 관리할때.. 한번에 관리? 분리해서 관리? (jotai, recoil, useState)
안녕하세요 react를 이용해서 복잡한 작성 페이지를 만들고있습니다. 아래의 타입은 예시입니다. type payload = { name: string; message: string; type: string; url: { pc: string; mobile: string; }; contents: { images: { url: string; name: string; }[]; buttons: { name: string; url: string; }[]; }; conditions: { ... }, .... }; 위처럼 복잡한 데이터를 서버로 보내줘야해서 데이터를 관리해야하는데 현재는 페이지내에 구조가 복잡하고 컴포넌트도 매우많아 props drilling이 너무 심해질거같아서 recoil, jotai와 같은 상태관리 라이브러리를 이용해서 작업을 진행하고있습니다. 이러한 상황에서 관리하는 데이터를 한객체에 모아서 관리하는게 좋은지 아니면 const nameAtom = atom(''); const messageAtom = atom(''); const typeAtom = atom(''); const urlAtom = atom({ pc: '', mobile: ''}); .... 처럼 일일히 쪼개서 관리하는게 맞는 방향인지 모르겠어서 질문드립니다 ! (사수가없어서 물어볼곳이없어요...) 현재는 아래와같이 쪼개서 작업한뒤 submit시에 합쳐주는 방식으로 구현해놓았는데 atom 갯수가 20개 정도 되버리니까 너무 복잡해보여서 이게맞나... 싶어서 질문드리게되었습니다.
안녕하세요! 상태관리 관련 자주 고민하게되는 부분에 대한 질문을 주셨네요! 사실 완전 정답은 없기 때문에 앱의 성능 최적화와 DX 사이에서의 적당한 타협점을 찾는게 나름의 요령 아닐까 싶습니다🥲 먼저 질문자님의 방식처럼 atom을 나눠 사용하게 되면 컴포넌트 별로 필요한 데이터만 사용하고 업데이트 하며 렌더링을 최적화하기에 용이하다는 장점이 있지만, 말씀하신대로 관리하기가 너무 복잡해질 수 있습니다. 반대로 한 객체에 모아 관리하게 되면 사용은 편리하지만, 하나의 프로퍼티만 업데이트 되어도 그 객체를 참조중인 모든 컴포넌트가 업데이트 된다는 점에서 렌더링 최적화에 대한 고민이 생기기도 합니다. 일단 위와 같은 상황에서 저의 추천은 "한 객체에 모아 관리하기" 입니다! 후에 어차피 submit시에 내용을 다시 합쳐줘야 하는 구조라면 굳이 다 분리 시켜놔야할 이유가 없기도 하니까요. 대신, 렌더링 이슈가 고민이 된다거나 프로퍼티 개별관리가 필요한 케이스에는 selector 와 selectorFamily를 활용하시면 될 듯 합니다! (Jotai에서는 selectAtom 등 활용) 공식문서를 찾아보시면 제일 좋고, 관련해서 간단한 사용법 정리해둔 블로그를 찾아서 함께 공유드려요! https://velog.io/@2ast/React-Recoil-selector%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94%EC%97%90-%EA%B8%B0%EC%97%AC%ED%95%98%EA%B8%B0
Jotai가 Provider 없이 컴포넌트간의 atom 공유가 가능한 이유
상태관리 라이브러리인 jotai를 사용할때, Provider로 감싸지 않아도 atom 선언과 useAtom을 이용해 컴포넌트간의 공유가 가능한걸로 알고 있는데, 그 이유가 무엇인가요? 내부적으로 context api를 사용하는걸로 알고 있는데 provider가 없이 어떻게 가능한걸까요?
프론트엔드 유효성 검사 어떻게 하시고 계신가요?!
진행하는 프로젝트에서 form에 관리하는 state들이 10개정도되는 편이라 recoil 이나 jotai로 state관리를 진행하고있습니다. 유효성검사가 필요한 부분들은 마찬가지로 const [nameError, setNameError] = usState('') 이런식으로 선언하여 name 변경시 setNameError(value ? 'error message' : '') 형식으로 관리하고있습니다. 각 state마다 이렇게 처리하니 추후 복잡해보이기도해서 더 좋은 방법은 없는지 어떻게 처리하고계신지 궁금해서 질문남깁니다 !
따로 라이브러리 사용하지 않더라도 특별한 예외 케이스가 아니라면 nameError 라는 state를 따로 만들 필요는 거의 없습니다(만들어야 하는 경우도 있긴함) name state를 가지고 nameError 또는 nameErrorMessage 등의 변수를 만들어서 쓰세요
nextjs app router
많이들 사용하시나요? 사용한다면 어느 조합으로 사용 하고 계신지 궁금합니다. 주로 궁금한거는 기존의 v13 or v14, 기존의 css-in-js 사용이 불가능한 상황에서 스타일링에는 무엇을 사용하는지, 별도의 데이터 패칭 라이브러리(swr, tanstack-query)와 전역상태도구(zustand, jotai)를 사용하는지. 음 기존 page router 쓰시던 분들은 프로덕션 레벨에서도 마이그레이션 해서 사용중인지도 궁금하네요 추가로 특정 조합에 장점이 있는지도 궁금합니다 감사합니다!
저는 주로 tailwind-css를 이용하여 개발하고 있습니다. 저는 tailwind를 선호하는 편이지만 호불호가 강한 프레임워크이다보니 선호하지 않으시는 분들의 경우에는 제 주변에선 주로 scss 를 사용하시는 것 같아요 그 외에도 css-in-js의 스타일링 방식을 매우 선호하시는 분들의 경우에는 주로 css-in-ts라고도 많이 부르는 것 같은데 빌드타임 css-in-js 를 표방하는 프레임워크들을 사용하실 수 있습니다. 이것은 생각해보면 간단한 이유인데 css-in-js 방식을 채택하는 이모션, 스타일드컴포넌트와 같은 라이브러리들을 서버에서 사용할 수 없는 이유는 런타임에 css를 동적으로 평가, 생성하는 과정을 수행하기 때문입니다. 따라서 코드를 실행시켜봐야 css를 생성할 수 있다는 것인데 웹환경 자체에 대한 의존성이 있는 코드를 서버에서 실행시켜보는 것이 가능하지 않기 때문에 css를 평가할 수 없는 것이죠 따라서 코드를 실제로 실행시켜보지 않더라도 css를 정적으로 평가하고 생성할 수만 있다면 서버에서도 사용할 수 있습니다. 그러한 개념의 일환으로 빌드타임 css 프레임워크들을 생각할 수 있는 것입니다. 대표적으로 pandacss , 바닐라익스트랙트 등이 있는데 저같은 경우엔 pandacss의 개발자 경험이 괜찮았던 것 같습니다. 상태관리에 대한 질문도 남겨주셨는데 서버사이드 환경에 익숙치 않으신 분들의 경우 쉽게 의문이 생길 수 있는 영역입니다. 결론부터 말씀드리면 대부분의 경우 페칭라이브러리, 전역상태관리라이브러리는 사용해야합니다. 이것은 next.js와 같은 서버사이드에서도 동작하는 프레임워크를 사용하게되면 실제로 상태를 다루는 영역이 "서버"와 "클라이언트" 둘로 나뉘게 되기 때문인데요 서버쪽의 상태를 관리하는 것은 여러가지 솔루션이 있지만 서버쪽의 상태만 관리한다고해서 클라이언트측의 상태가 필요없어지는게 아니기 때문입니다. 서버상태까지 리액트쿼리로 관리할수도있고, 안할수도있습니다만 저같은 경우엔 클라이언트 상태는 주로 리액트쿼리를 이용하여 관리합니다. 조합은.. 상황에 따라 달라지거나 취향인 부분이 많을 것 같네요
React 상태관리 라이브러리에 대해서 질문있습니다 !
안녕하세요 새로운 프로젝트를 들어가기전 라이브러리를 고민중입니다. 한번도 사용해보지않은 zustand 혹은 jotai 를 사용해보고싶은데… 보통 zustand나 jotai를 사용할때 비동기처리 같은 부분도 해당 라이브러리만 이용하는지… 아니면 redux나 react-query 를 같이 사용하는지 궁금합니다…! 그리고 다른분들도 선호하시는 라이브러리가 있으시면 알려주십셔 !!! 감사합니다 !!!
굿닥에서 프론트엔드개발자로 계신 오웬님의 글이 좋아 공유드립니다. 저는 주스텐드를 사용하고 있는데요. 리액트쿼리와 함께 사용하고 있습니다. 내부 상태 관리용으로 주스텐드 외부상태 관리는 리액트쿼리가 담당하는 식으로요. https://yozm.wishket.com/magazine/detail/2233/
