4 ms·
The need for this sort of disappears if the thing being displayed (client) is actually coupled to the application state. Toasts are bad UX, yes. But the reason
by mlsu 2y ago
The need for this sort of disappears if the thing being displayed (client) is actually coupled to the application state. Toasts are bad UX, yes. But the reason they exist is that we have one state on the server and then another pseudo-state on the client. Keeping them in sync via code locality in every component is extremely difficult.
So we come up with a workaround -- put async server updates in only one place in the application -- to get around this fundamental issue. In 99% of cases, this isn't about UX, it's about engineering. Nobody wants to put toasts in; they must, because managing state is too difficult otherwise.
It's a symptom of the larger issue.
If instead what's displayed on screen is simply the server's application state returned by the server, the user will always know what's happening with the server.
HATEOAS
- switchbak 2y agoHATEOAS is more about a standard, discoverable and consistent way to navigate around resources in a RESTful fashion. Which is nice, even if it didn't really catch on to a large degree. I think that's somewhat orthogonal to he point you're making. I think your point is good though, that an ephemeral toast message is a cheap way to avoid having to manage and expose the underlying state. Exposing that via a HATEOAS REST API would be even better!