What is Reddit's opinion of Storybook?

From 3.5 billion Reddit comments

>just wanted to know if there were benefits to implementing it in standalone applications as well?

Absolutely - I use it as a stand-alone component development playground for all my presentational components, not just stuff that goes in a component library. Here's why:

Instead of trying to integrate new components directly into my full app as I build them, I can just fire up Storybook, import some mock data, and start hacking away. Since Storybook supports multiple Stories per component, I can easily scaffold out all the different UI states I need in one place, with Viewport I can easily work on responsive stuff without fiddling around inside Chrome devtools, with Actions I can mock out some basic control flow and ensure the right stuff gets called, and with Controls I can fiddle with the mock data live. I can even build mockups of entire compound features by composing stories with other stories, which has been a lifesaver for complex UI changes.

(If you are even more of a Storybook maximalist than I, you can also do automated Jest snapshot testing on your stories with Storyshots and automated visual regression testing on your stories with Chromatic.)

On the flipside, azangru is right too - Storybook can be hella fragile, and unbreaking it when it breaks can sometimes requires a heroic level of Webpack and Babel wrestling and an iron will for slogging through GitHub issues. So be aware of that before going all-in on Storybook.

I use react storybook as a library for my components, https://storybook.js.org

Currently the components are organized alphabetically as I'm not sure how to group them. You can also add style guide elements to your stories, for example check out lonely planet's storybook

https://lonelyplanet.github.io/backpack-ui/?selectedKind=Styles&selectedStory=Design%20tokens&full=0&down=1&left=1&panelRight=0&downPanel=storybooks%2Fstorybook-addon-knobs

Yes! Look at the controlsadd-on. With controls you can play with the input props of a component to see what edge cases it can handle. This way, a designer can check if a component is available that fits the requirements of their new design.

You can even let testers/QA hook into Storybook and write tests for components through stories.

The developers should still make an effort to showcase all possible use cases of a component, so other developers/designers can check what is available. That way it really becomes a communication tool - more than just a simple style guide.

You could look into storybook. It’s a tool for showing live demonstrations of components, allows you to document intended uses and required/optional params, and it’ll show the underlying code for your live examples.

I used it for my last project, a 2 man dev team. storybook

• Isolated component development is an eye-opener for me, don't underestimate it!
  • It forces you to think about the component's API since it is the only component that is rendered and the story is controlling it directly through props (Storybook args). If you integrate your new component into your app directly, you might be tempted to pass a long list of props to it that are not a responsibility of the component.
  • If you use mock data, you can develop independently from the database environment. Front-end devs are not blocked if the DB/server goes down. Mock data can be reused for component testing.
  • You can write multiple stories for each component story, one for every use case/scenario. This allows you to quickly switch between use cases without having to go through the app to recreate and test a scenario. You can even write stories for sub-components (like a modal dialogue within your component and test flow for that modal).
  • There are addons for testing responsiveness (similar to Chrome DevTools). This becomes powerful when combined with other addons, such as your translations. We always have issues with French translations of the app since those sentences tend to be longer than English. With Storybook, it literally takes a few clicks to check if the component works on a small screen with the French language bundle.
• Stories are just components, you can reuse them for testing and compose them like any other component.

The upcoming Component Story Format v3 makes writing stories a breeze. Define the component in the default export and just export an object with args for every story.

I would recommend Storybook if you need to maintain a lot of reusable components (such as, in a component library).

It's really straightforward to mock APIs in Storybook. I wrote the Mock Service Worker addon not too long ago: https://storybook.js.org/blog/testing-composite-components/

There are a bunch of other options for Apollo, urql, Axios, etc. https://storybook.js.org/addons/tag/data-state/

TLDR: Vue 3 support is now in Storybook 6.2 beta!

This is one of the most requested integrations from Vue users and folks in this subreddit.

SBs core features/ecosystem included:

• Zero-config setup
  
• TS support
• Auto-generated controls and docs
• Automated testing
• Hundreds of addons

What is Storybook?
Storybook is a development environment for UI. It helps you build UI components in isolation. That makes it easier to develop and test hard to reach states (e.g., error, loading, etc).

