I have been working with React for about 4 years and recently started teaching React to juniors. Today I feel like I am a junior again 😀 Thanks for sharing this amazing content Jack!!
Jack, thank you for all your videos! Thanks to you I leveled up my skills and got to a senior position! I hope you come out with a course soon describing all of the mid/advanced React concepts, best practices, project structuring, when and how to use 3rd party libraries like RQ, state management, and all those good stuff. I would literally pay anything for that!
React Query as some excellent documentation -- dedicate a day to browse through it and you will be surprised what you will be able to accomplish with that library. My companies application has some complicated state between the server and client and react query has made it so easy to manage state, handle mutations + hydrating the client. It only took me a few days of going through the documentation and now I feel fluent with talking to that library -- it shouldn't take you very long if you dedicate a few hours to it.
@@jherr I have watched this video =). When I first used RQ I thought it was more for data fetching and managing it's state but I have used it to simply manage state from one component to another and mutate that state. I love RQ it's such a useful tool. Honestly Jack I have learned a lot through your content and have taken patterns you have provided and I use them daily =).
I've made this "fast context" solution a few times. The thing is, you don't even need any Provider here. You can just use any external object with the same pub/sub api, since we're triggering re-renders manually, so this useStore hook can pick its store from wherever, not just from a context. Also, when you do useRef(new Set(...) you're re-creating this Set for every render of that custom hook. It won't care about the value but still, it's "cleaner" to do: if (!store.current) store.current = new Set(...) to make it just happen once. Otherwise awesome content Jack. I love the useSyncExternalStore abstraction to get rid of setting up local states manually. Feels safer also to have React internals take care of that part.
The Provider and the `useStore()` hook are fine. They decouple the components from the source which is useful for developer tests and for inclusion in design system guides. However, especially as `useSyncExternalStore` is being used, there is no need for `useStoreData()` to be a hook so it can just be implemented as a vanilla `createStore` function without all the `useRef()`and `useCallback()` complexity. Also since the properties in the created { set, get, subscribe } object are stable through the lifetime of the application it makes sense to just bind it to a `store` variable within the closure created by `createFastContext()` that both `createContext` and `StoreContext.Provider value` can use to eliminate the initial `null`.
@@PeerReynders "so it can just be implemented as a vanilla createStore function without all the useRef and useCallback complexity" -- are you suggesting to just use `let var = ...` variables instead of useRef? I.e. rewrite createStore to be pure javascript, no react?
Jack writing a solid library in real-time is just incredible. Love to see it and super empowering for anyone looking in to see that you don't need 100 npm packages in your project to make something super solid and robust! The more code that you can own and understand yourself now means more flexibility and creativity later as you figure out what your project is and can be. Also helps even if you're using pre-built libraries to explore in code yourself to know exactly what you want out of a library and cut through all the bullshit you don't need.
This was so instructive, I love how you teach not only these cool patterns but the reasoning behind them AND colol little details like the Partial there. Thanks Jack!
Let's make react context great again :) I think the actual implementation of context should be something like this and the current version is really deficient. And again really enjoyed the way you went step by step, improved the solution, and made it generic. It not only helps with understanding the process but also demonstrates how to eat an elephant. Thanks again.
Small remark: if you are storing your data in a ref in any case, there is no need to overwrite it with a new object that destructures both the current data and the updates, instead use Object.assign to copy over the partial values for a little better performance. Otherwise, this is a nice pattern and you've done a great job showing how it comes together, @Jack Herrington!
How ? [line-22] if I use Object assign ------> store.current = Object.assign(store.current, value); but TypeScript says (Type 'Partial' is not assignable to type 'Store')
Using React Context and patterns like what you have shown too me is more than enough for a bunch of use cases. I'm glad to see a video like this so I can point some of our developers we hire to this video to get a gist of what I call baked into React for global state management using HOC patterns. Im sure I'm not alone with feeling like this but once you learn a few state management patterns/libraries (Zustand, Jotai, React Query, Redux, React Context patterns) I enjoy using almost all of them and when it comes to making a choice on which one to use I often struggle to make a choice because they are all great IMO (for React apps) Thanks again for all the content you provide to the React Ecosystem it's great, absolutely love the content -- your a great guy for all the work you provide towards developers coming into this gig.
What kind of solution is this!! You just made my understanding of react to another level! Thank you so much, I'll definitely come back to watch this video again and again.
You have almost introduced fine-grained reactivity to React like it is for Solid and Svelte. Fantastic job 🔥 Wondering why React did not yet implement such a thing lol
I haven't seen the video yet, but based on previous videos I know it's gonna be amazing. I like that you don't only show HOW to do it, but WHY you do it. Here, you dropped this, king 👑
Omg just realizing that context is initially designed for slow-changing-stuff really enhanced my mental model of React. Thanks so much for your videos, you are the coding buddy I don't have :)
I'm really interested in seeing how this would get involved in a more complex application, please do so Jack. For example: - involving async actions - actions that need states from different stores or fields of store
This is an absolutely incredible tutorial! I learned a ton from this! I understand context, useRefs, and how components rerender SO much better now! Thank you!!!
Hey man, please never stop making videos. I learn so much from you. It has been a year since I've been working full time on react apps and there hasn't been a day without something new. Thankyou.
I love it when these type of ideas come along. I wouldn't use it for state management, but it has a lot of potential when it comes to Multilayer contexts that I deal with at work. It piles up little by little. Thanks Jack
Thanks for the fantastic content! Love how you still get excited when your solution works (24:13). 😂 Even though you obviously prepped. Even though it's not unexpected. Keep up the great work!
I was playing around with your code and came to a realization that the magic is entirely in the useSyncExternalStore method and the context is 100% superfluous, it is not doing anything at all. In fact, useRef and useCallback are also redundant. With a few tiny tweaks this useful code became a game changer for me. Thank you for this video!
Do you have any examples I could look at. Sadly, just found this and am relatively new to Context - been using Redux and comparing if this could replace it.
In my experience, I use React context when it is limited in a very narrow part of the components tree, when the state to share is not internal and will wrap a big part of my application, I use Redux Toolkit, I found it very awesome. For server state management, react-query for sure.
My first comment to you. Your videos is super useful and straightforward. I like using Redux, but Context is super for local high state around piece of tree. I wish you GL and thanks for sharing your experience .
Love your content Jack, thanks for this great explanation! I am a React dev, I work with it every day, and this kinda of hassle that we have to go through to get this level of performance is one of my biggest pet peeves with the framework. For my freelance projects I use Svelte and I get all of that for free, it's glorious. Looking forward to a video on the new upcoming SvelteKit!
I see `useStore` is in the same scope as the components since they all live in the same file. But how could you extract useStore to use it in other places, splitting code into more failes?
That pub/sub solution is great! I'm relatively new to React and hadn't considered that as a way to manage state "globally" and only re-render components that need to. Thanks for sharing this Jack
I really love this combo. I'm going to use fast context in UI kit I develop (for fun and practice) as I see it reasonable to use React context instead of any 3rd party state management. Less dependencies better for UI kit. I made one modification, inside Provider component there are two providers now - one provides 'set', the other 'get' and 'subscribe'. And instead of useStore there are useStoreValue and useStoreDispatch now. There are cases when you have store setter that does not care about value, so component that uses setStore will never re-render as 'set' is always stable. Thanks for the video and solution it is awesome!
This is pretty awesome, I am curious how close a small lib like Zustand is basically just this general structure with a few more features? Good to see what's going on behind the scenes. Thanks for always sharing amazing content!
Jack, thanks a lot for making really excellent educational videos! This one is especially important, given how easy it is to misuse React context and end up being deep under a lot of performance issues. Thank you!
Woah Jack, you are a magician and even after watching you so much, I still can’t wrap my head over some of your concepts.. humbling experience this video was.. I will come to it again a little later in life..
I was able to predict what direction you were going to go as you went along. When I first started watching your channel a lot of what you talked about sounded like voodoo magic. The only reason I was able to predict before hand what you would do is because people like you are incredibly skilled and offer up high quality educational content. I often reference or recommend this channel to my coworkers. I really can't thank you enough and I still learned something new as I normally do with your videos. Thank you for being a part of keeping my skills fresh and staying highly motivated to stay curious.
The only part I didn't understand was a pub/sub model and how it works, maybe because I have never used it before. I believe I will watch this episode a few more times and read articles about how this pattern works. Thanks a lot for such majestic content, I appreciate it as other fellows here.
I once faced this challenge: 1) I fetched data from API 2) Based on that data, I should have rendered a slider for each item from a list. I didn't know the count on build time, I only knew it on run time 3) Based on current values of all the sliders, I should have calculated sum and some validation boolean (like isOverLimit or something) My initial naive way was to pass down value and onChange props from a container component. As expected, didn't go well at all. Slider can easily fire 1000 change events per second. All sliders needed to rerender. I was laggy and terrible UX. Second approach was to hack it with throttle. Each slider would have its own local state and once in a while (let's say once per 250ms), onChange was fired and calculation synced. Worked better, but it still needed to rerender all sliders, though not that often. Hacky, ugly, not nice. I did a quick research and and found Recoil. I implemented runtime atomic state for each slider, two selectors for calculated value, everything worked perfectly, only things that really changed had to be rerendered. Tried with 1000 sliders just out of curiosity, worked flawlessly, slide back and forth on 4K display, no lags, blazing fast. This solution looks good in a way that it could replace my solution entirely, without Recoil needed to be installed at all. Really nice. I like this ref - subscriber - selector approach. It's clean, neat and elegant. No hacks needed.
I really love the way you explain concept by doing step by step. It reminds me of Dan Abramov trying to re implement Redux from scratch. It make things clearer and straightforward. Really really enjoy your video format! Thanks!
Also one quick question: My team and I have started implementing the fast context in our app. But there is one thing we can't solve for a few days regarding the fast context. Actually, our app allows users to undo/redo all types of actions (e.g. input changes, deleting and adding things). For each change in the store we provide a command, the command contains three things: execute (that's how the store should change), undo function, and redo function. So basically, we do something like: const set = useCallback((command: Command) => { // alter the state using the command stack.current.execute(command) // command here subscribers.current.forEach((callback) => callback()) }, []) [get, set, blablabla] But here is the problem. We need to pre-populate the state with data from the back end, but we can't do this using set, since a user will be able to undo or redo data from the back end, which is not what we want. By the way, I suppose that's a great idea for a video: How to implement undo/redo in a front-end application (maybe even with the fast context).
For an undo/redo system like that the usual pattern is insufficient. You need a way to set the state without adding an action. In addition you need a way to stack actions onto the head action to handle things like typing where you only complete the action after a 500ms delay in typing.
Hey, I was wondering how would you use this createFastContext API when dealing with components that are in separate files to App.tsx. For example, lets say I want to share the state between Component A and Component B so I wrap these with Provider. How would Component A and Component B access the useStore() function? In your example these components live in the same file, so if they did not do you have to prop drill the useStore() function into component A and B?
I was wondering the same, any updates? I guess you can just put the createFunciton in separate file and then export useStore from it, this should work in theory
Thank you so much, Jack. I've tried this technique without using react context. I use closure for the store and it works perfectly fine. I don't know if any downside to this approach. Thank you again for sharing great quality content.
Downside to that is that you can't restrict it to a specific part of the tree as you can with context. That may not matter to you. Also, that approach is very similar to Zustand, so you might want to try that because it's of the shelf and well supported.
This is awesome. Been working on a dynamic form that can have any number of groups of several inputs each. The state for the entire thing lives in one provider. React.memo helps a bit with unnecessary renders, but this would work waaaay better.
Hey Jack, thank you for sharing your knowledge, I notice this strategy doesn't work if you have another UI provider wrapping your App. Something like Shakra UI Provider for example. On my end, I tried this but I have the next hierarchically of providers: BrowserRouter -> ContextProvider -> Routes and then, the respective routes. I think Shakra-UI is causing the full re-renders for every container and component.
@@jherr I got what was the problem. The component that uses the store value needed is the one that re-renders on state changes. So, isolating the component that uses the store solves the issue. I had a feature component using `useStore`, so the entire component and its children were re-rendering.
AMAZING video!! :) looks like this is a good approach for handling large forms in React, pages that have tons of input fields like 30 and several pages have form inputs, what do you think Jack?
This was on another level. I really hate Typescript. I know its advantages, but I hate it nonetheless. But I'm kind of obligated to use it, and your video show me how to do something that I needed and have no knowledge how to do it. Thank you.
I have been working with React for about 4 years and recently started teaching React to juniors. Today I feel like I am a junior again 😀 Thanks for sharing this amazing content Jack!!
Jack, thank you for all your videos! Thanks to you I leveled up my skills and got to a senior position! I hope you come out with a course soon describing all of the mid/advanced React concepts, best practices, project structuring, when and how to use 3rd party libraries like RQ, state management, and all those good stuff. I would literally pay anything for that!
'Anything'? I can imagine? ruclips.net/video/rZBHits8JPI/видео.html
React Query as some excellent documentation -- dedicate a day to browse through it and you will be surprised what you will be able to accomplish with that library. My companies application has some complicated state between the server and client and react query has made it so easy to manage state, handle mutations + hydrating the client. It only took me a few days of going through the documentation and now I feel fluent with talking to that library -- it shouldn't take you very long if you dedicate a few hours to it.
@@quelchx ruclips.net/video/JaM2rExmmqs/видео.html
@@jherr I have watched this video =). When I first used RQ I thought it was more for data fetching and managing it's state but I have used it to simply manage state from one component to another and mutate that state. I love RQ it's such a useful tool.
Honestly Jack I have learned a lot through your content and have taken patterns you have provided and I use them daily =).
@@quelchx Thank you so much!
I've made this "fast context" solution a few times. The thing is, you don't even need any Provider here. You can just use any external object with the same pub/sub api, since we're triggering re-renders manually, so this useStore hook can pick its store from wherever, not just from a context.
Also, when you do useRef(new Set(...) you're re-creating this Set for every render of that custom hook. It won't care about the value but still, it's "cleaner" to do:
if (!store.current) store.current = new Set(...)
to make it just happen once. Otherwise awesome content Jack. I love the useSyncExternalStore abstraction to get rid of setting up local states manually. Feels safer also to have React internals take care of that part.
Good point :D I guess this also means you could use a store that syncs with localstorage, if it made sense too
The Provider and the `useStore()` hook are fine.
They decouple the components from the source which is useful for developer tests and for inclusion in design system guides.
However, especially as `useSyncExternalStore` is being used, there is no need for `useStoreData()` to be a hook so it can just be implemented as a vanilla `createStore` function without all the `useRef()`and `useCallback()` complexity.
Also since the properties in the created { set, get, subscribe } object are stable through the lifetime of the application it makes sense to just bind it to a `store` variable within the closure created by `createFastContext()` that both `createContext` and `StoreContext.Provider value` can use to eliminate the initial `null`.
@@PeerReynders "so it can just be implemented as a vanilla createStore function without all the useRef and useCallback complexity" -- are you suggesting to just use `let var = ...` variables instead of useRef? I.e. rewrite createStore to be pure javascript, no react?
What a wonderful explanation, I've been working with React for over 4 years already, and still, there's something new I get to discover every day.
Thanks!
Jack writing a solid library in real-time is just incredible. Love to see it and super empowering for anyone looking in to see that you don't need 100 npm packages in your project to make something super solid and robust!
The more code that you can own and understand yourself now means more flexibility and creativity later as you figure out what your project is and can be. Also helps even if you're using pre-built libraries to explore in code yourself to know exactly what you want out of a library and cut through all the bullshit you don't need.
This is brilliant, thank you!
Thank you so much!
Thank you Jack, the time you take to make your content..with so much thought and care makes every video a gem. Again, thank you.
Such a great lesson! This channel is diamond for ones who wanna become really good at react! Awesome job, thank you!
Jack, it's like you're following my work and post videos that are surgically relevant to my challenges. You're so awesome. Thank you so much.
This was so instructive, I love how you teach not only these cool patterns but the reasoning behind them AND colol little details like the Partial there.
Thanks Jack!
This is so high-quality as a junior frontend dev your contents are really helping me write neat-codes,
Let's make react context great again :)
I think the actual implementation of context should be something like this and the current version is really deficient.
And again really enjoyed the way you went step by step, improved the solution, and made it generic. It not only helps with understanding the process but also demonstrates how to eat an elephant.
Thanks again.
Small remark: if you are storing your data in a ref in any case, there is no need to overwrite it with a new object that destructures both the current data and the updates, instead use Object.assign to copy over the partial values for a little better performance. Otherwise, this is a nice pattern and you've done a great job showing how it comes together, @Jack Herrington!
How ? [line-22] if I use Object assign ------> store.current = Object.assign(store.current, value); but TypeScript says (Type 'Partial' is not assignable to type 'Store')
@@talatkuyuk6556 in this case, you can cast value to store. This is a shortcoming of TypeScript.
@@alexlohr7366 Nope, I casted the value as Store; but Object.assign first parameter should extend {} in nature; TypeScript is still angry.
@@talatkuyuk6556
What about this:
`Object.assign(store.current, value);`
@@talatkuyuk6556
You have to constrain Store's type-note below the `Store extends Record`:
export default function createFastContext(initialState: Store) {
…
const set = useCallback((value: Partial) => {
Object.assign(store.current, value);
subscribers.current.forEach((callback) => callback());
}, []);
Using React Context and patterns like what you have shown too me is more than enough for a bunch of use cases. I'm glad to see a video like this so I can point some of our developers we hire to this video to get a gist of what I call baked into React for global state management using HOC patterns.
Im sure I'm not alone with feeling like this but once you learn a few state management patterns/libraries (Zustand, Jotai, React Query, Redux, React Context patterns) I enjoy using almost all of them and when it comes to making a choice on which one to use I often struggle to make a choice because they are all great IMO (for React apps)
Thanks again for all the content you provide to the React Ecosystem it's great, absolutely love the content -- your a great guy for all the work you provide towards developers coming into this gig.
I've been looking for a solution like this for years! Thanks, Jack!
Jack, you a a legend! Spent most of yesterday looking at state mangers to address this kind of issue... glad I took a "RUclips break."
in my eyes this should be an essential upgrade to react and should be an available hook that comes right out of the box, thanks for this!
Hey long time interested, but now full fledged fan, this is hands down your best stuff to date. Amazing
What kind of solution is this!! You just made my understanding of react to another level! Thank you so much, I'll definitely come back to watch this video again and again.
At this point, I don't really know how you keep coming up with a new cooler video. Thanks, from India
You have almost introduced fine-grained reactivity to React like it is for Solid and Svelte. Fantastic job 🔥
Wondering why React did not yet implement such a thing lol
I haven't seen the video yet, but based on previous videos I know it's gonna be amazing.
I like that you don't only show HOW to do it, but WHY you do it.
Here, you dropped this, king 👑
Done, yep, as expected, never fails to amaze.
It's a rainy and windy sunday, i drink a cup of tea and i'm definitly fallen in love with your code and conception. Thank you !
Jack, this is by far the most interesting video about state management in React that I have ever seen. Holy shit, Sir. you are a Beast.
Omg just realizing that context is initially designed for slow-changing-stuff really enhanced my mental model of React. Thanks so much for your videos, you are the coding buddy I don't have :)
I'm really interested in seeing how this would get involved in a more complex application, please do so Jack.
For example:
- involving async actions
- actions that need states from different stores or fields of store
A superb solution, refactored to perfection. That was an excellent video, as always. Thank you Jack for all you do.
came here from Codecamp, awesome content. Subbed!
This is an absolutely incredible tutorial! I learned a ton from this! I understand context, useRefs, and how components rerender SO much better now! Thank you!!!
Hey man, please never stop making videos. I learn so much from you. It has been a year since I've been working full time on react apps and there hasn't been a day without something new. Thankyou.
I love it when these type of ideas come along. I wouldn't use it for state management, but it has a lot of potential when it comes to Multilayer contexts that I deal with at work. It piles up little by little. Thanks Jack
That's SO VALUABLE Jack ! I was looking for a solution for exactly this problem for months. What an elegant solution !
Thanks for the fantastic content!
Love how you still get excited when your solution works (24:13). 😂
Even though you obviously prepped. Even though it's not unexpected.
Keep up the great work!
This was quite amazing and answers a pretty real need I actually have right now. Thank you _so much_ for putting this out there!
I never get tired of the view, what a zen-place to work from
This tutorial blew my mind (in a positive way). Amazing stuff!
Brilliant! I need this to maintain a complex form without a complete rewrite. Thank you! 🤩
I was playing around with your code and came to a realization that the magic is entirely in the useSyncExternalStore method and the context is 100% superfluous, it is not doing anything at all. In fact, useRef and useCallback are also redundant.
With a few tiny tweaks this useful code became a game changer for me.
Thank you for this video!
Do you have any examples I could look at. Sadly, just found this and am relatively new to Context - been using Redux and comparing if this could replace it.
I can't tell you how much I appreciate your videos Jack. You're a great teacher! 🙏
In my experience, I use React context when it is limited in a very narrow part of the components tree, when the state to share is not internal and will wrap a big part of my application, I use Redux Toolkit, I found it very awesome. For server state management, react-query for sure.
Great content as usual, it's really hard to find react content at this level so it's highly appreciated. Great pattern, love the use of refs for this
Awesome video Jack. Your videos are like goldmines.
It's incredible how much I have learned from you. Thank you once again!
My first comment to you. Your videos is super useful and straightforward. I like using Redux, but Context is super for local high state around piece of tree. I wish you GL and thanks for sharing your experience .
Love your content Jack, thanks for this great explanation! I am a React dev, I work with it every day, and this kinda of hassle that we have to go through to get this level of performance is one of my biggest pet peeves with the framework. For my freelance projects I use Svelte and I get all of that for free, it's glorious. Looking forward to a video on the new upcoming SvelteKit!
I see `useStore` is in the same scope as the components since they all live in the same file. But how could you extract useStore to use it in other places, splitting code into more failes?
That pub/sub solution is great! I'm relatively new to React and hadn't considered that as a way to manage state "globally" and only re-render components that need to.
Thanks for sharing this Jack
Really slick! Adopting this pattern immediately. Thanks for sharing!
Great explanation, I've been toying around with using this context pattern and you explained some parts that I couldn't figure out
This has to be one of the best react videos I have watched. +1 Subscriber
I really love this combo. I'm going to use fast context in UI kit I develop (for fun and practice) as I see it reasonable to use React context instead of any 3rd party state management. Less dependencies better for UI kit.
I made one modification, inside Provider component there are two providers now - one provides 'set', the other 'get' and 'subscribe'.
And instead of useStore there are useStoreValue and useStoreDispatch now.
There are cases when you have store setter that does not care about value, so component that uses setStore will never re-render as 'set' is always stable.
Thanks for the video and solution it is awesome!
This is the most insane video you made. This should be on npm as a library. 😁
I was looking for this exact thing for the past two days!!!! Glad I found this
Your solution is awesome; you are great guy to explain this kind of structural videos, thanks again.
This is pretty awesome, I am curious how close a small lib like Zustand is basically just this general structure with a few more features? Good to see what's going on behind the scenes. Thanks for always sharing amazing content!
Jack, thanks a lot for making really excellent educational videos! This one is especially important, given how easy it is to misuse React context and end up being deep under a lot of performance issues. Thank you!
Woah Jack, you are a magician and even after watching you so much, I still can’t wrap my head over some of your concepts.. humbling experience this video was.. I will come to it again a little later in life..
Very sturdy implementation, just loved the approach and the way you explained. can't wait to Implement this fast context.
I was able to predict what direction you were going to go as you went along. When I first started watching your channel a lot of what you talked about sounded like voodoo magic. The only reason I was able to predict before hand what you would do is because people like you are incredibly skilled and offer up high quality educational content. I often reference or recommend this channel to my coworkers. I really can't thank you enough and I still learned something new as I normally do with your videos. Thank you for being a part of keeping my skills fresh and staying highly motivated to stay curious.
Thanks for sharing this new pattern Jack. Really helpful.
Thank you Jack for really valuable React.js content on RUclips !
Jack, this is amazing content. I never thought about the idea to use this combination between context and useRef. You are such a huge inspiration 😊
Lovely video! Concise, and very helpful!! Thank you Jack :)
The only part I didn't understand was a pub/sub model and how it works, maybe because I have never used it before. I believe I will watch this episode a few more times and read articles about how this pattern works. Thanks a lot for such majestic content, I appreciate it as other fellows here.
Amazing, thank you Jack for all the value you provide with your videos
I once faced this challenge:
1) I fetched data from API
2) Based on that data, I should have rendered a slider for each item from a list. I didn't know the count on build time, I only knew it on run time
3) Based on current values of all the sliders, I should have calculated sum and some validation boolean (like isOverLimit or something)
My initial naive way was to pass down value and onChange props from a container component. As expected, didn't go well at all. Slider can easily fire 1000 change events per second. All sliders needed to rerender. I was laggy and terrible UX.
Second approach was to hack it with throttle. Each slider would have its own local state and once in a while (let's say once per 250ms), onChange was fired and calculation synced. Worked better, but it still needed to rerender all sliders, though not that often. Hacky, ugly, not nice.
I did a quick research and and found Recoil. I implemented runtime atomic state for each slider, two selectors for calculated value, everything worked perfectly, only things that really changed had to be rerendered. Tried with 1000 sliders just out of curiosity, worked flawlessly, slide back and forth on 4K display, no lags, blazing fast.
This solution looks good in a way that it could replace my solution entirely, without Recoil needed to be installed at all.
Really nice. I like this ref - subscriber - selector approach. It's clean, neat and elegant. No hacks needed.
Thanks 🙏
It's the clearest tutorial on how to implement the fast context
This is one of the best tutorials on RUclips 🙌💯
This tutorial is simply amazing. Thank you!
I really love the way you explain concept by doing step by step. It reminds me of Dan Abramov trying to re implement Redux from scratch. It make things clearer and straightforward.
Really really enjoy your video format! Thanks!
Also one quick question:
My team and I have started implementing the fast context in our app. But there is one thing we can't solve for a few days regarding the fast context.
Actually, our app allows users to undo/redo all types of actions (e.g. input changes, deleting and adding things). For each change in the store we provide a command, the command contains three things: execute (that's how the store should change), undo function, and redo function.
So basically, we do something like:
const set = useCallback((command: Command) => {
// alter the state using the command
stack.current.execute(command) // command here
subscribers.current.forEach((callback) => callback())
}, [])
[get, set, blablabla]
But here is the problem. We need to pre-populate the state with data from the back end, but we can't do this using set, since a user will be able to undo or redo data from the back end, which is not what we want.
By the way, I suppose that's a great idea for a video: How to implement undo/redo in a front-end application (maybe even with the fast context).
For an undo/redo system like that the usual pattern is insufficient. You need a way to set the state without adding an action. In addition you need a way to stack actions onto the head action to handle things like typing where you only complete the action after a 500ms delay in typing.
@@jherr Thanks a lot!
That's exactly what I was looking for! Thank you so much : )
I really don't mind using Zustand and React-tracked for this (in-fact I love it), but nice still for a no-additional dependancies setup
Yeah, I use Zustand daily. But it is nice to have techniques like this in the back pocket.
@@jherr Master Jack I can ask you something, what is better redux o context react Thanks.
Thanks Jack! Came for the context, stayed for the typescript!
Brilliant stuff, Jack !
Woooah! I couldn't stress enough how much I loved this video! Thank you Jack! 🥳
This is smashing, thank you so much Jack! 🔥🔥🔥🔥
I just found out about your channel and it is impressive the way you explain. It's amazing.
Do you know any idea about the progress of the proposal of memorizing everything in React?
I haven't seen it. But I'm not opposed. I just think having to memoize everything ourselves isn't great DX.
Hey, I was wondering how would you use this createFastContext API when dealing with components that are in separate files to App.tsx. For example, lets say I want to share the state between Component A and Component B so I wrap these with Provider. How would Component A and Component B access the useStore() function? In your example these components live in the same file, so if they did not do you have to prop drill the useStore() function into component A and B?
I was wondering the same, any updates? I guess you can just put the createFunciton in separate file and then export useStore from it, this should work in theory
Thank you so much, Jack. I've tried this technique without using react context. I use closure for the store and it works perfectly fine. I don't know if any downside to this approach. Thank you again for sharing great quality content.
Downside to that is that you can't restrict it to a specific part of the tree as you can with context. That may not matter to you. Also, that approach is very similar to Zustand, so you might want to try that because it's of the shelf and well supported.
Absolute meat!!! Thank you for the tutorial Jack
Thank you Jack for the best content I've ever seen, you're a great and awesome guy, and You thought me a lot
I will never do that but hey Jack now I understand what Zustand and other state managers do at a scale. Thanks!
Thanks for this implementation, you're a beast Jack!
ReturnType was clever.
This is awesome. Been working on a dynamic form that can have any number of groups of several inputs each. The state for the entire thing lives in one provider. React.memo helps a bit with unnecessary renders, but this would work waaaay better.
Thank you so much for such an amazing video.
This type of content is really inspiring.
Great stuff.. love these kind of videos
Very very cool approach. Loved it. ❤
That was bloody amazing
dang.. how did you come up with this? great stuff my man
I was surprised to see, after learning so much I haven't subscribed yet, what a shame... ;D
Great leveling up, keep up the best work
Thanks
good work king, love you
Hey Jack, thank you for sharing your knowledge, I notice this strategy doesn't work if you have another UI provider wrapping your App. Something like Shakra UI Provider for example. On my end, I tried this but I have the next hierarchically of providers: BrowserRouter -> ContextProvider -> Routes and then, the respective routes. I think Shakra-UI is causing the full re-renders for every container and component.
Sounds like you should create a minimal repro case and share it with the Chakra folks.
@@jherr I got what was the problem. The component that uses the store value needed is the one that re-renders on state changes. So, isolating the component that uses the store solves the issue. I had a feature component using `useStore`, so the entire component and its children were re-rendering.
This is incredibly helpful. Thank you!
Thank you for this amazing content, really insightful.
AMAZING video!! :) looks like this is a good approach for handling large forms in React, pages that have tons of input fields like 30 and several pages have form inputs, what do you think Jack?
Kinda depends on the use case. I'm always a fan of using local state first if I can get away with it.
@@jherr thanks for your input!
This was on another level. I really hate Typescript. I know its advantages, but I hate it nonetheless. But I'm kind of obligated to use it, and your video show me how to do something that I needed and have no knowledge how to do it. Thank you.