-
Notifications
You must be signed in to change notification settings - Fork 0
Future Actions Syntax
Packaging action data onto an object provides 'named arugments' but leads to a bunch of boilerplate whenever you want to process an action as you peel the arguments back off.
Actions that do not pass data (somewhat an anti pattern, but not unreasonable) are ridiculous as they have no payload.
Trying to use the packager function as syntactic validation is cumbersome and unpredictable.
-
Action args are simply positional arguments passed straight from the action caller to the action callbacks.
-
createAction (or equivalent) declarations are only required if multiple stores listen to the same action.
-
createAction's function is simply a validation function on the syntactic correctness of the passed arguments. It is therefore basically argTypes to React's propTypes.
app.create.store 'foos',
stores: ['bars']
actions:
'foo.create': (fooData) ->
@update(fooData.id, fooData)
'bar.setId': (barId) ->
@update(fooId: @stores.bar.getDefaultFooId())
app.create.store 'bars',
actions:
'bar.setId': (barId) -> @update(barId: barId)
app.create.action 'bar.setId', (barId) ->
@isNumber(barId)
given these stores and actions:
app.actions.foo.create(id: 12, baz: 42) # fires action
app.actions.foo.create(id: null) # still fires action
app.actions.bar.setBarId(12) # fires action
app.actions.bar.setBarId(null) # doesn't fire action, logs an error
- importing namespaces onto views would be nice. Not sure what to do about collisions.
app.create.view 'list',
stores: ['bar']
actions: ['bar']
render: ->
@actions.bar.setId()
@bar.setId()
@stores.bar.getId()
@bar.getId()