Introducing React Storybook
voice.kadira.io
voice.kadira.io
[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.
This is a way to list components and show their different use case. We can also develop individual components by just looking at this.
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.
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 itemsI'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
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.
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?
Come on, this is terrible use of bold text. It actually makes reading the post harder.
[1] An example: 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.
I used it for highlighting points. I think I am over using it. Will minimize it.
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.
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. :)
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.
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
-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.
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.
- 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).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.
We use demo-data, but never found the need to make a framework for handling this since its just so easy.