4 ms·

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 comp

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).
rattray 11y ago
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.
true_religion 11y ago
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.

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

rattray 11y ago

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.

true_religion 11y ago

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.