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.
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.))
[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.
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.
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
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.
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.
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.
In React-land, most component should be standalone pieces, but without any immediate joyful benefits it's easy to loose that requirement as complexity grows. Eventually, this can cause the guts of the app to be a lot more interconnected than I'd want for a clean architecture. I expect adding a working gallery of app components (through Storybook or Cosmos) would bring the joyful benefit I need to be more consistent in force true component encapsulation, which may require better thought-out components.
First impression : Storybook looks beautiful! Thank you for this. Developers like beautiful UIs as much as anyone.
I'm currently working on a simple React.js commerce platform and even in it's early stages I'm already wrangling tens of thousands of lines of UI code. Anything to make React development easier is welcome.
Also, thank you for bringing awareness to how hard building a proper UI is in your Medium post.
I'll try to give you some more thorough feedback on github.
I am curious to find out if you have any plans for future features or where you see this project going from here?
Usually you would use bold like that where you would stress the vocalisation when reading it aloud, not for highlighting key points you want to make. If you read that and stress those words it just sounds weird and confusing.
> This is the first time, I got a feedback on this.
That comma placement is strange too. I'm thinking not a native english speaker. It's a great tool though. Not taking away from that at all. Thanks for making it. :)
In the spirit of providing feedback to help improve the documentation, and with regard to the bold text:
The article made it difficult to find out what React Storybook is quickly.
The style of article is informational, which is usually written like a pyramid. High level information at the top, then works into more detail-oriented sections, most important first. For example, "any react application" would probably come in the second paragraph, after the high level intro as that was an important point (based on the repetition) in the bullets.
It's one of the reasons I prefer Storyboards over coded views in iOS development. The immediate feedback in the designer instead of compile / reload. They even got better with live views. Having the behavior simulated for different data sets would be the icing on the cake for me. This idea is so great it makes me wonder why it didn't exist yet (but perhaps there's something very similar out there already?)
I developed in Android first, then iOS, and I don't like storyboards (git merge conflicts, clunky drag/drop outlets, and more). I also found the XCode ide to be pretty terrible compared to Android Studio.
I have about 3 years of iOS experience and I have a love hate relationship with storyboards.
I think the introduction of auto-layout has made it them more powerful , but also a bit confusing.
Apple really needs to work on the UX in interface builder. I should ideally be able to see most of the constraints at a single glance rather than clicking on each every view to find out how it relates to the views around it.
I can create UIs reasonably fast now , after mastering all the tricks and UI shortcuts.
However as your parent mentioned , it is a fact that Android developers are able to create UIs faster. I know this since our team works on the same features on both platforms.
It used to be that Android used to really suck , but for simple standard UIs , mocking up something is much faster now on Android. And their layout system while not as powerful as Autolayout is enough most of the time and easier to grok.
The only thing they still struggle with are animations and device / OS fragmentation.
The idea has been around in the frontend community for years in the form of UI harness and hundreds of other react based projects like this one that do effectively the same thing.
I actually use my personal website for this. I build out components to play with data on top of API's I've built. It's fun as hell and pretty great for all the reasons that this is great, albeit not quite as shiny.
It seems like the same thing could be accomplished with a simple demo page inside of your app for testing new components. Some problems I see:
-Lots of UI components depend on the context of the page they live in and can't be developed in isolation
-Dummy data means you'll miss tons of weird edge cases. Your to-do list works great until it gets real data with 300 items and long, unbroken strings
-Any design team technically savvy enough to tweak and style components themselves should be able to clone the repo, run the app locally and do it within the app
I'm open to being wrong, but I don't see the value in this.
It's pretty powerful[0] because it captures a variety of states a component can exist in. I see it being very useful for exposing new team members to the application, as well as the obvious potential test coverage possibilities (it's not a state machine, but its better than nothing), and separating concerns.
You don't really have to use dummy data at all. If you're using a typed JS, use something like Haskell's QuickCheck to auto-generate your test coverage. With types, it'll fuzz you with everything it can throw at you, with the actual intention of breaking your app with 300 elements each with convoluted, unicodey hogwash.
When you bring types into it, things can actually get fun, because just like with immutable FP you can get certain deterministic guarantees, with a decent type system you can actually implement a state machine to capture all of your possible states and transitions, using your sufficiently strong type system + the states/transitions + QuickCheck arbitrarily throwing junk into each form field (annotate the type with a constraint, Date.prior_to_now(18,0,0) on field `D.O.B' => (state loops back on itself with errors[] now having 'underage_registration_error'))[1]
[0] The concept, that is, this implementation is re-inventing the wheel/nothing-special. Read my other comment on TimeWarp OS which is literally 30 years old.
[1] https://i.imgur.com/7jHldss.png Literally 5 minutes of work (of which, 3 were me learning the DSL). Hopefully it conveys the point though.
I see this as the equivalent of unit-testing React components, but for design.
1. React is built with the intention of highly-isolatable components. Using a tool like this (just like tests) can encourage developers to keep things isolated. But if that's too problematic in practice, I think you're right this tool wouldn't be useful.
2. This helps provide dummy data for visual tests. His edge cases here don't include those crazy things, but this is a much easier way to test that than doing so manually.
3. Doing it within the app is easy, but getting to the right "state" to see the component as you want is hard. And isolating a given feature can be nice for design.
- If your components depend inextricably on the context of the page, you're building them wrong. They should accept that context parametrically.
- If your dummmy data not including 300 item lists is a problem, then simply make it include them. Easy.
- Iterating on a component from within the app is what causes components to be built in the way described in point #1, tightly coupled to everything else going on. Iterating on them externally allows them to be built with proper interfaces, reasoned about in isolation, and easily tested and examined in different circumstances that may be cumbersome to manually create in the interface (e.g. as you mentioned, 300 item lists).
It's for prototyping. My team actually does something similar to this. We have a live UI toolkit instead of a static style guide, and every prototyping live pages is as simple as putting together our pre-existing components on a demo page.
We use demo-data, but never found the need to make a framework for handling this since its just so easy.
Not to hijack the discussion too much, but does anyone know of something similar for Angular 1.x? Minko Gechev has a prototype of an Angular 2 hot reloader, but that's all I could find.
I would be really interested too. For the moment when i want to develop some isolated component I use codepen but a more dedicated solution would be nice :)
