yoshuawuyts / barracks

:mountain_railway: action dispatcher for unidirectional data flows
MIT License
177 stars 22 forks source link

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

Open toddself opened 8 years ago

toddself commented 8 years ago

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.

yoshuawuyts commented 8 years ago

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?

toddself commented 8 years ago

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?

yoshuawuyts commented 8 years ago

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

yoshuawuyts commented 8 years ago

Updated title

yoshuawuyts commented 8 years ago

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