I haven't tried it yet, but have you tried storybook's MSW add-on to mock an API response and use the original screen instead of a dumb screen component?

That is what's being used under the hood. Storybook 6.5 will build on this to add in a test runner and assertions too https://storybook.js.org/blog/interaction-testing-sneak-peek/ So you won't have to import stuff into a test file.

I started a job recently using this approach with a component library using https://storybook.js.org/ it feels really nice, keeps things consistant without being overly rigid with well designed components.

The official Angular tutorial is great: https://storybook.js.org/tutorials/intro-to-storybook/angular/en/get-started/

And the NX team has one that's advanced: https://blog.nrwl.io/build-your-design-system-with-storybook-nx-e3bde4087ad8

Often you want to use the same "template" for each story but with different arguments passed in. This is common pattern with Storybook. You start by defining Template as a function. Template.bind({}) then makes a copy of that function. We copy the Template so that each exported story can set its own properties on it.

It's a standard JavaScript technique.

That said, the Component Story Format 3.0 simplifies this by switching to stories as objects instead of functions. https://storybook.js.org/blog/component-story-format-3-0/#spreadable-story-objects

The thing being discussed: https://storybook.js.org/

I find the video almost unwatchable, demo thing quickly to get my attention don't bore me for a full minute while I wait for you to get to the point.

Since you've already done the work to create a design system, I would encourage the client to allocate engineering resources towards implementing your design system in a generalized way as a component library, even going so far as to create some component documentation like storybook. This way, the redesign of each flow will be quick, painless, and without need for pixel perfect designs. This should make some redesigns so obvious they won't need your intervention. Others might only need wireframes, and only a few should require a full design. It will also enforce good design with code, even after you move on, by making it hard to break rules and easy for lazy engineers to use good design rather than inventing their own "creations".

TLDR: Storybook is expanding framework support to Vue 3

Vue is the second most popular JS framework used by millions of devs. Storybook is a development environment for UI that's framework agnostic. This expands support for another major framework.

Vue support includes:

• Zero-config setup
• TS support
• Auto-generated component controls and docs
• Automated testing
• Hundreds of addons

What is Storybook?
Storybook is a development environment for UI. It helps you build UI components in isolation. That makes it easier to develop and test hard to reach states (e.g., error, loading, etc).

Currently testing library is recommended quite often. I've played around with it a bit, but so far I've mostly used Enzyme.

Also keep in mind that for frontend tdd there is another kind of test that makes a lot of sense. In Storybook it is called a story: A visual way to verify that the component you created, given a certain set of props, looks a certain way.

