yoshuawuyts / barracks

:mountain_railway: action dispatcher for unidirectional data flows

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

discussion: should we allow registering models after the application has started?

toddself opened this issue · comments

The following doesn't work it seems:

const store = barracks()
store.start()
store.model({some: 'model'})
store.start()

The reducers, subscriptions and effects don't get parsed out of the model, so trying to call send('ns:action') throws an error saying there is no action for it.

When you inspect the store object after you can see that _reducers, et al are empty but the model does exist.

commented

Any given property on the models can only started once now. Once stuff has been started there's no way to attach extra models currently. I've been thinking about this, and while dynamic model attachment might make sense I'm not entirely sure we should support it. What do you suggest we do?

I feel like dynamic model attachment might make some good sense for some (ab)uses of barracks as decoupled from the choo-ecosystem.

I haven't delved too deep into the code here -- is there anything gained by batching the model iteration to when start is called via handling it via the model function?

commented

We definitely want to start subscriptions after the dom has loaded in most cases. Also definitely don't wanna start most of the model stuff if we're rendering on the server (but do want the initial state) - I think we could only add support that if a certain section has started, it's booted directly rather than pushed into the "to be started" array

commented

Updated title

commented

oooh, or we could have dynamic models which can be swapped out with other stuff.... hmmmmm - like this (from IRC): https://gist.github.com/MelleB/654d8763892eb10ea4718691d611b72a

e.g statically declare a model and then make it dynamically call other stuff within it. Would "solve" this kind of logic; only caveat is for logging but I'm sure we can come up with something