Hacker News Reader

Comment by programnature | Hacker News Reader

This is extremely similar to DevCards for Clojurescript, https://github.com/bhauman/devcards, https://www.youtube.com/watch?v=G7Z_g2fnEDg

View on HN

DevCards is great! Bruce has put a lot of work into making it a really smooth experience, and advocating the benefits of building your components outside of the application first.

I've been working on a more-or-less direct port of devcards into standard React / JS - it's available here: https://github.com/glenjamin/devboard

Dan Abramov's DevTools[0] with Hot Reload and "Time Travel" (historical debugging) is basically the same thing too, though its tied to Redux pretty heavily IIRC. So yeah, nothing new. ("TimeWarp OS"[1] was a project developed in the late 80s that did the same thing at the OS level, primarily for physics simulations. (Something would break, you'd go back to state foo, change parameters mu,delta,sigma to yield foo' and continue the run.))

[0]https://www.youtube.com/watch?v=xsSnOQynTHs is the canonical talk on it, certainly worth a watch.

[1] http://www.cs.nyu.edu/srg/talks/timewarp.pdf Brian Beckman formerly of Microsoft as a second author. All those RX features I'd imagine were done largely in part by him and De Smet.

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.

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.

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.

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.

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.

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.

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.

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

DevCards and Figwheel are amazing. As much as I love React and its hot reloading plugins, `lein new figwheel` has always worked better than cloning a boilerplate or setting stuff up.

Reply on news.ycombinator.com