choojs / choo-store

Lightweight state structure for choo apps.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Re-order event functions

jondashkyle opened this issue · comments

This is awesome! Only thing which stood out to me is the prop ordering differs from choo. state, emitter (choo) vs emitter, state (choo-store). What are thoughts on restructuring that, and perhaps exposing app as well?

function event (options, store, state, emitter, app) { }

Really awesome work!

Hey @jondashkyle! So in the context of choo-store, store represents state local to this store. The idea being it encourages manipulating local store and using events to manipulate state in other places (rather than manipulating a namespaced store in this store). Another way to look at it would be:

function event (options, localState, emitter, globalState) {}

I also like this ordering because it makes it easier to drop global state as a param when not needed:

(opts, store, emitter) => {
  store.foo = opts.baz
  emitter.emit('render')
}

Having the app level state as a third parameter means you'd have to include it every time you need the emitter regardless of whether or not you're using it. Which is not terrible, just more typing.

Another option which deviates from choo but is more flexible is a single object parameter with named keys so you can pluck what you need and not care about argument order at all.

function event ({ options, store, state, emitter, app }) {}

I've never used app in the context of a store but I do remember reading yesterday that it's made available by choo, so I agree that should be added.

Totally open to more thoughts and changes, just want to share my reasoning and see what you think.

Another option!

function event ({ state, emitter, store, app }, ...eventArgs)

I think above is most flexible, since any number of arguments can come from nanobus and we don't want to make that more difficult to process, and parameter ordering for other things is made irrelevant too.

Totally makes sense as you’ve explained it. Thanks for that! Pretty into passing event args into options and deconstructing the object to order however you’d like.

Ok released a new version (0.5.0) with reworked event parameters.

function event ({ data, store, state, emitter, app }) {}

I renamed options to data because it sounds a bit more type agnostic, as data could be anything. Also less letters to type.

Thanks again for your feedback!

Forgot about my second comment above (#1 (comment)) -- open to another refactor to go with that style instead, as needed.