I have a state management solution in React that is infinitely simpler than Redux, less restricting than React Context, more lightweight than Zustand, and is as easy as using the standard React State hook. This solution makes React state global and very easy to manage. By the end of this video, you'll never want

to go back to anything else. What is this solution that I'm talking about? I'm talking about using Atomic State. The idea of Atomic State is very simple: state is stored in what is called atoms. Atoms are just units that contain a single piece of state. Anywhere in your

app and component, you can use an atom, and that atom will look the same anywhere it is accessed. If I change the value of the atom in one component, it updates in real time in every single other component. So it is literally like using regular React state, meaning that

you use the state hook, except that it is global. That's all Atomic State really is. It allows components to communicate and share state very simply. The library that has an incredibly simple yet effective implementation of Atomic State is Jotai. It is so simple that the main documentation is made up of four main

pages, all of which are really short and very straight to the point. I'll show you exactly how it works and exactly how to use it. As always, when working with some external library, we'll first need to import it into our code. In our terminal, we can get it installed by running `npm i

jotai`. Once we have Jotai installed, it's incredibly easy to use. No big config files or anything else that we need to mess with. The first thing that we need to do is initialize an atom, which is what we call pieces of Jotai state. We can

do this by simply writing `const` name of the atom, which we will call `countAtom` equals, and then we're going to call the `atom` function from `joai`. Make sure we get this atom imported from `joai`, and then in here we can pass in whatever we want the

initial value to be. For our case, since we're using a count, we will start it at zero. It's important that we initialize this outside of a React component, that way it only gets initialized once. Now, in order to use this atom, we can use the `useAtom` hook inside any React component

which, for the purpose of your understanding, is used identically to how `useState` is used to make a count state in our app. We can simply go into the `App` component here, and we can write `const [count, setCount] = useAtom`. As you can see, this is

identical syntax to how we use the `useState` hook in standard React. The only difference now is what we pass into these parentheses here. Instead of passing in the initial value, we already did that, we just need to pass in the atom that we created, which we called

`countAtom`, and we'll make sure we also get this `useAtom` hook imported from `joai`. Now we can use `count` and `setCount` exactly how we would use normal `useState`. This is the state itself, and this is the setter function for the state, and

here down below I set up a very simple scenario. I just have a `div` that has a `span` that is displaying the count, and I have a button here that whenever it is clicked will increment the count by one. And as you can see if I go over here and

test it, it behaves exactly like you would expect normal React state to behave. The only main difference being that we initialize it as an atom outside of the React component first, and then whenever we want to use that state inside of a React component, we can just

call the `useAtom` hook, pass in the atom, and then it acts essentially identical to `useState`. So what's the hype all about then? Well, now this state can be used globally, absolutely anywhere in the app, and it still behaves just like `useState`. Let's say now I have two

components being rendered out: one that will display the count, `DisplayState`, and one that will increment the count, `IncrementState`. It is legitimately the exact same thing we just had except we've just extracted the logic into two completely separate components. If we want to get access to this count state

in the component that is displaying it, we can again just do the same thing we did up top, just make a `useAtom` call like this to get access to the count, and we can do the exact same thing in `IncrementState` so we can get access to

the `setCount` function. And now if we save it, we should be good to go. I can go over here and test it, and you can see it behaves in the exact same way, despite the fact the logic for showing the count and setting the count is contained entirely in

separate components. There's a quick optimization thing that we can do. If we go into the first component, `DisplayState`, that is just displaying the count out, you notice that we're not using this `setCount` function. If we're using the state, but we're not

using its setter function, we could actually go ahead and delete these square brackets here and instead of using `useAtom`, we could use another function from `jotai` called `useAtomValue`. This just gets the state itself, not the setter function, so we can get rid of

this to just get access to the count. This `useAtomValue` just returns the state so that way you're not wasting space and destructuring a function that you won't actually use. The exact same thing goes for if you're only using the setter function like in this example

right down here, for example, in this component we're not actually using the state, but this can actually run into an optimization problem because we're using `useAtom`. This component is going to rerender every single time `count` changes, but this component doesn't need to

render at all. To fix this, all we have to do is just like last time, we can remove the brackets here and instead of using `useAtom`, we can use `useSetAtom`. And again, if we save it, this will behave the exact same way as before. We've just

optimized it so that we are not destructuring functions or state that we're not going to be using. So basically, long story short, if you're going to use both the state and the setter function in the same React component, you can use it exactly how you do `useState` and you

would do it like this, using `useAtom`. If you're not doing it this way and you just need the setter function, you can get `useSetAtom`. And if you just need the state itself and not the setter function, you can do `useAtomValue`. Now, even though this example is super, super

oversimplified, we've just effectively created global state that works between components without having to use props at all. To prove to you that this state is truly global and is updated in real time, I'm going to take this stuff from display state, I'm going to go back into

