Normalize actions/events signatures.

[jorgebucaran]

tl;dr

Make all functions in the API follow the same signature:

(state, actions, data, emit)

---

Now

• view(state, actions)
• actions.myAction(state, data, actions, emit)
• events.loaded(state, actions, emit)
• events.action(state, actions, data, emit)
• events.update(state, actions, data, emit)
• events.render(state, actions, data, emit)

After

• view(state, actions)
• actions.myAction(state, actions, data, emit)
• events.loaded(state, actions, emit)
• events.action(state, actions, data, emit)
• events.update(state, actions, data, emit)
• events.render(state, actions, data, emit)

Tentative: Pass the options (the same from app(options)) object to loaded as data, so it can match the proposed signature too. 🤔

[FlorianWendelborn]

events.loaded(state, actions, emit) — @jbucaran

Maybe it's better to just use state, actions, _, emit here, where _ is (right now) always undefined? It streamlines everything and if we ever decide that we need data we don't have to break the API.

It's also not unheard of. JSON.stringify({}, null, '\t') is similarly used. Of course null doesn't have to be null here, but I've seen this a lot.

[jorgebucaran]

@dodekeract Good point!

[jorgebucaran]

This is a breaking change, as you'll need to modify all your actions signature from:

(state, data, actions)

to

(state, actions, data)

@selfup @pedroborges @cdeutmeyer @lukejacksonn Are we okay with this?

[lukejacksonn]

The difference between (s,a,d) and (s,d,a) has always niggled me and it would certainly mean one less thing for users to remember.. for these reasons I am all for it.

I also support @dodekeract's statement of using state, actions, _, emit for loaded. Just to keep things super consistent. Your proposal @jbucaran of passing options as the data for that function is also not a bad idea at all 👍

[jorgebucaran]

c29970c 🎉