Dev Tools

[bowheart]

Zedux has amazing dev tools support, but we haven't published any dev tools for it yet. Let's change that!

We have an old StateHub React component that we stopped maintaining over a year ago. It had a few problems:

• React is slow. Zedux is designed to handle thousands of updates per second, but rendering all those events in the StateHub React component adds a lot of overhead to complex apps. The DOM paints will still need to be batched even without React, but using something faster will help a lot.
• Couldn't get a graph visualization design we liked that was also useful.
• The overall design was too complex - lots of icons and extra features for "power users" that no-one will really use and only serve to confuse beginners (including advanced users who only occasionally pop open the dev tools).

This discussion will keep track of progress toward making the new dev tools:

• Creating a new design
• Exploring faster rendering:
  • Possibly using Solid and creating a new Zedux Solid integration library.
  • Possibly creating a Zedux Signals library for interop with stores, atoms, and a new signal primitive.
  • Possibly creating an entire Zedux View library patterned after Solid but using atoms.
• Putting together the core dev tools UI
• Creating the chrome extension
• Creating the dockable React component

Feature list:

• Ecosystem selection
• Log page - monitor atom status changes, state updates, graph updates
• Atoms page - see current state of an atom (if it can be stringified, otherwise use a button to log the state to the console).
  • A single filter input that accepts accepts advanced search syntax for power users but provides a useful quick search default behavior for beginners (For example: my-atom will fuzzy search for atoms with ids matching the string my-atom. key:user status:Stale state:role:admin will search for atoms whose template key matches user, whose status is Stale, and whose state contains an object with role: 'admin'
  • For sorting: If we use a real table, it can be sorted by column. Or add some quick-sort buttons to sort by update frequency, creation time, last update time, status, slowest average evaluation, injectors used, graph weight.
• Graph page - see a visualization of the atom/selector graph. New plan is to pattern this after the DOM view. Show a top-down or bottom-up view where each top-level node is the roots or leaves (respectively). These nodes can be expanded recursively like the DOM.
  • Same filter input on this page. Will auto-expand nodes to show matches and highlight them

If you have any features that you're dying to see in the dev tools, absolutely feel free to comment! Everything within the realm of possibility is on the table for this redesign. And it's a pretty big table.

[Aleksion]

Hi!
What's the status on this?
I'm increasingly intrigued by Zedux, but not being able to debug the state of my atoms makes it hard to truly get going.

Alternatively: Is there a guide for how to integrate this with Redux devtools or similar?

[bowheart]

Hey! Thanks for asking.

July was busy for me. I mostly just lost momentum trying to get back to it this last month. Definitely motivating to hear people need it.

There is a lot of work still to do with it. I'll keep this discussion updated with progress. As my schedule is looking, my initial estimate is 2 months to get all the features listed here basically in place. But I can potentially release something much simpler much sooner (perhaps even this week).

@Aleksion What features do you need most? And would you use a dockable React component or does it have to be a browser extension?

In the meantime:

We debug Zedux by putting the root ecosystem on window and running stuff like the following in the browser console:

// to get atom instances related to what I'm working on (assuming their keys are prefixed with "my-feature"):
ecosystem.findAll('my-feature')

// to see current state of those atoms:
ecosystem.dehydrate({ include: ['my-feature'] })

// to debug graph connections - e.g. to see if something is holding onto an atom
// that I expected to be destroyed:
ecosystem.viewGraph()

injectWhy() is also a life-saver sometimes (pretty rarely) when an atom is updating unexpectedly.

The only other thing we add sometimes is a plugin to see when atom instances are created/destroyed.

const statusLogger = new ZeduxPlugin({
  initialMods: ['statusChanged'],
  
  registerEcosystem: ecosystem => {
    const subscription = ecosystem.modBus.subscribe({
      effects: ({ action }) => {
        if (action.type !== ZeduxPlugin.actions.statusChanged.type) return
        
        console.log('[Atom Instance Status Changed]', action.payload)
      }
    })

    return () => subscription.unsubscribe()
  }
})

myEcosystem.registerPlugin(statusLogger)

Plugins documented here. I know all of this is pretty low-level and certainly not a replacement for real dev tools. But it's still usable. All of the functionality is there, we just don't have a pretty UI doing heavy lifting (like time travel) for you yet.

Redux Dev Tools

I actually did hook up an early version of Zedux to the Redux dev tools so I know it's possible. It's been a while and I don't think I ever did get it working perfectly so I can't say I recommend trying this approach.

It could be worth looking into, but I'm not dedicating time to that right now. We know we want our own dev tools anyway for all the atom-specific and other Zedux-specific features so I'd rather dedicate my dev-tools-building time to that.

[Aleksion]

I'm hacking away so anything bare bones helps - it doesn't need to be a full extension etc.

First of all:

1. easily inspect all atom changes
2. Be able to track and understand changes
3. Be able to mutate state (fire actions?)

Most dev tools in the atom space don't have 3. - I find that that's the real super power.

For now I'll do what you're doing and log it to window.

On that note: is Zedux still being maintained?
I'm loving it so far and the "effects" implementation solved one of my biggest annoyances with Jotai.

But "diving in" is seemingly a lot more complicated with Zedux than the alternatives.

[bowheart]

Most dev tools in the atom space don't have 3.

Good point. I'm not sure how I'd plan on allowing manual state updates in the dev tools themselves. If the state is serializable it's simple enough to allow direct editing of the JSON string. Could also add a button to log the atom instance to the console so you can right click -> "Store object as global variable" and manipulate it from the console.

For now, I use:

ecosystem.find('my-specific-atom-instance').setState(whatever)

easily inspect all atom changes

Btw you can accomplish this with a plugin too for now:

const stateChangeLogger = new ZeduxPlugin({
  initialMods: ['stateChanged'],
  
  registerEcosystem: ecosystem => {
    const subscription = ecosystem.modBus.subscribe({
      effects: ({ action }) => {
        if (action.type !== ZeduxPlugin.actions.stateChanged.type) return
        
        console.log('[Atom Instance State Changed]', action.payload)
      }
    })

    return () => subscription.unsubscribe()
  }
})

myEcosystem.registerPlugin(stateChangeLogger)

is Zedux still being maintained?

Zedux is very maintained - we use it every day at Omnistac and discuss various aspects of it all the time. It's the only state manager we know of that is really designed for handling the kind of highly volatile state we deal with and that provides escape hatches for every possible use case. I'd say it's very unlikely we ever switch to anything else.

Dev may seem slow right now, but that's mostly because Zedux is already very stable. We didn't open-source it until we'd already been using Zedux in production for over 2 years.

We may eventually get around to dedicating time to making full-fledged addons like a form lib, a query lib, and possibly a graph lib. Until then, it's mostly me doing smaller changes on my own time (not that I don't have enough time to dedicate to doing bigger features, there just aren't any big, new additions we have need of right now). Also there are quite a few people (idk how many, at least 10) with write access to the Zedux repo. I'm the only one who actively uses that power currently, but others may start contributing more.

a lot more complicated with Zedux than the alternatives.

This is probably expected. We created Zedux because Recoil and Jotai were both missing quite a few must-have features for us. Side effects were a big one - Recoil's effects weren't stable ("stable") yet and Jotai didn't even have onMount when we made the first version of Zedux.

Adding those features makes Zedux more powerful, but also naturally more complex. But yes, that should only be the case when really "diving in" and making the most of Zedux. Most apps shouldn't need some of the more advanced features. Especially with e.g. plugins, the goal is eventually to make it so most people never have to know those exist (dev tools use them for you behind the scenes).

[Aleksion]

I love the detailed response here.
I'm loving it so far, and I'll keep tinkering and playing with it.
I'd love to share feedback, ideas and potential contributions if I keep going.

But for now - thank you for what you've shared and put together here!