need to documenting model-routing order?

When bootstrapping an app in version 2.3.1 we did this:

app.router((route) => [route('/', Submission(app))])

…where Submission is a component that also made an app.model call. This no longer worked in v3, and had to be changed to

const root = Submission(app)
app.router((route) => [route('/', root)])

I’m guessing somehow the new architecture required the app.model calls to have been made before the routing. If this is really so, perhaps it should be documented?

[krawaller]

Haha, I was just returning here to say much what @yoshuawuyts did: I think we’re missing the point when comparing to React. Yes, the React version of the confirm button component is stateful and breaks hot reloading and time travelling.

But! In the Choo version, even though isolate the definition of the relevant model parts to the component, the actual state is still stored centrally. If you were to inspect the app state at any point, the confButt stuff would be there. My smart component is still dumb!

In essence - Choo is stupidly smart. Put that on the box!

I agree that putting the model definition on the exported function is cleaner than passing app to the constructor, good call.

[dereklieu]

Or perhaps the value of having a centralised model trumps the value of isolating concerns in a component? Not an ironic question, I’m genuinely equal parts intrigued and unsure! 😃

I worked on an app that kept component state such as a confirmed = true localized while storing what we thought of as application state, like api query data, in a central redux store.

We found that the bits and pieces we thought of as component state actually added up to a pretty good amount, and usually that component state would affect how other components render. It wasn’t terrible in the end, but we’re working on a new version with choo that will try to store all the bits and pieces in the central place.

This also gets you an easier path to start the app from a moment in time, as long as you’ve got a copy of that store handy, which was a requirement for us.