4 ms·
The ubiquitous waiting/loading/error(msg)/success(data) Lots of frameworks and state management libraries already lean towards helpful design, in languages wit
by dakom 4y ago
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)
- davnicwil 4y agoI think a switch or an if/else expresses this really clearly though and also prevents impossible states.
- capableweb 4y agoAs 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.
- davnicwil 4y agoI 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?
- joshribakoff 4y agoI 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
- dakom 4y agoYes, 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
- capableweb 4y agoStatecharts 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.
- davnicwil 4y agogeneral 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.
- capableweb 4y agoI agree with you, as mention in another comment (https://news.ycombinator.com/item?id=35331199 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.