How UI-driven state increases accidental complexity

Another angle to consider is that even within the context of UI state, the natural shape of the data may not match the renderer's state.

For example, if you're building a "pong widget" - the UI state is pretty straightforward across the board (paddle position, ball position, etc.) - but that's going to have an "impedance mismatch" when targeting DOM vs. GPU. The former may want things in a left-to-right tree structure[0], the latter may want paddle-meshes first regardless of their position on the screen[1].

Separation of concerns is a wonderful- even essential thing, but can be tricky for large real-world projects.

[0] that's not really a problem here - CSS grid with named areas could solve it in this specific use-case

[1] e.g. to avoid shader switching

Specifically for dropdowns, you usually want to keep their open / closed position in the UI state explicitly, because you want to close an open dropdown when the user clicks on another dropdown.

I frankly think that this complexity is not accidental. It is the real complexity of the UI, which is often not realized. All the little things that need thought and, at least once, an implementation.

Contexts were added to React to replace prop drilling.

Controller. You need a controller. Or a smart model, in this simple case.

That’s what react/redux has done to you, selling this ‘immutable functional’ flavoured thing. While it is immutable at the programming surface, it is actually a series of complex updates with little to no help from the ‘store’ for convenient access. In pure js, when you want project.tasks, you just:

  class Project {
    get tasks() {
      return db.tasks.filter(x => x.project_id == this.id && !x.deleted)
    }
  }

  class Task {
    get project() {
      return db.projects.find(x => x.id == this.project_id)
    }
    del() {this.deleted=true}
  }

  db.tasks = [].map(Task)
  db.projects = [].map(Project)

  ... in a view:
  h(button, {bind:[cr, 'add_task']}, '+')
  cr.project.tasks.map(task =>
    ...
    h(check, {bind:[task, 'done']})
    h(button, {bind:[task, 'del']}, 'x')

  ... in a controller:
  add_task(project) {
    db.tasks.push(new Task({project}))
  }

In “immutable functional state transformer based on async-dispatched store”, which these re-whatever buzzwords are, you cannot have neither smart data items, nor a good controller that could join unrelated objects together, nor recombinable data sources, nor nice testable api boundaries. And when someone whispers MVC, you think about web 1.0 patterns, with it’s “MC in MVC is backend roundtrip” meaning.

This particular example is a set of five dead-simple classes (DB, Project, Task, TaskListController and TaskListView), almost all orthogonal and useful/testable on their own. Easy for imperative thinking and managing^, cause UI is suddenly imperative. You constantly battle with immutability, lack of control, state copy-transfer and tons of boilerplate for a simple action, can’t you see? You’re doing a monad bind operation by hand, because there is no do-notation in your language, and where there is, it exists and is called “do” for a reason. How did they miss that completely? /rant

^ e.g. want to see deleted tasks? Write a getter in a controller or a db (depending on locality requirements) and use it in a view as if it was a pojo array. Reimplement on demand to leave your tests and logic intact.

You may want to have a look at how re-frame[0] (ClojureScript) does this or redux-toolkit[1]. The issues you mention are discussed there and solved well.

There is a controller in the sense you are describing, but the reads and writes are clearly decoupled as separate, functional steps, while the data is just a plain composition of maps and lists.

Putting these operations into classes is a regression from this point of view. You suddenly get these artificial objects (models) that get harder to extend, reuse and change, because you have relations between objects that you somehow need to model and synchronize as well.

Imagine if databases worked this way. Gladly they don't. They have a uniform, declarative language that you use to interact with them and the data is just data, no matter if it is a Person, Cat or w/e.

So in a sense these libraries are re-inventing databases to handle GUI state in the browser, which is a good thing.

[0] https://github.com/Day8/re-frame

[1] https://redux-toolkit.js.org/