Hacker News Reader

Comment by dakom | Hacker News Reader

The ubiquitous waiting/loading/error(msg)/success(data)

Lots of frameworks and state management libraries already lean towards helpful design, in languages with async and ADTs as first-class citizens you've got a real leg up, but at the end of the day it comes down to preventing impossible states.

You can't have an error message when in the success state, you can't have success data while loading or waiting.

By preventing this at compiletime, it also means the UI can't ever show bogus data (i.e. it's impossible to have a success screen with the error message dangling at the bottom because somebody forgot to clear it)

View on HN

I think this is solved more generally with a discriminated union in typescript.

A state machine is the wrong solution unless you also need to restrict transitions themselves in my opinion

Statecharts are language-agnostic, whereas your proposed solution appears to be tailored specifically for TypeScript or other strongly typed languages. In this context, Statecharts offer a more versatile and generalized solution compared to your suggestion.

general is not always better though. There's a tradeoff to other things like readability.

If a TS typed switch statement, say, offers the same guarantees of covering all options yet is just run of the mill JS that anyone can read and instantly grok, and covers 99% of usecases in run of the mill web dev product work, then to me that's an argument that it's the better solution.

I agree with you, as mention in another comment (https://news.ycombinator.com/item?id=35331199), that if you can cover all the cases with conditionals and you don't have nested states, don't use Statecharts. Just like distributed architectures are not for everything but more advanced use cases, so is Statecharts. It's a tool to help you manage great number of states, not just a couple.

Yes, sorry if that wasn't clear, but the transitions here are also typically restricted. For example, business logic may dictate that you can't go from waiting to success, you must go through loading and fetch fresh data. This prevents the problem of displaying stale data, at compiletime

I think a switch or an if/else expresses this really clearly though and also prevents impossible states.

As a huge proponent of Statecharts, I agree. If what you're doing is really simple and only have a few amount of states (as conditionals introduce those states no matter if you use state machines, statecharts or conditions), it makes sense to keep things simple.

But once you start having much more than that, or nested states, Statecharts makes it really easy to build reliable, performant and easy to change flows.

I can see that. Do you have some examples of common UI usecases which are the other side of the line here and for which statechart based code is better?

the original paper by David Harel has a marvelous long example of his own digital watch, highly recommended

thanks, I'll check this out!

Reply on news.ycombinator.com