[arunoda]

Time time debugging is something different here. It's on working with different states of app and try to find issues.

This is a way to list components and show their different use case. We can also develop individual components by just looking at this.

[iheartmemcache]

I'm missing something, I think. Walk with me through a hypothetical example. I load component todo-list. Dan used integers to mark each modification of virtual DOM, so lets define this as an revision of 42, saved-state-0, labelled with a reference "Populated todo-list", after {"quuz" "bar" "baz"} have been added as elements all bool, all incomplete.

OK, now you can save a ref to this state state, i.e., Component 'todo-list' is now rev 51 (on the vDOM) saved-state-1 (with a reference to rev 53) with a rendering label of : "Bar complete". Check off the 2 remaining elements for component todo-list, we now have saved-state-2 (a reference to rev 53) with label : "Tasks completed".

I'm not saying that what you built isn't useful (I'm 100% certain it is!) but I don't see how it's any different from taking an append-only journal and adding bookmarks to save state, though I really could be missing something since I don't work front-end.

[CognitiveLens]

It looks like React Storybook uses a similar set of principles to what you're describing but organizes them for a different use case than Redux DevTools. You definitely could build something like React Storybook using Redux DevTools, but from what I understand React Storybook provides a pre-made standalone app wrapper + server that consumes components and applies state specs ("stories") in a 'standardized' way for browsing - you would have to write your own app to leverage Redux DevTools (or even just plain React since you don't have to keep undo/redo info) for the same purpose.

[glenjamin]

The fancy part is assembling stories for showing all the different states. This is even more powerful if you show them on the screen at once.

Imagine having all the examples below shown on screen, and then editing your component definition and having the hot reloading update them all at once so you can see the effects.

    Todo item normal:
    [ ] A thing to do

    Todo item checked:
    [x] -A-thing-to-do-

    Todo item editing:
    [  A thing to do  ]

    Todo item hovering:
    [ ] A thing to do  [del]

    Todo list show all:
    [ ] ABC
    [x] DEF
    [x] GHI
    3/3 items

    Todo list show incomplete:
    [ ] ABC
    1/3 items

    Todo list show complete
    [x] DEF
    [x] GHI
    2/3 items

[Wintamute]

I think the selling point for devcards/React storybook et al. is that of a live/visual styleguide of UI components. Imo its raison d'etre is that it promotes a UI component centric methodology for developing web apps, whereby designers and developers can develop UI components in isolation away from the cognitive noise of how those components come together in a single monolithic app. That's the innovation here, if you can call it that, ... the state travelling stuff is an implementation detail.

[d0m]

I can see how useful it is for the less technical part of the team as a way to see all components and their important states.

[lygaret]

To me it's not even non-technical users, or juniors: this is a way of documenting components and their important substates, the same way a CSS styleguide does. It can help keep consistency of use, document features and states that may be overlooked by a consumer, or act as a framework for design QA.

[glenjamin]

It's not even just documentation - you can use it like visual unit tests, so you can see what the effects of a change are to all the different states of a component.