💡 Features from Redux that I would like to see in react-easy-state

[rodryquintero]

Here are a few things that I like from Redux that I think could enhance this great lib:

• Single global store: it is very useful to have access to the whole store from any part of the application. Perhaps some documentation on how to do this properly would be useful.
• Action log: in Redux I am able to console.log any action type in any reducer. This is very useful for debugging.

I made a simple counter app with this library and I really like it. I am considering rebuilding a work project to react using this state management library. Great work!

[solkimicreb]

Hi!

First things first, this is a TodoMVC example with a single global store: https://github.com/solkimicreb/react-easy-state/tree/master/examples/todoMVC. You just create a store in a file (let's call it appStore.js) and import it wherever it is needed - with import appStore from 'appStore'. I wouldn't recommend it for big apps though.

For me the best working pattern so far is this: Have a separate global store for every app page and have a lot of small local state stores for reusable components. Reasoning:

• App pages are singletons (only one page is displayed at a router level at a time), so they are a nice match for singleton global stores. Having a single, common store for the whole app can get messy and it doesn't play nicely with code splitting, lazy loading per page and separate dev teams per pages.

• Having local stores for reusable components makes them ... reusable. If you want to reuse something, do not let it pollute the global scope with state.

This is my way of doing things and it may not be the best though.

About debugging:

I agree, that it is really needed. I just don't know how to go for it, there are no real equivalent of Redux actions in Easy State. Do you have any other favorite Redux debugging patterns?

Thanks for the issue!

[solkimicreb]

A built-in debugger is under development, I think you will like it 🙂

Edit: it will take around a week more until the debugger release (meaning February 8-ish).

[solkimicreb]

A quick update about the debugger. Currently it's a drill down style logger, which can be enabled separately for each component with view(Comp, { debug: true }).

• It logs each render of the component.

• If you click on the log, you can see why Easy State scheduled a render for that component. The reason is always a property set/add/delete operation on a store or a shallow change of the component's props. Multiple mutations/scheduling may be batched to run a render once only, this is up to React Fiber to decide.

• If you click on the reasoning it lists a few formatted stack traces, which show you where exactly the store property was used and mutated in your code. You can click on the links the see the place in the source code.

Is there anything else you would like to see? Is this the 'right direction' to start a debugger? What exactly do you use debuggers - like this - for?

[rodryquintero]

This is nice. I guess I can setup actions 'a la flux' just to label what triggered the update. Very thoughtful. This should cover my needs for now.

Is this feature available on the latest release?

[solkimicreb]

It is not yet released. I have to tweak/test/document it, February 8 still seems like a doable release date. I just wanted to see if it is useful beforehand 🙂

Edit: I am not yet satisfied with what I made, I will need some more time until the release.

[ro-savage]

@solkimicreb - Would like to try out this logger / provide feedback. If you've got it in a branch / next

[solkimicreb]

I will put it on a branch tomorrow and write a short doc about what and how I want to do. I spent most of my time with preparing the underlying Observer Utililty library for the changes so far.

[solkimicreb]

You can find it on the next branch. There won't be much debugger related changes in this lib.

Basically I spent my last week to prepare the underlying Observer Utility lib. It now pushes out a lot of data about state access/mutations to a passed debugger function. Easy State will proxy this to it's own devtool option and it will also add a few more events (like render, mount, unmount).

It is designed in a way to eventually make the following possible:

• Redux style time travel and session saving / loading / replay (this already has a working prototype).
• Hot reloading with keeping the state (hopefully).
• A drilldown timeline.
• Tracking the property mutations and accesses (in renders) to show the exact reasoning why a render was triggered.

The debugger is a very dirty React App on my Mac currently, I will try to push to a WIP repo ASAP (hopefully today).

[solkimicreb]

v5 has an experimental interface for connecting debuggers. You can test it out with view(Comp, { devtool: console.log }). It just pushes out a huge amout of raw data - related to the view. A more sophisticated devtool is in the making and I will put a prototype in a separate repo soon.

All the needed is data is available now, but the devtool will require a lot of development effort to make it as useful as the Redux one. I will let you know how can you contribute, if any of you are interested 🙂

[ivan-kleshnin]

Devtool would be great, yes. I see devtool and debug options are still undocumented. Will it be possible to log store instances directly (not only through their views)?

[solidpulse]

just another way to debug:

let myStore = store({})
window.myStore = myStore;

you can then access it in the chrome console or even better, you can simply attach it to be watched in chrome -> sources tab.

[ciaoben]

Do exist a new way to debug? I notice that devtool and debug options are gone

[joshuaquek]

Is there any way to use the old debug feature? That worked for me earlier, but now has been removed

Is there any way to re-introduce the feature that was mentioned by @solkimicreb ? (the comment above with screenshots posted on 4th Feb 2018)

[JDMathew]

Following up on the debug feature. This would be something super useful I to many I think.