Hacker News new | ask | show | jobs
by skybrian 4119 days ago
A web app always has a state machine somewhere, even in functional languages. The question is whether the app's state is internal (mutable state) or external (write a state transition function and let the environment pass the state back to you on the next iteration).

I think the jury is still out on whether storing all application state in a single state object (as in Elm) scales well beyond toy examples. All the state is exposed which doesn't seem so good from a data-hiding point of view.
3 comments
baddox 4119 days ago
> I think the jury is still out on whether storing all application state in a single state object (as in Elm) scales well beyond toy examples.

I'm not familiar with Elm, but what do you mean by this? Even if all the application state isn't literally in a JS object like {users: [...], messages: [...], ...}, it's going to be in multiple variables like UserStore and MessageStore. There's really not a big difference other than the syntax of accessing them. But perhaps you're hinting at a drastically different approach to application state.

link
skybrian 4119 days ago
Elm [1] is not JavaScript. It's a pure functional language that compiles to JavaScript. There are no mutable variables in Elm as you'd normally think of them, but there are streams (called signals) and state machines.

The issue is that you can't really write UI components as you'd normally think of them; everything needs to be divided up into a separate models and view functions. The state of every single widget in the page (recursively) needs to be represented somewhere in the application model.

[1] http://elm-lang.org/

link
donw 4119 days ago
It seems to work reasonably well for the two non-toy apps I've worked on that use a single state object. There are two key rules required to make this work, however:

1. For each domain, state can be modified in one place (in React, a store).

2. For each domain, state can be read in once place (a Presenter).

This preserves data-hiding for the most part, and keeps you from having to play hunt-the-wumpus when you need to change the data structure.

link
i_s 4119 days ago
Om also stores all app state in a single object, but lets you give components a window into that state ('cursors') in order to maintain modularity. If there turns out to be a problem with this general approach, it won't be a data-hiding one.
link