Wolf

Since the view/components are stateless, my best guess would be maybe calling the lifecycle events for [`onremove`](https://github.com/jorgebucaran/superfine#onremove) and [`ondestroy`](https://github.com/jorgebucaran/superfine#ondestroy)? Assuming we are keeping those going forward.

The root cause, of course, is that Hyperapp performs a shallow merge of your action result/return with the existing state in the same slice and finally returns only the partial...

@rishavs are you familiar enough with **Type**Script to take a stab at this? PRs welcome!

> @rishavs I actually started on Typescript just a day ago. Then maybe there's still some hope left for your eternal soul 😂 All joking aside, I'm curious what made...

@jbucaran good point. For now I'm going to keep drawing inspiration from redux-logger since I know it best, but I'm open to suggestions for other good loggers to borrow features...

@jbucaran see the updated list of proposed options above.

@jbucaran I agree with the priority, reordered the list. I also like the shorter name suggestions. To me `performance` is a better fit if the info displayed is how long...

> @jbucaran Gotcha. So, the question is which one is more useful or can we have both? ;) I think we should either have an option for only one of...

@jbucaran for `filter` do you think there's any value in providing the `prevState` and/or `nextState` for the filter function to decide logability? How about `format` for `action`s? 🤔

> @jbucaran I thought `filter` would just be an array with action names. That would be an alternate option, but my original proposal would take the full `{name, data}` object...