okwolf / hyperapp-logger

Log Hyperapp state updates and action information to the console.
MIT License
47 stars 5 forks source link

State Slices 🍰 #8

Closed okwolf closed 6 years ago

okwolf commented 7 years ago

One consequence of adding support for state slices 🍰 /modules in Hyperapp is that actions only receive their 🍰 of the state and can only return updates to that 🍰 . This extends to actions 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 global state is unable to affect the outcome of an action that runs against a state 🍰 is this actually useful?

Here are some of our options:

  1. Log only the state 🍰 like we do today.
  2. Log the global state. This will need some hackery to get the entire global state before and after the update happens.
  3. Add more arguments to the custom log function and leave the default logger as-is.
  4. Add a flag to options for switching between 🍰 and global state. The default could be either one.

Now I need to go eat some 🍰 😋

SkaterDad commented 7 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.

zaceno commented 7 years ago

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.

zaceno commented 7 years ago

@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

okwolf commented 7 years ago

@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. 😊 🔌

okwolf commented 6 years ago

Closing this due to lack of activity and slice behavior being well established now.