#Just curious what would you guys say
1 messages · Page 1 of 1 (latest)
Hey. I have written some of my thoughts on github. I won't repost the whole thing here, but you can read it at https://github.com/jensen/ui-workshop/tree/main/part2
Hey, I have written some of my thoughts on this here https://github.com/jensen/ui-workshop/tree/main/part2
Thank you! :)
These are the guidelines I use when building react apps.
- Think in interfaces
- Minimize duplicate JSX
- Minimize duplicate state
- Prefer handlers for side-effects
- Identify root dependencies
- List all dependencies, and reduce them if possible
- Use context to share things that don't change
Why wouldn't you use context to share say a state that changes constantly?
Well I find other people complain about re-renders more than I do, but something that is on a context way up your app tree that changes a lot, will render you whole app
That is true, I don't use context much so I hadn't even thought about that
Probably would go with Redux in that case
So when you use context for state management, you are more likely to use a subscription system. You pass a static subscription around, but then when the data changes the components that are subscribed can be notified. This is why context is not a direct replacement for redux. Context is a dependency injection system not a state management system
Yeah, no reason to rebuild an existing library that already uses context to do what you need
I have more than 20 sample projects here https://github.com/jensen
Only two of them are SolidJS instead of React.
I have a tendency to rebuild the wheel unfortunately, but I would never try to rebuild a state management library, it's not insanely complex but I feel like it would take quite some time lol
there are just so many good options
Haven't really explored any besides redux, it just does everything and it's really small
Yeah, I think it has a bad rep. That is only because it is so popular
Check out zustand, it's a cool state management library as well.