our app up here, I'm just going to copy and paste it up into here. Let's move this span back down into here, get rid of this return here, and now we are displaying the count in both the app component and in the display state component. So if I go ahead and save this, 

now you'll see we have two numbers here. If I click increment, notice how it increments in both of them at the exact same time. So it's as if app and display state were both sharing the exact same piece of state. Pretty cool, right? There's no massive setup process like Redux or 

other popular state management tools and no having to do some strange wrapping around your component to make context providers. Just atomic state that behaves like useState and is global. I want to make a quick note that normally you're not going to have all your components in 

the exact same file. So this atom probably shouldn't be there either. What I normally do is I would take this and in a separate file that I usually call atoms.ts or something along those lines, I would have this definition for the atom actually in here. I would just 

export it, make sure this atom is imported here, and then wherever I want to use this atom, I can just go into into that file and I can just go ahead and import countAtom from atoms, and then everything will behave in the exact same way. I'll give you another simple example.

to show you exactly how the state is actually global. So I've written this code here in our app. We just have a navbar that is at the very top of our page, which is this purple navbar you see here on the right-hand side. And then

we have this dashboard, which is this green box over here. Inside that dashboard is a card here, and inside that card is the button, and that button is the one that says 'Click me.' And it looks something like this. So essentially, we have a navbar plus three nested

components inside of dashboard. I have a file here called atoms.ts, and in here we just initialize an atom called color atom that we are defaulting to the string 'purple.' All that I want to do in this entire scenario is make this button right here that says 'Click me' change the

background color of this navbar up top whenever it is clicked. If we navigate to our button component, you can see that I already have most of the logic set up minus actually setting the color, which we'll do right now using Jotai because we're only going to be using the atom

setter function in this component up here. In this component, let's just make a setter function for our atom by typing `const set color = useSetAtom` because again, we're only using the setter function, not the actual state itself. And then we can pass in `color atom`, and again we want to

make sure both of these things are imported from their respective places. And all that this code is doing in this `handleClick` down here is it's taking a random color by just taking this array right here of rainbow colors that we have, and it's selecting a random one, and

then it is calling `setColor`, which is the function that we just created, to whatever random color was chosen. Which means that anytime `setColor` is called, like in this button, and this button is actually clicked, then we are going to set the `color` atom to one of these

colors right here. If I go ahead and save this and head to our navbar where we actually care about getting the color itself, we also have most of the logic setup in here. We just need to get the color out of the `joai` atom. We can do

that by going up here and just writing `const color = useAtomValue` and again, it's `useAtomValue` instead of `useAtom` because we're just getting the state itself, not the setter function, and we will pass in `colorAtom`. And now we have access to the color, which is in the form

of an atom though. Just so we're entirely on the same page, this `Navar` is simply getting the color, and the button is simply setting the color. Now our background color is getting set to whatever color is in the `color` atom, despite the fact that these two

components, the `Navar` and the button, are two entirely separate components that are multiple layers of parts. We've connected them with shared state in basically two lines of code. If I save this now and I go over to our site and I start clicking on this, notice how the

navbar is changing color. Again, in this button component here, we are actually setting the atom every time it is clicked, and then the navbar is receiving that change and it's updating its background color using the style tag. It's pretty neat that we're able to connect these so easily. The very last

The thing that I want to cover in this video is how to take one atom and use multiple instances of it in different places at the exact same time. For example, let's say you have 10 card components that all use the exact same atom where they can

all display the atom value and increment it. But wait, if all 10 cards are rendered at the same time, all referencing this one state atom, they're all going to be competing for this atom at the exact same time. I can show you exactly what I

mean by, if I click one of these buttons here to increment the count on one card, it increments the count for all of them. Any of the cards will increment every single other card. And 99% of the time this is exactly what you want because the whole

point of using Recoil is to make React state global. Sometimes, however, the situation might arise where we want to use atoms but not completely global, like restraining each atom to an individual card. Well, your first obvious thought might be to just make the state an actual use state in each card to keep it

local. But this card example is super, super oversimplified. What if in an actual scenario you had cards like this that were actually really complex components that had a ton of children and you wanted to let each card have its own atom to make state sharing easier within the card? In other words, scoping

each atom to a specific component so it's not entirely global. If you go this route, the solution to this problem of competing for the same instance of the same atom is not to go into this atom file and copy and paste this 10 times. Recoil actually has a feature called

scoping that allows us to use the same atom in multiple places at once without risk of having them overlap or interfere with each other. The way we do this is by using a component called scope provider. How we implement this is very very simple. We can open up our terminal and

we can run npm i joai-scope just like this. If I now want every card to have access to this count atom, but each count atom should stay unique to its own component or in other words, scoped to its own component, all we have to do is wrap the

component in this scope provider right here, which we can import from joai-scope, the library we just installed. We want to make sure this has an opening and a closing tag and that we wrap our card inside of it. The very last thing we need to do is just give this a prop that we

