Return the state fragment to the caller if the action is a reducer.

[jorgebucaran]

Now actions.myAction will return whatever the original myAction function returns. Before, this was only true if myAction returned a Promise.

Example

app({
...
  actions: {
    getState: state => state
  }
...
})

Diff: 0 bytes.

Fix #242.

[codecov]

Codecov Report

Merging #243 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #243   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           4      4           
  Lines         165    165           
  Branches       45     45           
=====================================
  Hits          165    165

Impacted Files	Coverage Δ
src/app.js	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 316b2a8...86f3a08. Read the comment docs.

[jorgebucaran]

🎉 💯

[FlorianWendelborn]

So does this still update the state or did you just implement my suggestion regarding getting rid of the weird return to update functionality?

[jorgebucaran]

@dodekeract This returns the result of an action to the caller, whatever that may be.

This just helps with @zaceno's use case without breaking the API.

Maybe @zaceno can explain it better?

[zaceno]

@dodekeract: still updates state. I kind of still wish we could have getters, i.e. same as actions but dont update state -- just return out whatever the inner function returns from the state.

... thinking maybe you'd be more ok with the behavior of actions if there were getters to use for when you don't want the state to update?

[jorgebucaran]

@zaceno Those are the old effects no? Maybe we can come up with another clever way?

[zaceno]

@jbucaran -- that's right! Hadn't thought of it before because I always thought of effects as a way of batching and/or deferring reducers -- not as a way of getting/processing data from the state -- but the old effects could work for that too.

I'm open to thinking about & discussing clever ways to get that behavior back. But to be fair you shouldn't give my opinons on hyperapp's state management too much weight, since I've switched my personal projects from away from hyperapp, to picodom + my home made state management solution (which I'm still very much experimenting with)

Anyhow, here are my thoughts:

I feel like we've already "violated" the reducer principle when we allowed actions to return a promise, and in that case not update the state. So we could always take that a step further, with other "magical" ways of returning in actions, that don't cause state updates. Like perhaps if what you returned was an object {update: false, result: x} then the action would return x without updating state.

I grant you, that's not very pretty. I'd much prefer something along the lines of what @dodekeract already suggested, which is that actions always return with the inner-returned value, and don't update state by default. Instead they are passed a setState or similar function to be used inside the action, when you actually want to set the state.

[jorgebucaran]

@zaceno Thanks for the feedback! Definitely, something to think about.

[FlorianWendelborn]

without breaking the API — @jbucaran

Not true. In complex actions I'm often using return actions.someOtherAction() to end the action execution and forward it to a different action.

Now, this would update the state twice which may even lead to race conditions or hard to track down bugs.

Actually, I just upgraded from 0.9.2 to 0.9.3 and my whole application is so broken that the state isn't even initialised. I'm getting "can't access something of undefined" in all components, lol.

[jorgebucaran]

@dodekeract I see what you are saying. I can try to give priority to #90 (leaving #238 for later) and see if that helps, otherwise, we can reverse this.