Closed okwolf closed 6 years ago
It is pretty painful that you can't pass the global state to actions anymore. Even as an optional 4th arg, it would be so useful!
For general logging of actions, I think it's probably fine to only see the state slice. As you said, the global state can't affect the outcome of the function.
For general logging, just the state slice should be alright. But I started thinking that maybe the logger could be more than just a logger. Maybe it could be the point where stuff like HMR and time travel debugging could hook in (rather than make separate HOA for those) In that case the logger (or general "do whatever" HOA on which a logger could be based) would certainly need the full state for every action.
@SkaterDad FWIW I too miss global state and actions a little bit. I used to use custom events for cross module communication (because events rather than direct action calls let you avoid dependency hell). I made a HOA to replace them, which you could use to get access to global state and actions, if you want to. https://github.com/zaceno/hyperapp-events
@zaceno For general logging, just the state slice should be alright. But I started thinking that maybe the logger could be more than just a logger. Maybe it could be the point where stuff like HMR and time travel debugging could hook in (rather than make separate HOA for those) In that case the logger (or general "do whatever" HOA on which a logger could be based) would certainly need the full state for every action.
I think that would be pretty major scope creep for @hyperapp/logger
, although I could imagine a future hyperapp-devtools
meta-library that would compose multiple HOAs together for great justice! Or perhaps some standard way of handling these action lifecycle/hook style HOAs like hyperapp-middleware
might emerge. 😊 🔌
Closing this due to lack of activity and slice behavior being well established now.
One consequence of adding support for
state
slices 🍰 /modules
in Hyperapp is thatactions
only receive their 🍰 of thestate
and can only return updates to that 🍰 . This extends toactions
wrapped by an HOA as well.This is good because:
it only shows you the 🍰 of the
state
that can change during an action, cutting down on extraneous information while debugging.This is bad because:
it won't show the other global
state
at the time the action ran. However, since the globalstate
is unable to affect the outcome of an action that runs against astate
🍰 is this actually useful?Here are some of our options:
state
🍰 like we do today.state
. This will need some hackery to get the entire globalstate
before and after the update happens.log
function and leave the default logger as-is.options
for switching between 🍰 and globalstate
. The default could be either one.Now I need to go eat some 🍰 😋