okwolf / hyperapp-logger Goto Github PK

When an action is not creating a brand new object but extending the existing one before returning, logger will log the original reference instead of a copy/deep clone. The object gets updated before it's printed to the console and both prev and next logs are identical, which is misleading.

Possible fixes:

• deep clone the state object on prev before logging
• pause execution when logging to make up for console.log being actually asynchronous (probably a bad idea)
• documentation to clearly state this happens if you're lazy and don't implement actions with the assumption that the state is immutable.

As noted in the subject, the Typescript type definitions for the library are yet to be done.

in index.js line 18: var result = action(data)
it seem that action can only take one parameter ?

error when action with more than one parameter

const actions = {
    test1: (a, b)=>(state, actions) =>...
    test2: (state, actions) =>...
}

Summary

Let's rename the named export to withLogger and this way, start a naming convention for all future higher-order-apps, e.g. window.withGizmo. I am not proposing we add a prefix to every package; I think @hyperapp/html should continue to be available as window.html.

Related

• mrozbarry/hyperapp-debug#1

Hello there,
I'm constantly getting the above Error passing any of the view of my app.
I'm invoking the logger from a class constructor:

withLogger(app)(state, actions, this.views.intro(state), document.body);

And yes, this come from the hyperapp in the render function, but indeed the node of the view is undefined.
Anybody having an idea what I'm doing wrong?

This would enable the following simplified syntax:

logger(app)(state, actions, view, document.body)

while still preserving support for the current syntax:

logger(options)(app)(state, actions, view, document.body)

I already wrote an implementation that supports this in my hyperapp-effects library, since it started with no options, and then added them without a breaking change.

Today the only available option is log to provide a custom logging function. It's a good escape hatch that's highly flexible, but I'm wondering if there should be other options in between. Not proposing to copy every option redux-logger supports, but maybe some are worth the effort.

Here are some proposed options:

• filter - provide a filter function to decide which actions to log and which to ignore. The filter function is passed the {name, data} object describing each action. Defaults to show all actions by always returning true.
• format - function to pre-process the state values before being passed to the logger. This allows for returning a new object with the state reorganized to be more readable or in a preferred String format. Defaults to the identity function.
• diff - try to print an intelligent diff of what state the action updated. In the case of redux-logger deep-diff was used. Defaults to false.
• performance - show how long the action took from start to end. Defaults to false.
• timing - show the time the action began and/or ended. Defaults to false.
• sameStateWarning - include a warning when not returning a new state object from an action. Defaults to false. See #3.

Imagine the following scenario:

const state = {
  counters: {
    count1: 1,
    count2: 2,
    count3: 3
  }
};

const actions = {
  counters: {
    inc1: () => ({ count1 }) => ({ count1: count1 + 1 })
  }
};

Let's run inc1() action and here's what we see...

prev state:

{
  count1: 1,
  count2: 2,
  count3: 3
}

next state:

{ count1: 2 }

What's expected next state:

{
  count1: 2,
  count2: 2,
  count3: 3
}

Right now logger simply returns the result of an action, and I strongly believe that it should return merged slice of a state.
Here's an illustration

BTW, thanks for logger!

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 🍰 😋