6 ms·

Introducing React Storybook

459 points by dsego 11y ago

programnature 11y ago
This is extremely similar to DevCards for Clojurescript, https://github.com/bhauman/devcards https://github.com/bhauman/devcards, https://www.youtube.com/watch?v=G7Z_g2fnEDg https://www.youtube.com/watch?v=G7Z_g2fnEDg
- iheartmemcache 11y ago
  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 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 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.
  - arunoda 11y ago
    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 11y ago
      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 11y ago
        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.
      - d0m 11y ago
        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 11y ago
        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 11y ago
        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.
      - Wintamute 11y ago
        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.
- glenjamin 11y ago
  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 https://github.com/glenjamin/devboard
- sotojuan 11y ago
  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.
ecthiender 11y ago
Is the site broken? I assume in my browser the CSS is not being served, and hence the site looks completely broken.
- minimaxir 11y ago
  The site is Medium w/ a custom domain, if you have settings blocking Medium.
exizt88 11y ago
http://i.imgur.com/kwaIrAH.png http://i.imgur.com/kwaIrAH.png Come on, this is terrible use of bold text. It actually makes reading the post harder.
- albasha 11y ago
  Agreed but he's using it to emphasize a point not for making skimming easier.
  - deleted 11y ago
    [deleted]
- minimaxir 11y ago
  Frequently bolding key words for quotable/sharable emphasis is one of the more recently-developed growth hacks. (not sarcasm)
  - sotojuan 11y ago
    It always throws me off. As much as I love it, Nicolás Bevacqua's Ponyfoo is a bad example of this. Too much emphasis that it becomes noise.[1] [1] An example: https://ponyfoo.com/articles/github-for-human-beings https://ponyfoo.com/articles/github-for-human-beings Luckily the content is good enough that it doesn't matter. But IMO emphasis should be barely used at all.
- maaaats 11y ago
  Yeah, kinda weird for a text that supposedly talks about making good UI.
- arunoda 11y ago
  Thanks for the feedback. This is the first time, I got a feedback on this. I used it for highlighting points. I think I am over using it. Will minimize it.
  - jmpeax 11y ago
cloakandswagger 11y ago
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.
- iheartmemcache 11y ago
  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 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.
- darawk 11y ago
  - 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).
troncheadle 11y ago
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.
- arunoda 11y ago
  Thanks. I'd like to get you feedback on what we can improve. Could you post your feedback here - https://github.com/kadirahq/react-storybook/issues https://github.com/kadirahq/react-storybook/issues
rvdm 11y ago
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?
- arunoda 11y ago
  Cool. I will create a ROADMAP.md file in the repo soon. Check it tomorrow.
tootie 11y ago
This is basically a framework for making living style guides? That's potentially very useful, but it wasn't a super hard problem to solve before.
- hellofunk 11y ago
  No, these are not just style guides.
e1g 11y ago
Another project in the same spirit is https://github.com/skidding/cosmos https://github.com/skidding/cosmos 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.
dep_b 11y ago
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?)
- stevenhuang 11y ago
  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.
  - hellofunk 11y ago
    Storyboards take a while to set in, but once they do, you'll see why so many people save so much time with them.
    - thewarrior 11y ago
      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.
- modarts 11y ago
instanceofjava 11y ago
nice one
coredog64 11y ago
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.
- xavhan 11y ago
  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 :)

459 points by dsego 11y ago

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

iheartmemcache 11y ago
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 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 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.
- arunoda 11y ago
  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 11y ago
    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 11y ago
      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.
    - d0m 11y ago
      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 11y ago
        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 11y ago
        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.
    - Wintamute 11y ago
      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.
glenjamin 11y ago
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 https://github.com/glenjamin/devboard
sotojuan 11y ago
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.

ecthiender 11y ago

Is the site broken? I assume in my browser the CSS is not being served, and hence the site looks completely broken.

minimaxir 11y ago
The site is Medium w/ a custom domain, if you have settings blocking Medium.

exizt88 11y ago

http://i.imgur.com/kwaIrAH.png http://i.imgur.com/kwaIrAH.png Come on, this is terrible use of bold text. It actually makes reading the post harder.

albasha 11y ago
Agreed but he's using it to emphasize a point not for making skimming easier.
- deleted 11y ago
  [deleted]
minimaxir 11y ago
Frequently bolding key words for quotable/sharable emphasis is one of the more recently-developed growth hacks. (not sarcasm)
- sotojuan 11y ago
  It always throws me off. As much as I love it, Nicolás Bevacqua's Ponyfoo is a bad example of this. Too much emphasis that it becomes noise.[1] [1] An example: https://ponyfoo.com/articles/github-for-human-beings https://ponyfoo.com/articles/github-for-human-beings Luckily the content is good enough that it doesn't matter. But IMO emphasis should be barely used at all.
maaaats 11y ago
Yeah, kinda weird for a text that supposedly talks about making good UI.
arunoda 11y ago
Thanks for the feedback. This is the first time, I got a feedback on this. I used it for highlighting points. I think I am over using it. Will minimize it.
- jmpeax 11y ago

cloakandswagger 11y ago

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.

iheartmemcache 11y ago
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 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.
darawk 11y ago
- 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).

troncheadle 11y ago

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.

arunoda 11y ago
Thanks. I'd like to get you feedback on what we can improve. Could you post your feedback here - https://github.com/kadirahq/react-storybook/issues https://github.com/kadirahq/react-storybook/issues

rvdm 11y ago

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?

arunoda 11y ago
Cool. I will create a ROADMAP.md file in the repo soon. Check it tomorrow.

tootie 11y ago

This is basically a framework for making living style guides? That's potentially very useful, but it wasn't a super hard problem to solve before.

hellofunk 11y ago
No, these are not just style guides.

e1g 11y ago

Another project in the same spirit is https://github.com/skidding/cosmos https://github.com/skidding/cosmos 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.

dep_b 11y ago

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?)

stevenhuang 11y ago
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.
- hellofunk 11y ago
  Storyboards take a while to set in, but once they do, you'll see why so many people save so much time with them.
  - thewarrior 11y ago
    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.
modarts 11y ago

instanceofjava 11y ago

nice one

coredog64 11y ago

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.

xavhan 11y ago
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 :)