ReactStateMuseum VS crank

Also, there's this for state management: https://github.com/GantMan/ReactStateMuseum

React development has always had a bit of a choose your own adventure experience. By that I mean there are a LOT of choices to make in any react app. Other frameworks are much more prescriptive in how you build applications. You won't get very far down your adventure before you must make some choices in how you handle data and state within your application. React components can have state using setState in a class component or useState in a function component. That along with context is really all React gives you out of the box. Over the years there have been countless state management solutions that have risen and fallen in popularity. Have a look at React State Museum to see dozens of the most popular approaches over the years. There was a time where it looked like Redux was going to be the clear winner and for maybe a couple of years it did seem like every enterprise react app was built with redux. It's sort of fallen out of favor in recent years although it is still a solid pattern. Over the years my preferences have changed as the options have expanded. Back in the redux hay day I was all in on global state management but these days I do not find myself reaching for a global state management solution. I'll try to break down my preferences for data/state management. So pretty much every app out there talks to some sort of API to query/mutate data on the server. I prefer to synchronize my app with the serve using React Query or Apollo Client. I've been working mostly with GraphQL APIs in recent years so I've typically found myself using Apollo Client. Apollo client has a memory cache that your app can use to synchronize the UI with the server. I only recently learned about React-Query which has a very similar API as Apollo Client with the useQuery hook, but can be used with anything that returns a promise like the Fetch API for example. React Query is useful for synchronizing your app with server data regardless of if it is GraphQL or REST, or something else. I find that once your app data is synchronized with the server using one of these approaches, then there is not really much left that needs to go into global state. It is worth noting that Apollo Client does allow you to add some local state to the cache, but I’ve found it to be a little heavy handed for my tastes. Most apps you will want some state available globally for example you might want to track dark mode settings, or if a particular modal is open and things of this nature. In these cases I find useState or useReducer with React Context is sufficient. I tend to prefer to keep my state closer to where it is relevant. I do have a fascination with Finite State Machines - and XState is awesome for state machines in your app. I do like to use state machines at the component level, for complex operations or to orchestrate some nuanced sequence or application flow.

If you enjoy this approach, you might enjoy the Crank JS framework. https://crank.js.org/

> Crank uses generator functions to define stateful components. You store state in local variables, and `yield` rather than `return` to keep it around.

I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components.

[0]: https://github.com/wishawa/async_ui

[1]: https://github.com/bikeshaving/crank

Take a look at crank.js, a JavaScript framework where components can be written as async functions or as generators. It seems similar to what you're trying to do :)

Well there's https://crank.js.org that uses native js generators where you would you normally put hooks in. Never used it but looked like a very neat idea.

Reminds me of https://github.com/bikeshaving/crank, which was rather fun for a PoC I made a while back.

Strictly speaking, the framework hides this complexity away, but it still exists and it is the framework that's now paying the extra cost. Of course a framework is allowed, and should, when possible, hide away these things. For example Crank.js uses generators to allow for async Components as first class citizens, https://github.com/bikeshaving/crank, but they're still having to deal with the pitfalls of asynchronous work.

To give the author of https://crank.js.org/ due credit, after reading through the descriptive posts I was impressed by the amount of thought and design that went into it.

> What do you propose as an alternative?

There are lots of alternatives, but perhaps the simplest would have been to use async generators. This is how Crank[0] (mentioned elsewhere in this thread) works, and it allows you to do anything (AFAIK) that's possible with hooks with a much simpler and more testable API.

> So, sure, there are limitations and rules you have to pay attention to with hooks... but that's just programming.

No, it's not. The biggest problem with React hooks is that they are not composed of transferable knowledge, meaning memorizing these rules and patterns does not transfer outside of React; likewise, I can't use much of the knowledge I have already built up over many years of my career when using hooks. It's the same argument that's made against Rails, where you have to learn tons of Rails-specific idioms (on top of having to understand general concepts like relational database access patterns) instead of just writing code in a way that's more direct and intuitive for anyone.

My brain has limited RAM. The more things I have to keep in my head when developing against an API, the more likely I am to make a mistake. With every release of React, I seem to have to keep more and more of these details in my brain as I work. Contrast this with something like Svelte, where you really only need to fully grok about two concepts to use it effectively. I understand that this is the tradeoff the React team made, but I'm not convinced it's worth it.

[0]: https://crank.js.org/ and https://crank.js.org/blog/introducing-crank