Hello there sir. I just found your channel and I really liked your content. Thanks very much for your teachings. You explain things very clearly. I was think if you could make a series on nextjs with typescript. Thanks a lot again!
Since I started learning React with Typescript I generally find myself wanting to smash my laptop at least several times a day You are actually a hero for taking the time to explain this so clearly in a really logical progression through the complexity... and also additional thanks for delivering it with such a positive vibe. Surprisingly makes quite a difference in reducing the urge to throw a rage quit tantrum. I would describe this as the filet-mignon of React Typescript State Management tutorials
Haha, happy to provide the choicest cuts. :) Let me know if there are other topics you'd like to see covered. I may have something already, or make something new.
I agree with you on this channel and I'm in the same place with React/TS. I'm envious anytime I see examples in javascript, because they seem so much simpler and there's so much less noise/code. I find myself fighting with the TS compiler half the time. But I know there's a lot of value, I just haven't gotten versed enough in TS and React. I've definitely gotten a few ideas from this channel though.
You put a bang after useContext because it can be null and mention quickly something about "coerced". Having seen this before in JS, is this a typescript thing and can you ref or eleborate on what it does?
Thanks for the great video, I learned a lot. I just have one question that was confusing me. At the end when you create the custom hook, in the helper methods (addTodo, etc.) You use `tl` ex. setTodos(tl => addTodo(tl, newTodo)); I noticed `tl` wasn't declared anywhere and assumed that useState set functions invoke with the state variable automatically? I didn't see anything in the React docs about that from what I can tell. Just has me scratching my head.
Right, in this case `tl` is the name of the parameter and this is an anonymous function declaration that takes that parameter and sends it on to addTodo. The first parameter is a todo-list so the name `tl`.
Great material as always ! Presented in such a nice and entertaining way only an expert would know how to do . Thank you so much for this amazing content. I expected you in the end to remove the export keyword on your business methods ( add, remove, update, delete), did you forget to do it, or is there a specific reason you did not ? God bless you :)
The only downside I see here is having to wrap multiple providers... over doing say pub/sub singleton approach. I do the latter but wrap it with useGlobalState type approach or HOC. This was a well done presentation.
Hey! Thank you for this tutorial. I am. *just* learning TS and therefore am struggling to troubleshoot. I am console logging the current todos and it seems like done isn't changing to true for me. Any thoughts?
I am beginner in typescript, but I found this lecture (especially the part with custom hooks) to be quite difficult to understand. I can see that the material is top notch, I just wish, it would be more “accessible” to beginners. Like explaining why we add callback functions to methods in our return statement, etc.
I really enjoyed your videos on custom hooks and using context! Your channel is unique and goes beyond the norm, which is much appreciated. But I found myself wishing that you had used an item that's a little bigger than a todo (eg, an employee, or customer - something with more fields). I ask because I have a project I'm working on that has a screen with multiple tabs and item data on each one- and I really want to find an elegant solution to the state part of it. My screen only has 7 fields at the moment and the change handlers on the text fields alone are making things way too busy for one file (ie, prop drilling). Can you put the change handlers that set new state on every keystroke in a different file/hook and import those instead of having them in the file that renders the input fields? I know that something similar to your custom hooks with context must be the answer, but I can't quite map the todo example to mine.
Early on in my career I had a job where I needed to build a single dialog with 8 tabs with interconnected fields. What I ended up doing was creating a "view model" that mapped 1:1 with the controls and it then translated its own state to what the backend needed. I then made extensive use of the observer pattern to connect the controls the view model. Technologies have changed, but I think the approach is solid. If you use something like Valtio or MobX to manage the view model it should scale up to the size you need.
I recently embarked on a no-libraries React state management in TypeScript, actually inspired by this video. But... few days ago I discovered something in Hacker News.... a lib aptly called "Simpler State", so far it's looking super simple to me. My library-less React TS app suddenly got shorter, feels like Context API without providers.
It looks good. I'm not a huge fan of the `entity.use()` but there appears to be a `useEntity` as well. Slightly concerning to me is that the library is actually written in JS and it's just the types file that's in TS. Not sure why that's the case. I think it would be less error prone to also write the library in TS. But that's just because nowadays I write everything in TS, even the simple stuff. This kinda reminds me of Daishi Kato's `react-hooks-global-state` but with a bit more to it. I'm not sure in Daishi's case you can set the state outside of a React context but I think you can with this one, which is good.
@@jherr Funny you mentioned it, I much preferred the useEntity() alternative to the example entity.use() too. And as for JS source, i agree TS is more readable. But i dont mind it too much cos even my TS app barely has explicit typings anyway... so as long as type inference works im good with that.
@@robovirtuoso1354 Yeah, the TS stuff comes through because of the types, I'd just rather those types were auto-generated from the source. I actually put a trivial PR into the repo because the definition for `resetAll` was duplicated, and that wouldn't have happened if the types were generated. And there is no way for the types to go out of sync as well. It's funny, there actually is a lot of extra stuff in there around metadata and I'm not sure what that's about. It's all undocumented.
@@robovirtuoso1354 Totally agree about `useEntity`. If you want to do the React thing then do `useEntity` and call it a day. `entity.use()` is just gonna look odd to React folx.
Hey Jack! Awesome Content as always! I noticed that the store did not accept the Context Provider when the file name was store.ts but accepted it after it was renamed to tsx. What is the difference between ts and tsx files? Are there things I should keep in mind while naming them to ts or tsx files?
I like the pattern you created with interpolated type / guessed typed. Is it a common thing you seen in many project. Or you came up with this idea. Pretty neat though :) I struggle with react with one thing. It creates ton of anti-pattern, biggest of the all is redux :) big global var anyone can write or read from :). The context pattern I am not 100% convinced about either. I can not put my fingre on it but it feels this is not the way :). React for me is functions calling functions, functional/currying library. It has elegance when you think like that, but breaks down when they start injecting stuff. I guess real world problem can not be solved by Haskell (lolzzz) BTW :) as usual great stuff man !
On the plus side, as we look at a number of state managers in this series some of them do not use context to share state, so you might find something you like.
You've got some misconceptions about Redux. It doesn't act like a "global var" because it is immutable and can only be updated through dispatching actions and run reducers to decide the new state. It's one way only, meaning you won't run into the problems that a "global var" has, such as race conditions. This is how state is often handled in functional programming languages. As for React Context, it is simply just a dependency injection mechanism (not state management). Rather than drilling state deep down in your tree manually resulting in many dependencies, Context provides a mechanism that allows you to access top level state with less friction, while preserving the single source of truth.
You might want to be clearer / more precise on the typescript specific stuff ( the reasons behind decisions) , exporting the useSate from the store and not from the App for instance, the returnType Tupple VS export type TodosSetter = React.Dispatch. btw, i'm not the thumb down guy ;)
I think they are fantastic when you have a system with discrete states. I've done some videos on XState and it's great stuff. I wrote a GraphQL subscriptions based game that used XState for game management and it was AWESOME. The issue I have with it is that the current tools are an either/or, it's like, everything is in the state machine, or everything is not in the state machine. Which is why I think what Daishi Kato has going on with doing an optional XState integration into Jotai is very compelling. You can have one piece of state modeled as a state machine, while other pieces of state are get/set kinds of things un-related to the state machine. Once that integration is done I look forward to doing some videos on it. What's your take? Should I do XState as part of this series? I think I'd have to go beyond Todos though since they don't really require a state machine.
@@jherr thank you for the very thoughtful reply. I have to scroll back and watch your GraphQL And XState series. From my experience using XState, I agree that with encapsulatesd state that is highly dependent upon one another, it is probably best with a state machine. Otherwise, libraries like those from Daishi Kato, or others (redux/toolkit, mobx, recoil), are probably best with the getter/setter approach. I am a heavy flux pattern enthusiast, however, having to handle asynchronous actions with custom middleware is a bit bloated and heavyweight. Therefore, framework agnostic libraries that sit outside of react context are appealing. They are light weight, async capable, and much more performant. I just think they need time to catch on. Engineers in my opinion are overly used to frameworks like Redux and MobX for scalability. Plus, this video demonstrates best context practices, but many engineers probably don’t utilize context efficiently (waiting for the new selector hook). I know this is a very long post, but I definitely would love to have some videos within the series on X State and a comparison to alternatives. It can put things into perspective for your app. Thank you for the great content as always! Sincerely, Eric Zorn
@@ericzorn3735 Now that you bring it up I really do want to integrated XState into this, but the Todo example just isn't complex enough. So if you have some ideas for that let me know either here, or on Twitter (@jherr) or on the Discord server.
@@jherr I can definitely keep the convo going on Twitter so that I don’t clutter the comment section. Definitely thinking of a good alternative example
I really like that you moved the "set" part when using useState to the end of the variable instead of in the front (the type should perhaps be named likewise. I'm considering to be inspired and use a good practice to write it like this in the future const [todoGet, todoSet] = useState(null)
Please DON'T! It's a generally accepted convention (not just in React!) to name setting functions as setSomething. Why would you do it the other way around?! Name like 'todoSet' would suggest not a function but 'a set (collection) of todos'. Also, the first element of the array returned from the useState hook is not a function, but the state itself. Naming it todoGet would be just plainly wrong. Jack, I appreciate what you're doing, and I'm sorry to say this... but in this case, as an educator, I think you should have known better. Keep up the good stuff though!
@@lllllllllIIIIIIIIIIl Ah, sorry, I misread your comment when I replied the first time. I've read it as "invented" instead of "inverted". I fully agree. :)
The useState typing pattern at 5:45 is soo clean. 🥹 Thank you soo much. Drilling "useState" and importing "Dispatch" was making my code gross. I was getting confused and frustrated. Thank you very much for these videos.
