Q: Is it possible to use redux-style state management?

I’m curious is it possible with Laminar to have whole app state in one big immutable object, like in Redux or ClojureScript’s re-frame?

For example, I have something like:

case class Todo(...)
case class User(...)
case class AppState(user: User, todos: Seq[Todo])

As far as I can understand to build view layer for this app-state we need something like (sorry, don’t know well Laminar API, so I use pseudo-code):

def appView(state: ReactiveStream[State]): ReactiveNode[Div] = {
  // .. here we call child components userView(user: ReactiveStream[User])
  //    and todoView(todo: ReactiveStream[Todo]) ...
}

Does it have any sense? If not, what’s the recommended way to manage state with event-stream based frameworks?

Btw, thanks for your great work! No doubts we need Scala-“native” solutions to cope with UI issues and I found Laminar and Outwatch very promising! 👍

[raquo]

No, extraneous re-renders should not be needed at all. In your code you will have pieces like something <-- someSignal. That means that when someSignal emits a new value, something will be updated in the DOM, nothing more.

In your user component you will probably have something like div(child.text <-- usernameSignal) where usernameSignal is derived from centralVar. So when usernameSignal updates, a new DOM text node will be created and inserted into that div instead of the previous text node.

I assume nothing in the todo list depends on the username, so its DOM will not be touched at all when it updates.

The thing to avoid in Laminar is this pattern: div(child <-- usernameSignal.map(username => span(username))). In that case, a new span element will be created every time usernameSignal updates. That is not a big deal in my contrived example because username updates are probably very rare, and this span is just one element, but if it was a bigger component and/or the updates were coming in more often that would be really inefficient.

---

Importantly, Airstream’s State does not emit a new value if it is equal to its previous value. So you should make your components depend on individual chunks of centralVar (e.g. centralVar.user) rather than on the centralVar itself, because the value of centralVar itself will change with every update to any of centralVar’s contents because of immutability, but the individual chunks will only change when they themselves (or their children) change.

Note that Signal-s don’t have the same de-duplication behaviour built-in. I wasn’t sure about that design decision, and I might add deduplication later. For now you’ll need to .map centralVar first to narrow it down, and only then convert it to a Signal, otherwise you’ll get more DOM updates than needed.

[raquo]

State management is now sufficiently documented under Var in Airstream docs I think.