[section] start

[yoshuawuyts]

• describe how subscriptions work
• describe the "global start" pattern; e.g. wait until multiple models have booted before changing some other variable (e.g. "application has now loaded, stop rendering the placeholder view")

[dannief]

@yoshuawuyts Until the docs get updated to describe the subscriptions model, any way you can point to some samples or source code to that describes how they work?

[bcomnes]

@dannief sounds like maybe you are trying to use an older Choo release? The newest version of Choo does away with those and only uses mutable state objects and an event emitter. These are described in detail in https://handbook.choo.io

Or are you looking specifically for older docs for an existing project?

[dannief]

@yoshuawuyts @bcomnes I actually read the docs, so I am aware of the API change. I think I may have misunderstood something that was written at the end of the handbook, implying more documentation to come.

So there is no way to subscribe to state changes then? Say you want to perform some logic on certain state changes like syncing with local storage?

I know you can subscribe all events using the "*". So if I wanted to know if a particular state change was made, I'd have to manually do a diff with the current state?

[bcomnes]

That would work (e.g. listening on all events and checking if state has changed), or you can emit another event whenever you know you are changing state.

Here is an example of how an app I'm working on handles state updates from an external source:

https://github.com/hypermodules/hyperamp/blob/master/renderer/stores/player.js

I'm not sure that helps. If it does, please note what helped clarify the confusion so we can maybe add that to the docs.

[bcomnes]

I guess the way I think about it, rather than listen for state updates, listen for the events that will cause state to update if you need to hook in there. Otherwise, update state as you go, and emit render whenever you want a fresh repaint of the page.

[dannief]

@bcomnes Thanks for clarification, I see how your suggestions would work. I can either just listen for events that I know update the state changes I need to act on, or for all the handlers that change the state, I can emit another event and listen for that.

That certainly works. I suppose I was checking if there was a more direct way. However, I understand wanting keeping the API nice I small.

Nice work on version 5 btw, I really like the simplicity.

[bcomnes]

A wild v6 appears! choojs/choo#489 (API is nearly the same though).

Yeah, I'm digging the changes too!

[bcomnes]

@dannief I had an idea... Rather than set state directly on the state object, you could write a function that sets state for you, both on Choo state and wherever else you need it to (localstorage)? When you set state with that, you don't run the risk of forgetting to set it in two places. That way the two (or 3 or 4...) are always in sync.

You can also link into page lifecycle events and dump state into local storage when the page closes or navigates away if thats the goal.

[dannief]

@bcomnes That's a good idea re the function. I was thinking about something along those lines as well
Linking into the page life-cycle was something I hadn't though of. I have to try that. Thanks 👍