When you get Storybook up and running, I recommend the storybook-add on-a11y ( https://storybook.js.org/addons/@storybook/addon-a11y ). It uses the Deque axe-core rule set and will do baseline accessibility checking on your components.

Jest is a pretty good starting point for unit tests too. I started really basic, asserting the component rendered, that props were what I expected, and any conditional renders were behaving properly. Then I slowly added axe-core to my testing suite, so I could evaluate components before transpiling.

I’m a big believer in accessibility as a core tenet of a healthy design system. Good components won’t solve every a11y problem, but they can head off a good number.

>all Figma allows is static screens, so if you want users to "free roam" around your UI and being able to click on any interactive element in any order, you'd have to design all screen combinations for them. I hope I'm making sense

That's true. We prioritised building out a design system with Storybook and Vercel thanks to which we our designers could with minimum fuss work with engineers to easily create functioning UI prototypes that we could test with users. We'll be writing about this process as part of our upcoming blogs but it effectively cut our design-dev cycle in half.

TLDR: If you use Vue 3 and you want to use Storybook, now you can.

Vue is the second most popular JS framework used by millions of devs. Storybook is a development environment for UI that's framework agnostic.

Now you can use Storybook's major features in Vue 3:

• Zero-config setup
• TS support
• Auto-generated component controls and docs
• Automated testing
• Hundreds of addons

What is Storybook?
Storybook is a development environment for UI. It helps you build UI components in isolation. That makes it easier to develop and test hard to reach states (e.g., error, loading, etc).

It is absolutely ready.

​

It's fast and fun, you can use RxJs library with it, as it's supported internally. Which means angular like features are present, even integration with Firebase via Rxfire is possible.

​

I would suggest you to take the Micro-frontend approach with it. To appropriately break the UI into smaller pieces. i.e. Use Bit.dev, Storybook.js

​

See: My Post if you need more convincing about Micro-Frontend architecture.

Do you (or your head of design) already have any sort of style guide? It could just be a PDF document, or a powerpoint deck (i.e. not relating to code at all) which describes the fonts/colours/imagery/writing-style your company uses.

I suppose you could take that information and present it on a webpage if that's useful for your company, but I'm not sure how much more useful that would be than just having the original style guide. If you are going to do that, then React may not actually be your best bet, since it would just be a few static pages without any heavy interactivity (I imagine).

>We discussed that it would be nice if there would be code blocks which you can copy the elements, colors, etc.

From what you say here, you may want to look into Storybook: https://storybook.js.org/. If you want to build up a library of reusable React components, then Storybook is a neat way tool for helping write, cataloguing and displaying them. You can even host a storybook instance so other people in your company, like designers, can check it out.

Hope that helps

Do some research on Storybook: https://storybook.js.org/

That's what my company uses, but there are other style guide generators that can be used with React. If you're familiar with the Bootstrap css framework, you can go to the website and it shows an example component with basic instructions on how to implement it.

Storybook (or whatever styleguide builder you use) creates something similar, but custom to your specific needs.

Storybook is a development tool to help you create your components/widgets on a isolated sandbox, and also works as a showcase for then, you can check more about it here: https://storybook.js.org/

Monarch is a tool to help you build widgets in isolation and provides convenient tooling for testing your widgets in all kinds of scenarios: different themes, text scale, device sizes, locales, etc.

If you are familiar with web development, then Monarch is similar to Storybook.

Monarch is not a low code tool. You write stories in code and Monarch renders those stories in the Monarch UI.

Hey Lloyd, maintainer here. The linter does support TS, in fact every test contains examples using Typescript! I think you were asking something else, however? Storybook supports Typescript out of the box since version 6.0, you can read more about it in the announcement made last year.

What I would do is look into using something like https://storybook.js.org/ and keep a personal library of components. When you need something you can easily copy paste the component code and reuse it across projects

You can maybe try Storybook with MDX/MD? Not sure. Check their recent blog post about it I think. They use Netlify CMS in their example but not sure if that’s required OR if that’s okay with you since you said “Netlify Stuff” but idk if that means just their hosting or all things netlify

https://storybook.js.org/blog/storybook-netlify-cms/

You might want to look into Storybook. It's a tool that front-end developers use for developing and demonstrating component libraries. I've used it a lot. You build your components in React or Svelte or whatever, and you can showcase them. Developers then pick components to build the UI.

https://storybook.js.org/

Canvas in Storybook refers to the element where a story is rendered. The canvas element is that particular DOM node.

Yes, that's on the roadmap next. Storybook will ship with a jest compatible test runner. During dev you can run tests in the browser and then again on CI to catch regressions. More context here: https://storybook.js.org/blog/interaction-testing-sneak-peek/

1. Arc42 is a good foundation for your documentation. IMHO a good level of detail is new team member or you in a year should be able to pick it up. I think the examples linked to in Arc42 docs give a good level of detail.
2. I think there are two audiences for this: Users, who will need help documentation how to do things, and devs/UX. I find storybook a good tool for dev/ux colllaboration, and you end up with living documentation here.
3. Confluence is fine. There are things you can do to make finding things in confluence easier. The best thing about using confluence is that non-technical people can contribute.
4. yes, but you will find yourself fighting with the tools, and editing docs embedded in code is nasty.
5. there’s sections in Arc42 for both these.

Great article!

We did follow a similar strategy when we've built an Angular-based UI library. Couple of learnings & additions to your blog post:

• Visual screenshot testing is a life-safer. Let's be honest, Component libraries usually don't have massive functionalities. Surely, it's good to Unit Test the components, but from a visual PoV visual screenshot testing is REALLY valuable.
• Build dark mode from the beginning. We did the mistake of "de-priotizing" dark mode because it's not that important. Which is true, but it is so much effort to implement it after the fact.
• If you don't have it already; think about adopting design tokens. It let's you keep your Component library in sync with multiple platforms as well as with the Design specs.
• Check whether it's a good idea to adopt Angular for your UI library. If you're an Angular company, then sure go for it. In our case, some folks were building React, Vue, Backbone.js or Angular applications. In this case, consider using Stencil (which we ended up migrating to) or Lit-Element or any other Webcomponents based FWK. Especially with Stencil you can nicely target any major FWK without sacrificing user experience.
• Use Shadow DOM and CSS variables. Folks are going to try to re-style or use internal DOM elements to perform magic tricks. Usually, we'd then change our components DOM and that would result in a broken application. Shadow DOM & CSS variables have a much more explicit way of defining your components public API.

Storybook only gets you so far, you need to rely on automation tools. Like proper JS Doc annotations or utilizing something like TypeScript and enforcing proper types.

Storybook can use the JS Doc annotations and types to generate a nice page of documentation for you using addons like this:

https://storybook.js.org/addons/storybook-addon-react-docgen

If you can't use something like TypeScript, you should still be using React props to properly define.

I found this advances tutorial very helpful in setting up a component library that can be shared across all projects in a company (ultimative reusability) and is tested visually + functional AND sets up CI/CD stuff... really nice (basic knowledge of storybook required though)

https://storybook.js.org/tutorials/design-systems-for-developers/

Earlier this year we launched the addon ecosystem 2.0. There are now a bunch of addons that make it easier to work with composed and connected components: https://storybook.js.org/blog/storybook-addons-to-manage-data-state/

For example, mocking API request with MSW addon

I'm pretty sure the:

> We write all of our components in JS

Part was correct. He said they wrote all of their components using Storybook so that they're completely standalone, and then used ~1,500 lines of ClojureScript to glue them together into the application they needed. The business logic is in Clojure, UI specific stuff in JavaScript.

What you are describing sounds a lot like a component library/design system.

Storybook is a really good tool for building design systems. Ideally you'll want to distribute them library through npm. Here's a tutorial for it: https://storybook.js.org/tutorials/design-systems-for-developers/

I haven't found any magic way to sync styles but I did find Storybook Composition if anyone was interested. Here you can publish your storybook and other teams with the proper link can view it locally which perfectly fits our means.

​

https://storybook.js.org/docs/react/workflows/storybook-composition

I would also second checking out Storybook: https://storybook.js.org/ as my go to tool for this kind of task, specially as u/oscar-8880 said: building and displaying a library of reusable frontend components. But in terms of creating the Styleguide itself, this (in my experience) has usually been the task of the designers to actually create. The frontend devs will discuss and participate in the planning meetings with the designers, but the actual task of creating the Styleguide itself is down to Design. This has normally been (Again in my experience) with a tool like Figma or Adobe XD etc. something that the developers can access and then build components from accordingly. But it could also be a generic presentation / text document detailing the specifics

Sorry to hear that.

The team (I'm a maintainer) does our best to bring the community along. For instance in 6.0, there's a lengthy migration guide and re-written docs.

Ultimately, the goal is to improve Storybook every version to save developers work – but I guess that ended up causing you more work.

I'd recommend looking at Storybook. https://storybook.js.org/

It gives you a sandbox/style guide to test components in and I think it is still wired up to Jest for UI snapshot testing which is all you should really need if you're keeping the business logic out of your UI.

Edit: ..erm... yeah... what /u/docaCode said.

I built my first Storybook addon and wrote about the process.

TLDR: Storybook is the most popular tool for UI development. Addons are a massive part of the its ecosystem. They automate your UI development workflow which cuts out a lot of grunt work.

This tutorial shows you how to code an addon using the built in APIs.

I'd probably default to Rollup over Webpack for the actual bundling process for a component library. The config will be simpler, the build will be smaller, and it'll be easier to set up things like tree shaking.

The official Vue plugin for Rollup is a good place to start, specifically: https://rollup-plugin-vue.vuejs.org/examples.html#component-library, which will allow your package to be consumed by the browser/node/webpack/etc.

You'll still want to "run it independently" (you need a development environment for developing components and testing them, after all), and that's where you could do something like add a webpack config and run webpack-dev-server, enable HMR, etc. Or, an even better option is to just use Storybook for your dev environment: https://storybook.js.org/ which uses webpack under the hood anyways.

I'd recommend you to use storybook to develop your components and integrate it with the accessibility addon. This way you always have a quick way to check every component in isolation and you'll have a panel that scans them and tell if they conform both with WCAG2.1 and Section 508(it uses axe internally).

Work on a team with someone more experienced or has a different project than you do. Often times "the tools" that one uses has a drastic effect on how effectively one can program.

Also, try storybook: https://storybook.js.org/

Are you referring to this https://storybook.js.org/docs/react/workflows/package-composition#for-package-authors?

That's meant for published packages. When a user installs a package then its Storybook composes automatically.

It still relies on you publishing your storybook somewhere. There are a few options:

• You can offload that responsibility to chromatic. It manages both the deployment and the versioning for you.
• You can deploy your storybook to any service of your choice (eg: Netlify or S3) and provide that URL for composition.

I would recommend reading about component driven development: https://www.componentdriven.org/ This helps underatand the pros and cons of the approach and do the right decisions for you based on the right reasons.

I would also recommend coupling the project with Storybook to enable the approach in case that is the way you choose to go with. https://storybook.js.org/docs/vue/get-started/introduction

As others have said reality is not black and white. You need to do what works in your case.

My team started with Styleguidist which we used for about a year and then switched everything over to Storybook. Use the Docs addon for the best user experience https://storybook.js.org/docs/react/writing-docs/introduction

this is not a react app. this is a component library using storybook for react. The main component of the library, NLPAnnotator, is meant to be imported into an existing app. I have done very little with storybook, so I'm not the best person to ask questions but I can at least help you get started. after npm install you would do npm run storybook. That will start up the storybook server and should automatically open in your browser. storybook is basically just a playground for testing components in isolation outside of an actual app. you'll probably want to read through the storybook docs, they'll help you a lot more than I can.

https://storybook.js.org/docs/basics/introduction/

Have you considered Storybook? Aside from that, here's a link to an excellent resource shared in this sub the other day.

You cannot confidently rely on DOM elements to ensure a page looks and behaves as expected.

Use automated visual regression tests to validate expectations.

For React, Storybook [1] allows you to visually test each of your React components. That’s a paid for service, but there’s open source alternatives out there.

[1] https://storybook.js.org/docs/testing/automated-visual-testing/

If you want a tool to help not only make documentation but to improve your development flow, Storybook is a good one. It has an addon called docs of which you can use mdx files and add whatever components in there. There are a bunch of other addons to add a bunch more functionality, it's awesome.

Might depend on your tech stack, but I've found Storybook (https://storybook.js.org/) good for project specific components.

bit (https://bit.dev/) might also be a good option if you need to use the components across multiple projects

Generally I only look at my transpiled code when it needs optimization. It is usually considered harder to read than as written. If you are using the transpiled code for documentation, that's different and understandable.

Maybe I should suggest a different solution here if your goal is to see your components in the browser. Check out storybook. It's a development library that lets you design a component explorer. When you run the storybook command, it starts up a tiny web server locally that serves your components to you and lets you test them

It's simply a collection of UI components, built in isolation from the main project or projects. You'd use one to help ensure consistency of your components' design and functionality everywhere they're used. You might use something like https://storybook.js.org/ to view and maintain the components.

https://storybook.js.org?

Hello u/df342fs, it appears you tried to put a link in a title, since most users cant click these I have placed it here for you

^I ^am ^a ^bot ^if ^you ^have ^any ^suggestions ^dm ^me

At work we used a similar setup to this: https://github.com/Microsoft/TypeScript-Babel-Starter#readme

We use the Babel CLI like the template but run it twice to produce a universal library (CommonJS and ESM. Then you can add storybook as a dev dependency and set it up following this: https://storybook.js.org/basics/writing-stories/.

If you need to support script tag in the browser and/or unkpg use microbundle: https://github.com/developit/microbundle/blob/master/README.md

Try this https://storybook.js.org/docs/guides/guide-react-native/#automatic-setup. I successfully set up this on the expo typescript project.

As you can see in examples here, the notes addon is activated by being passed as the third argument to the storiesOf function. How would it even work with CSF?

I like to put all relevant documentation about the code or api contracts in the repo if possible. There are tools like storybook that help with this and gives people in design and product something to see. You can easily standup this as a simple app with GitHub pages. Mostly for component level work (and other free type of work), can help to have a source of styling and using company specific components. You can also set up knobs to let others “change” the component in real time (colors, text, font, etc).

There’s also auto generated tools for code itself like the other people mentioned like jsdoc (and other language equivalents). If you have an internal library that the company uses look into docusaurus. It generates static content to create documentation.

For APIs there’s also swagger.

Either way my rule of thumb is keep code documentation alongside the code. Keep the business documentation on confluence. I have yet to find a company that doesn’t run into the issue of not finding relevant documents after it grows a certain size. You’re not alone with this problem.

The reason why I prefer putting documentation in the repo is that as a SE I’m spending the majority of my time in the repo. I don’t want to leave it to look for documentation elsewhere.

https://storybook.js.org/ https://docusaurus.io/ https://swagger.io/

I looked through a handful of their provided examples and none of them seemed to be what I was looking for. I couldn't change any markup to see how the component reacted. I was looking for something like a code editing box on the left, and a preview of the component on the right.

<mycomponent />

I'd love for the developer to be able to add like an attribute into the <mycomponent> tag like <mycomponent data="['apples', 'oranges', 'plums'] /> and get a live preview of what that attribute would do to the component itself.

For that matter, I also don't see the long-form of this in these examples... It shows all the variations of a component, but I don't see where the developer can just copy the markup for that component to use it.

If I'm missing something, please show me! There are some cool parts of Storybook for sure, but it doesn't look like it has what I'm looking for.

There's a project called Storybook that encourages what it calls "component-driven design". It's goal is to let you create your individual components in abstract, without having to fully scaffold the application or the container components, or connect them to data, or anything like that. You can display and test them in isolation so you can worry about designing and building each component on its own. Then you build the container components, working from the bottom up until you're working on "screens".

I just started using it, so I can't necessarily say how well Storybook works for longer-term projects. But I do like the approach.

If you're running your server with ts-node you can use its transformers option to pass a transformer that will add the variable to your decorators for you. If you use Babel with the typescript preset you could write a plugin or a macro.

Keep in mind that passing module into libs is not uncommon. Storybook for instance requires it when writing stories to enable hot reloading. If you're writing a library that will be consumed by others it would be best to be explicit and require the variable instead of requiring the consumers to change their build system. If it's used only in your projects then you could go the extra mile and automate things at the expense of adding "magic".

Angular Playground and Storybook come to mind.

I‘ve only tried AP but always wanted to try out Storybook. AP could have better docs IMHO.

Not sure about Storybook but AP shines with dumb components. With smart components the setup will be more difficult especially as your application grows, they will break easily if not maintained properly.

Storybook looks intriguing. I'm a lazy designer and use Angular Material for pretty much everything at the moment, does it have mockups for those components? Or is this more towards a from scratch design approach? (I watched the intro Youtube video and it was pure fluff unfortunately)

Decided to try it for the first time and ran into brick wall right away. Seems problematic running create-react-app with typescript even if you follow the instructions @ https://storybook.js.org/docs/configurations/typescript-config/#setting-up-typescript-with-babel-loader

I recommend checking out Storybook. It allows you to come components in different scenarios and props. With it you're able to quickly iterate and get your code right how you want it before adding to your application and dealing with reducers or what have you.

https://storybook.js.org/

I'm working on my first story driven project and I'm really digging it. It's caused me to think differently about both how I work and how I architect my components / application.

edit: https://storybook.js.org