are going to call atoms. This is an array by default, so even if we only have one value we'll still want to make them square brackets and then we will just pass in count atom, which we can just import from atoms. What scope provider does is make it so that the atom we

passed down stays completely scoped to everything that is a child of it, but it doesn't exist outside of that. In our case, this is the card component. They call this a subtree in joai, referring to this child and all its possible children or adjacent components. By mapping over

10 different cards, we have created 10 of these scope providers, each with their own card, meaning we now have 10 scope subtrees. So they are all using the exact same atom, the count atom, but we have effectively created 10 instances of that atom. And that is actually all it

takes to do this now. If I go ahead and save this file, all of our state for our card is going to reset. And if I click on a single card, it's only going to increment the state for that card. Almost exactly like `useState` works if we were

to do a `useState` hook and each card individually and just scope the count locally. However, we're using an atom and it's behaving in that exact same way. So this is how it behaves with scoping, and this is how it behaves without scoping.

If we just remove this how we had it before, oops, like this, it behaves just like this. So again, no scoping, making everything global is the default behavior of `jotai`, and that is probably what you're going to want the vast majority of times. However, if you do have an

instance where you need to scope state to a specific component, like in our case, the card, we can do it just like this. And now the state is local despite the fact that we're still using atoms. In summary, `jotai` is amazingly simple for state management. You make an atom using the

atom function from `jotai`, and then to mimic the exact same behavior as `useState` but as global state with atoms, you can use the `useAtom` hook where you just pass in the atom that you initialized. Then you have access to the state itself

plus `set` function, and again behaves exactly like you would expect `useState` to behave. If you want to just get the state, you can use `useAtomValue`. If you want to just get the setter function, you can use `useSetAtom`. If you want to make

multiple instances of the exact same atom you can use the scope provider and wrap the component or subtree you want to use them in and that's really all there is to Jotai it really is that simple I hope you're able to learn something from this video and I honestly

encourage you to use Jotai if you're wanting an incredibly simple way to handle global state in React I think you'll find it very useful and very nice to use please let me know in the comments your thoughts on it take care everyone and I'll see you in the next

State Management in React Will Never Be the Same

Austin Davis

Jotai는 간단한 React 상태 관리 솔루션으로, Redux보다 간단하고, React Context보다 덜 제한적이며, Zustand보다 가볍습니다.

원자 상태는 앱 전체에서 액세스 가능하고 일관된 단일 상태 단위인 원자로 상태를 저장합니다.

한 컴포넌트에서 원자를 변경하면 모든 컴포넌트에서 실시간으로 업데이트됩니다.

Jotai의 원자 상태 구현은 간단하고 배우기 쉽습니다.

Jotai의 설치 및 기본 사용법을 설명합니다.

Jotai의 `atom` 함수를 사용하여 원자 초기화하기.

React 컴포넌트 내에서 `useState`와 유사한 `useAtom` 훅을 사용합니다.

사용 아톰`을 사용하여 카운터를 증가시키는 예시입니다.

여러 컴포넌트(`DisplayState`, `IncrementState`)에서 글로벌 스테이트 사용량을 보여줍니다.

사용 아톰 값`과 `사용 세트 아톰`을 사용한 최적화 기법을 소개합니다.

글로벌 상태 및 실시간 업데이트

여러 컴포넌트에서 글로벌 상태의 실시간 업데이트를 시연합니다.

원자를 별도의 파일(예: `atoms.ts`)로 구성하는 모범 사례에 대해 설명합니다.

중첩된 구성 요소(탐색 모음, 대시보드, 카드, 버튼)가 포함된 더 복잡한 예가 표시됩니다.

이 예는 Jotai를 사용하여 버튼 클릭으로 탐색 모음 색상을 변경하는 방법을 보여줍니다.

여러 원자 인스턴스 및 범위 지정

여러 컴포넌트가 동시에 동일한 아톰 인스턴스를 사용할 때 발생하는 경쟁 문제가 해결되었습니다.

'조타이 스코프'를 사용하여 특정 컴포넌트에 원자 범위를 지정하는 개념을 소개합니다.

'조타이 스코프'의 설치 및 사용법을 설명합니다.

범위 제공자`를 사용하여 다른 컴포넌트 내에서 동일한 원자의 독립적인 인스턴스를 생성합니다.

범위 지정 결과: 이제 각 카드가 독립적인 카운트 상태를 갖습니다.

Jotai의 핵심 기능을 요약합니다: atom`, `useAtom`, `useAtomValue`, `useSetAtom`.

동일한 아톰의 여러 인스턴스를 생성하기 위해 `ScopeProvider`를 사용하는 방법에 대한 설명입니다.

React에서 글로벌 상태 관리를 위해 Jotai를 사용하도록 권장합니다.

State Management in React Will Never Be the Same

State Management in React Will Never Be the Same

스크립트