[aikah]

You're example is the perfect example of what not to do and why React, Angular and such exist: STATES. You want your view to be data driven.It means that your component should be STATELESS.

There are other issues such as event delegation,cleaning up event listeners,... that will make your solution hard to scale past simple widgets.And before you know it,you'll be writing your own complicated framework that does less than Angular or React.

[joshstrange]

> that will make your solution hard to scale past simple widgets.

I am fully aware of this issue, again, this is a stop-gap between the jQuery mess we had and proper framework. This is not being used to run the whole front-end, it's only being used for components that are loaded on a page. And in fact the one page that we have that does a full re-draw on every change is actually extremely fast, you don't even notice it. Again, this is not to say it's the end goal, just a step on the staircase to a JS framework. Just getting away from building a component in PHP then modifying it in JS has been a huge win. My rule of thumb is logic should only be implemented in 1 language and so if you need to update/modify anything on the client side (which we almost always need to do, this is a Web App and not a website with some JS sprinkled in, even if that's how it started) you need to do it all in JS or else you get into a case all too easily where you edit the JS or PHP and not the other. Not to mention that if we wanted in the future we can alway render the first load on the server (using JS) and then subsequent renders could happen on the client with the same code.

[skybrian]

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.

[baddox]

> 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.

[skybrian]

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/

[donw]

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.

[i_s]

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.