908: Storybook Has Evolved w/ Jeppe Reinhold

Wes and Scott talk with Jeppe Reinhold about Storybook 9’s powerful new features—including drastically reduced bloat, seamless Vite integration, and next-level component testing. They dive into visual regression testing, accessibility, performance, and best practices for writing robust, isolated UI components developers can actually enjoy testing and documenting. Show Notes 00:00 Welcome to Syntax! 01:40 What is Storybook? 03:48 How Storybook makes component design easier 04:41 Vite integration and compatibility with other tools Vite webpack RSpack 06:50 Storybook’s significantly smaller bundle size e18e polka 13:31 Upgrading to Storybook 9 17:34 Testing components with Storybook Vitest 19:51 How do you write a component “story”? 24:29 Brought to you by Sentry.io 24:54 How visual testing works 28:38 How Storybook makes money 29:33 Best practices for component design 32:24 Mocking and testing strategies 34:49 Accessibility testing 40:51 Add-ons and future features 44:43 Storybook’s documentation 46:33 Sick Picks + Shameless plugs Sick Picks Jeppe: JBL Boombox 3 Wi-Fi Shameless Plugs Jeppe: chromatic Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we're talking with Yeppe Reinhold about Storybook. Storybook has announced a new version. It's in beta, version number nine. We are using Storybook on the Syntax site, and I thought this would be a great opportunity to catch up and really see what's been going on with Storybook lately. Longtime listeners of the show will know that in one of the very first Syntax episodes back in 2017, we were talking about React Storybook. So Storybook is not new to the game. They've been here a long, long time, and there has been a lot of stuff going on. So, Yeppe, welcome to the show.

• 0:42Speaker 01

  Thank you. I'm super happy to be here. This is gonna be a lot of fun.

• 0:45Wes Bos?

  Awesome. So, give us a rundown of who you are and what you do, and then we'll get into the Storybook stuff.

• 0:52Speaker 01

  Right. So I'm Yeppe. I am a software engineer at the Storybook team in Chromatic. Chromatic is the company that funds the development of Storybook, and it's sort of like something that builds on top of Storybook, essentially.

• 1:08Speaker 01

  And I've been working in the Storybook team for almost three years now. It's a joy working in open source every single day, working with the tool chain that I love, JavaScript. I am also responsible for the Svelte integration of Storybook. That's how I met Scott.

• 1:26Wes Bos?

  Oh, yeah.

• 1:27Speaker 01

  And that's also been a joy to take from a place to another place, I guess we can say that, over a few years. And then I'm also responsible for some of the other stuff, like the docs part.

• 1:39Wes Bos?

  Awesome. And for anyone who hasn't heard of Storybook yet, probably most of our audience has, can you give us a quick rundown of what it is and why you might want to use it?

• 1:50Speaker 01

  Right. So Storybook is, we call it a workshop for your frontend. So essentially, if you're building your website or your UI, you would probably use components, and Storybook allows you to work with these components in isolation. So you don't have to look at them in the app, but like as a pure component. Storybook has three pillars. It's development, documentation and testing. So you can choose to use Storybook however you want, just for developing on your components, or you can use it to document. Maybe you have a design system where you write a lot of docs for every single component. Or also for testing, which I guess we're gonna go more into today.

• 2:32Speaker 01

  Where you write tests for your components, not for your full application.

• 2:36Wes Bos?

  Oh, interesting.

• 2:38Speaker 01

  That's sort of the rundown of our storybook, I guess.

• 2:40Wes Bos?

  Cool. Yeah, so if you have like a podcast component, right? You may, you may develop that component in, like you said, like in isolation, so that the rest of the website doesn't have to necessarily play into it. Because we've all written code before where it looks good and it functions well when it is in the sidebar, but then you move it into the footer or into another part of your application and the styles break, the functionality breaks. And that's not a very good design process. You haven't coded that very well because it is so brittle and it depends on it living in a specific part of your website.

• 3:23Wes Bos?

  So simply just developing them and designing them in isolation allows you to just focus in on that, as well as focusing on like different states as well, right? Like you may have several different instances of that component in several different states and different types of data that needs to be passed in. Or what does it look like when it's open and closed? And components get complicated, man, and Storybook makes that a lot easier.

• 3:49Scott Tolinski?

  Yeah, I found it's been very helpful for us in this process because I personally have used Storybook in the past, but I never like built something in Storybook, really. And so we're building this new site and I'm building it in Storybook first and foremost. And the thing that I've noticed first and foremost that it's helped with is like component design, the inputs and the outputs of specific components. And what a component needs to function independently makes it a little bit more robust than when you're building it so kind of tightly coupled to its parent or children or anything.

• 4:22Speaker 01

  So Storybook really helps you in playing around with your component, very easily change up the props. How does that affect my component? Or getting the component into a specific state? That would be really hard to get into in the application. That's a common problem with developing in the application first.

• 4:40Scott Tolinski?

  Yes.

• 4:40Speaker 01

  Is getting into these states.

• 4:42Scott Tolinski?

  So in the past, I'd used Storybook and it felt like a, and I'm going to say like, five, six years ago. So, you know, before you would have been there, but it felt like a big to do to add it to my application, especially if I was using certain build tools or whatever. It just felt like a lot. And in this recent installation, I was what? Like on version eight when we made the choice to use it. I was impressed to see that it's on Vite now and that it all just kind of like, just works and is all pretty fast. When did that all happen?

• 5:13Speaker 01

  So it started at the end of Storybook six. That's where we did the first Vite integration. It was actually a community contribution to do the Vite Builder integration. And then for Storybook seven, which was around,

• 5:28Speaker 01

  end of 22, I think. That's where it was like an official integration to Vite. Essentially, like to give some context, the problem with Storybook is that you sort of have to set up the same build pipeline as your application does. So if your application uses Webpack or these 10 Vite plugins, you would want the same thing in Storybook so that your components render equally the same, right? And that was historically really hard to set up that duality. But starting with Storybook seven, we made it easier to just integrate into your existing Vite setup. And then gradually, we've made that simpler and simpler. And so now it's very close to just being what your application is, especially if you

• 6:12Speaker 01

  use some of the official application integrations that we have like NextJS and SvelteKit. So if you just plop that in, it should work exactly like your SvelteKit application does.

• 6:22Wes Bos?

  And what about someone who's not on Vite? It still works with Webpack and all the other tools out there?

• 6:28Speaker 01

  It works with Webpack and with Vite. And then the RS Pack team has built their own builder that combines Storybook and RS Pack. And there's also one for, I think it's called Modern Web Dev, where the idea is there's no bundler.

• 6:44Wes Bos?

  Yeah.

• 6:45Speaker 01

  But it's mainly Webpack and Vip that's being used today. And that still works today, mostly at least.

• 6:50Scott Tolinski?

  One thing that I noticed in the announcement of the new version nine, which is not out yet, I think it's in beta, right?

• 6:58Speaker 01

  Hmm.

• 6:59Scott Tolinski?

  Was a big emphasis on the reduction in the bundle size in terms of like, both the size, but also like the dependency tree complexity.

• 7:09Wes Bos?

  Yeah, significantly.

• 7:11Scott Tolinski?

  Significant.

• 7:12Wes Bos?

  And like less nested, right?

• 7:15Speaker 01

  It's been a long time complaint of Storybook users that Storybook is bloated. Like that word bloat has just been over and over again repeated. And so with the with the rise of the E18E community, that's like, how can we make stuff smaller and faster?

• 7:32Scott Tolinski?

  What is that community?

• 7:33Wes Bos?

  The E18E?

• 7:34Speaker 01

  E18E, E18E. I can't even remember what it's.

• 7:37Wes Bos?

  Oh, E18E.

• 7:39Speaker 01

  E18E dev?

• 7:40Wes Bos?

  Ecosystem Performance. Oh, that's a new one I have not seen before. Cause it's like accessibility is A11Y. So ecosystem performance is E18E.

• 7:51Scott Tolinski?

  Cool.

• 7:52Speaker 01

  It's a community of some really smart people that are transforming the JavaScript ecosystem by building smaller packages and replacing packages. And they kickstarted our journey towards reducing this bloat. We had some great contributions and then finally we said, okay, we're going to do this officially. And so we sort of split it into two parts. We we called it actual bloat and perceived bloat. And the actual bloat is what you have reacted to is that the fact that Storybook had a lot of transitive dependencies, like hundreds and hundreds. And it also had a huge install size, like hundreds of megabytes. And so we we replaced a lot of dependencies. So the biggest one was Express.

• 8:38Speaker 01

  That was by far the biggest part of that tree. We replaced that with Polka, which is like way smaller, has two dependencies.

• 8:45Scott Tolinski?

  Yeah, I know Polka.

• 8:47Speaker 01

  And then we we removed some dependencies because like, you know, some of the low dash utilities, you can just do them in plain JavaScript today. You couldn't do that five years ago, but now you can.

• 8:56Wes Bos?

  Okay.

• 8:57Speaker 01

  And then we pre bundle a lot of dependencies also. That's a that's a more advanced topic, but essentially some of the dependencies were huge when you pulled them in. But if we bundled them into Storybook and we only use a tiny part of it, we would like lose. Hundreds of magnitude, of size from that.

• 9:18Wes Bos?

  So I joked about that. I was like, Scott said, yeah, I don't know how they did it. And I was like, they probably just, but they're probably just bundling it before they ship it, you know, instead of, the alternative is like shipping like a package JSON, right? And the NPM tree all the way down. But in your case, you're simply like pre bundling some of them because you only need a little sip of one of these packages here and there.

• 9:42Speaker 01

  Right. Yeah. And so, so it's not, it's not what we do for all of them at all. Like we did remove a lot of them, but some of them needed to be bundled in. And that has its own trade offs, of course, but for us, we thought it was the best trade off. So that was, that was like the actual bloat of the, of the megabytes and the dependency tree, which like is makes it, it makes it faster to download store book also, because you don't have to download a ton of dependencies. And then we tackled the perceived bloat in store book nine, which is when you initialize a new store book project, we would historically, we would add fifteen packages, I think, to a package JSON.

• 10:22Speaker 01

  It was like the main store book and then the, the five add-ons and then the V integration and then the Svelte integration and all that, right? And that was annoying to everyone. So we, we ditched some of the add-ons and said, like, they aren't used anymore. Add-on links is one of the add-ons to store book that nobody uses. Uh, we moved a lot of them into core because we saw that, all right, ninety-five percent of users are using this add-on. We should just put it into the core packet. So you don't have to worry about that. And then I think we cut that in half. So now you only get four packages, I think, in your package. And I can't remember.

• 10:57Wes Bos?

  Yeah.

• 10:58Speaker 01

  So those two things, whether like what we did to reduce the bloat of store book, there's still more to do and we are still collaborating with that ecosystem, performance community. Um, but we are pretty happy with the results at least.

• 11:09Scott Tolinski?

  Yeah, I do have to say, there is something nice about a shorter list in my package.json that just makes me feel a lot easier about picking to use something. I'm curious about, like, from your perspective, has this change made developing Storybook any easier? So it's great that it's all, you know, less bloat, noticeably less bloat, I will say, because I was a complainer that there was too much bloat before. So has this made working on it easier or more difficult?

• 11:39Speaker 01

  It's a lot easier. I think to explain that well, we have to do sort of a history lesson, because Storybook is old in JavaScript history. I think Storybook is seven years old, if not more. And way back when, that was when Babel and Webpack had its peak. And at that point, the paradigm was you build a bunch of small utility packages that you just reference internally. And then Storybook followed that pattern and had like 70 small packages. And then throughout Storybook 8, and then finally in Storybook 9, we consolidated all this into one Storybook package. And that just made everything easier in terms of our own bundling and development and how

• 12:24Speaker 01

  we can reference stuff. Because before, you couldn't just import a function, you had to export it in this package so you could import it in this other package. But we don't need to do that anymore at all. So it's just like way easier for us.

• 12:37Scott Tolinski?

  Was that kind of transition perilous? Because like, I can imagine, again, we talked about Storybook in 2017 on this show, I can imagine there is a lot of debt in that codebase, or possibly, I don't know. But was that transition difficult?

• 12:55Speaker 01

  It requires a lot of effort, for sure. I mean, we spent a lot of time doing that transition, and we're still not done. We have more planned in what I call the modern paradigm, getting into the APIs and the structures that have been defining for Vite and just build and roll up. And we're still doing that transition today, because what we're seeing is that users love it. Users love it when we reinvent ourselves and actually keep up with the ecosystem. It's months and months of work to do that transition.

• 13:27Scott Tolinski?

  Yeah, I believe that. Yeah, I bet that'd be crazy.

• 13:31Wes Bos?

  What about the transition for someone who's been on previous versions of Storybook to this this most recent one? What does that look like?

• 13:40Speaker 01

  It really depends on which previous version, because the the biggest change we ever did was Storybook six to seven. That was a huge change. It was almost a rewrite of a lot of the stuff. And if you're going from Storybook six to seven, you're gonna need to do some manual work. But we also learned at that point that we we need to write a lot of automigrations, we call them. So if you run the Storybook upgrade command, we will analyze your codebase, your dependencies, and then we'll tell you, it looks like you're using X. We're gonna help you migrate to using Y instead, because that's what has changed in Storybook eight or nine. And if you're following the chosen path, or like following the documentation on how to set up a Storybook, that will help you a lot. If you're doing a lot of custom stuff with importing

• 14:25Speaker 01

  configs from five different files and stuff, we can't help you with that. So it depends on how complex your setup is, for sure. One of the funny thing that we're seeing now is that we have created a NextJS integration that's based on VEET, which is weird, because in NextJS, you use Webpack and TurboPack, right?

• 14:43Wes Bos?

  Yeah.

• 14:43Speaker 01

  But there was just a lot of users that wanted a faster NextJS integration, and so, okay, we're gonna do it for VEET. And that also allowed us to integrate with Vtest from component testing while still using NextJS. And and those kinds of transitions should be seamless for users.

• 14:59Wes Bos?

  And how does that work? If NextJS has to use Webpack or TurboPack, how are you using VEET? Is that just to render the individual components out?

• 15:10Speaker 01

  Yeah. So all of the NextJS APIs in Storybook, they're mocked, because you wouldn't want to call, go to this link, and then actually navigate.

• 15:22Wes Bos?

  Like a router method or something?

• 15:24Speaker 01

  Yeah.

• 15:24Wes Bos?

  Okay.

• 15:25Speaker 01

  And so we just have re-implemented all of those mocks in the VEET plugins that we've made. So from a Storybook user's perspective, it should be opaque that they do this change, but we're just using VEET to render all your React components.

• 15:40Wes Bos?

  Oh, that's great. And that's that's significantly faster, or how much faster do you know that was it versus like a Webpack implementation?

• 15:50Speaker 01

  I don't know, because I haven't worked much on the webpack side for years.

• 15:54Wes Bos?

  Yeah, yeah.

• 15:54Speaker 01

  But I would say potentially 10 times faster. Like, V is a lot faster at the initial build.

• 16:00Wes Bos?

  A lot faster, yeah.

• 16:01Speaker 01

  For sure. I don't think it's comparable at all.

• 16:04Wes Bos?

  No, no, that's great.

• 16:06Scott Tolinski?

  Yeah.

• 16:07Wes Bos?

  Have you guys, have you guys ever dipped into using turbopack as well? Or I guess like RS pack, you said there was a already implementation?

• 16:16Speaker 01

  Uh, so the RS pack team, they've done the implementation themselves.

• 16:19Wes Bos?

  Yeah, they've done it, okay.

• 16:20Speaker 01

  And, and we have seen a lot of users migrating from their webpack setup to our pack setups. And it seems to be going good. We don't get a lot of complaints at least. But it's just because the RS pack team is killing it. I mean, they're just amazing. They've spit out packages.

• 16:36Speaker 01

  And the problem with turbopack is that there's no open API.

• 16:39Wes Bos?

  Yeah.

• 16:39Speaker 01

  We, we wouldn't be able to integrate with turbopack even if we wanted to. It only exists inside a next JS application.

• 16:45Wes Bos?

  Oh, yeah. They actually recently moved the entire turbopack repo into the next JS repo as well. So like, I was like, looking at, I was like, will this ever be something other than like a next JS speed up? I mean, I don't think so now that that's, it's that way. It may, it may be, they may have done it for other reasons, you know, like development speed. But I thought it was interesting.

• 17:09Speaker 01

  Yeah, I mean, we can only guess. I have, I have spoken with the turbo team before. And they said that at some point they want an open API. But I mean, it could be years, so we're not, we're not.

• 17:18Wes Bos?

  Not too worried about that right now?

• 17:20Speaker 01

  No.

• 17:21Scott Tolinski?

  Imagine being on a team that you could call the turbo team. That sounds like a cool ass team.

• 17:28Scott Tolinski?

  I'd love that.

• 17:29Speaker 01

  It also puts a pressure on your shoulders. Everything you have to do just has to be super fast.

• 17:33Scott Tolinski?

  Yeah. You mentioned a V test a while back, and I have noticed an emphasis in many regards on whether that is like visual testing or testing in general in Storybook. And one of my beefs with testing in general, especially component based testing, is like, yeah, you test a function, you test the input with the output, you know, pure functions make that easy, whatever. But when you get into components, it always felt like components are so visual. Now I'm writing this code to test my components in a non-visual way. It always felt very odd to me. But I started trying out the V test testing in Storybook. And I gotta say,

• 18:17Scott Tolinski?

  It kind of made me be OK with writing tests because what you guys do is that like, I can press play on it like it's Cypress or something like that. I can see the test happen, or I can see them pass. I can write the test in a standard, you know, testing language with Vtest or anything like that. Is testing going to be just like a major emphasis for you all going forward in general? Because I found the experience to be nice.

• 18:42Speaker 01

  It really is. And that's because what we're seeing, our most successful users, and chromatic customers especially, is that they are just testing a lot. And when they really go into testing of their components, they see huge benefits in terms of their own development speed and just their usage of the storybooks. And so we're like, OK, how can we make other people see the light, like these bigger enterprise teams are seeing? And that's basically the component testing push that we're doing now. On the surface, we haven't actually changed much, because it's still stories. It's just think of your stories as tests, except that the syntax for defining a story is more based around

• 19:27Speaker 01

  the complexities of UI, and not about like doing something in sequence. So usually when you think about a unit test, you go from A to B to C.

• 19:36Wes Bos?

  Yeah.

• 19:37Speaker 01

  But UI is more than that. It's about interacting with it, and it's about having 10 different props to your component. And so that's basically what a story is. But then you can also add interactions on top of it, and assertions. And we're going to do even more of that in the future.

• 19:51Wes Bos?

  Can you explain real quick for anyone listening? Like, we'll stay on the testing stuff, but anyone who's not used Storybook before, if they're trying to visualize this, obviously it's your component rendered out in isolation. But like, how do you write a story? How do you decide what all the different props are to a component, and all the different states?

• 20:12Speaker 01

  So a stories file is what we call it's it has a format that we call Component Story Format, CSF for short. And it all starts with a and a default export of the meta information where you say, this is the component.

• 20:30Wes Bos?

  Yep.

• 20:30Speaker 01

  And these are the default props I would like to pass into the component. In Storybook, we call them arcs, but you could consider them props. And then you could do a lot more meta information. And then after that, you do one export per story. So you would for your for your button component, you would export primary. And then for that story, there would be an object where you put in arcs, primary equals true. Or you can change the label with another type of prop. And then you just define a lot of exports where each story is like a scenario of how this component could be represented.

• 21:10Wes Bos?

  Okay.

• 21:10Speaker 01

  For Svelte, we have a special Svelte syntax called Svelte CSF, Svelte Component Story Format, where you it's slightly different, but it's it's way more intuitive for a Svelte user because you write it in Svelte syntax.

• 21:21Wes Bos?

  Okay.

• 21:22Speaker 01

  But it's still the same idea.

• 21:24Wes Bos?

  Okay, so you're just basically you're you import the component and then you try to think of every possible combination of that component, you know, a red one, a green one, a big one, a small one, et cetera, et cetera. Obviously, much more complex than a button, but a button is a really nice, simple example.

• 21:42Speaker 01

  Hmm.

• 21:42Wes Bos?

  And then how does that play into testing?

• 21:46Speaker 01

  So for each story, what you can do is you can define a play function. And that's essentially a function that runs after your story has rendered. So let's say you have a story for a form. Then that play function can contain interactions and assertions, similar to if you've ever written tests with Testing Library in in Etest or Jest, where you have an element get by role or expect this to be in document, like that's the exact same API we're we're giving you. And so you in this play function, you write in, fill out these four input fields, press submit, and then expect these two errors to show up in the document

• 22:29Speaker 01

  or expect this function to have been called because it actually submitted successfully. And and you can define these play functions for each story. Essentially.

• 22:41Scott Tolinski?

  Yeah.

• 22:41Speaker 01

  And so it's a bit hard to explain the visual stuff, but what you'll see inside the store book is that you'll see everything you did in the play function as a separate step. And you can actually step through it. So you can say, so if there's something unexpected happen, why didn't this error show? You can step to the specific input label, filling out form. And then, oh, it filled out the wrong thing. Or you can step to the next step and then, and then still interact with component and then step further on.

• 23:11Scott Tolinski?

  Yeah, if you've ever used Store or, um, no, sorry. Have you ever used Cypress or something like that? It's not like the same concept because that's running it in a headless bra, do whatever. But like it, because that's usually running your whole site. It does give you that same sort of development workflow to be able to really truly understand, like, why is your test failing? Is it the test or is it the component itself? Again, like for me, I'm a visual guy and we're writing components. They're very visual. I found that to be a nicer experience than having just my test pass or fail in a terminal somewhere. Right?

• 23:50Speaker 01

  Yeah, especially because you mentioned the terminal. And one thing that I find really cool about store book is that you can share your store book. So store book is an application that you can build and publish to Netlify or wherever you want to go. And then you can, you can tick that link and you can say, send to your designer and say, hey, is this test what you would have expected to happen? And then they can see that visually. Whereas with most other tools, you're like sharing a log from GitHub Actions. That's this failed and you have to go through it. Whereas in store book, you actually just share the visual part with the actual DOM, not even a recording, but the DOM.

• 24:29Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 24:54Scott Tolinski?

  And so it also does, in addition to just like component testing, like visual testing, which is something that I've personally poo-pooed on this show 100 times or so. I told Wes during our JS News show that we did. So this is not just because we got the storybook guy on the show, but I told Wes very specifically, this is the first time that I've been like, hmm, it'd be kind of nice to do this. Can you explain how the visual testing part of it works?

• 25:21Speaker 01

  Sure. So visual testing is, it works with Chromatic. And Chromatic is a service that you pay for, but there's a very generous fee here, that you upload your storybook to Chromatic, and then behind the scenes, it takes a bunch of snapshots of each story, and then it sends the results back to your storybook. And then it shows you, this is the diff between you took a snapshot maybe 10 days ago on the main branch, and this is a snapshot you're taking today. The button was clearly resized 10 pixels. And so we're sending it to the service and then getting the results back. That's how it works behind the scenes.

• 25:59Wes Bos?

  It makes sense to put the regression testing at the component level there, because in the past, I've done regression testing, and it's always been page by page. And I've, like, this was probably 10 years ago, or maybe even more. And it got to a point where it was just like, it was too noisy, because there was too many things that could possibly change, that were, some content in the CMS was updated, or simply like you had a tweet in the sidebar, and that was like a different, you know, or the date was different, things like that, where if your components are as pure as possible, meaning that you can control the data that goes into them, and they should render dead nuts the exact same way every single time, then it's

• 26:44Wes Bos?

  much more easy to catch when certain, I call it like website rot, you know, when things start to rot in your application, where that font got changed a little bit, or somebody tweaked the color of that to be a little bit slightly different than the other one. And you might not visually catch those every single time, but... Fifteen, twenty of those little rots over a couple of years, your website starts to feel kinda icky and old.

• 27:14Scott Tolinski?

  Yeah, it can also catch like that, that I don't know if this is a problem that you have Wes, maybe it's.

• 27:18Wes Bos?

  I've got lots of problems, let's see.

• 27:20Scott Tolinski?

  You, you think you got like ten switches and you flip one switch and then this switch accidentally flips over here. So then you flip that one down, another one pops up and you're not, and it's like you change one thing and unexpected side effects happen. Uh, somewhere down the line and then uh, this definitely seems like it would prevent that from happening. And also help you to develop in a way that like, you're not making those kind of choices.

• 27:43Wes Bos?

  Yeah, or, or when it does happen, it's very much like a test where you're like, oh, well, I didn't expect you to do that with the app. Let's go write a, reproduce that, that uh, instance where somebody's name is, is extremely long. And then, then they click on the button, then you go ahead and make that instance in there and then you go ahead and fix, uh, fix it, right?

• 28:07Speaker 01

  Historically, if you've done visual testing with like in an end to end setting, as you say, it can be, it can be flaky. Because like visual testing is the most high fidelity testing you can do. It's on a pixel basis, right?

• 28:19Scott Tolinski?

  Yeah.

• 28:19Speaker 01

  And so when you have a high fidelity test, you have a flaky test. Uh, so that's why we recommend you do it on a component basis where you have full control over what's rendered. And the, one of the biggest flakes we see is when people they use Google fonts and then the font just doesn't load.

• 28:36Scott Tolinski?

  Mm hmm.

• 28:37Speaker 01

  That happens a lot and it just shows up as like these little tiny pixel changes because it wasn't Times New Roman, it was Helvetica or whatever, right? But you can configure your storybook to say, I want, I want to use a local font. I want to use a mock image. I want to do all of this pure so that I can control the test. Uh, that makes it a lot easier, I think, to write the visual tests.

• 28:58Scott Tolinski?

  Yeah, because a flaky test is a test you ignore. That is a guarantee. So I guess that leads definitely into the question of like Storybook's been around clearly for a long time. How does it make money was a big question I had. So it seems like partially it's through visual testing. Are there other ways that like Storybook has monetized itself?

• 29:18Speaker 01

  No, well, we have an open collective where people donate, but it's like 99% is funded by Chromatic. Storybook's a team of, I believe, six engineers and two managers. And we're all hired in Chromatic and work in the Chromatic organization. So there's a lot of discussions around how can you fund open source? And there's a lot of solutions, but in this case Chromatic needs Storybook because you can't really use Chromatic without using Storybook. And so that's like a very symbiotic relationship in that there's incentive to improve Storybook because otherwise you can't earn stuff in Chromatic. So I think that's a great relation.

• 29:59Wes Bos?

  Let's talk about like best practices and whatnot when you're when you're writing stories or building even even just like component design in general. I'm sure that bad component design comes to you as I can't use Storybook in this way. And the answer is often like, well, you shouldn't be doing it in that way. Are there any like bad practices or best practices that pop up when you're when you're trying to design a component? That is well tested and works well?

• 30:31Speaker 01

  I think what we've seen a lot is that when people they have a big application with a lot of components and then they start to add Storybook in it. And as you say, they they'll do, oh, how do I ever write a story for this component? That must be because Storybook sucks, but then well, you need to refactor your component to be testable, similar to how you would do unit tests, right? And one of the biggest things we tell people is do the presentational component versus a smart component split. It's an old way. We haven't discussed this in like five years or something, but it's still a very good way to construct components, which is one component takes a lot of props. And then shows all the styles and then a parent component that. Do all the logic.

• 31:15Speaker 01

  That makes it way easier to play around with the presentational component, just by changing a bunch of props. But then also write the test for the behavior of the parent component.

• 31:25Wes Bos?

  Okay.

• 31:25Speaker 01

  Where you actually do the extraction. I think that's a huge win for testable components. One thing that we're seeing all of the successful teams doing is actually also write stories for the pages, which might not be logical, but in Spellkit, in NextJS, in Remix, your page is actually also a component that just takes in a few cool props that you can do whatever you want. So you can write a story for your page and then navigate through that. But it's still at end to end because you still don't have the database. You don't have the network request to your auth provider and stuff. You're just marking all that out. So it's, it's just the UI still, even though it's a page.

• 32:06Scott Tolinski?

  Does that make it tough to mock like deeply nested components that might be loading their own data?

• 32:11Speaker 01

  Yes, for sure.

• 32:13Scott Tolinski?

  Yeah.

• 32:14Speaker 01

  We have an integration with the mock service worker, MSW, where there's an add-on that allows you to basically mock any network request that you want. And that's pretty powerful in that regard. And that doesn't care if it, if the fetch happens in a very low level component or if it's a high level component, right? But that would definitely be our recommendation. You shouldn't be afraid to mock things. It might feel dirty at first, but sometimes when you reach it, when you're, when your component isn't pure, it's best to put it in an environment that you have full control over. We're also trying to make that easier in the upcoming releases of mocking stuff because it's a huge win.

• 32:49Wes Bos?

  I want to go back to the, the first thing you said, which was like splitting your components up into like, like functionality and presentational. So for anyone listening, what that would mean is like you'd have one component that handles all, it could handle data loading or it could have a bunch of submission logic, loading states, things like that. Maybe an external data store or something like that. And then you have a secondary one, which you simply just pass all of that information in. You might be passing getters and setters, you might be passing booleans. So in, in Storybook, you, obviously the presentational one, you would just.

• 33:29Wes Bos?

  Do one on its own? Well, maybe not always. You would do the presentational one on its own, but what about the one that has all of the logic? Does that also go into Storybook for testing, or is that something that should be tested differently?

• 33:42Speaker 01

  It depends on how much you want to put into it and how much you want to get out of your tests.

• 33:48Wes Bos?

  Yeah.

• 33:48Speaker 01

  I would definitely recommend putting it in Storybook and do the work that allows you to write that great interaction test with the great assertions that ensures that the logic actually works. Because testing that logic separately is pretty hard. I mean, you can do a unit test for the specific function, but you really want to test that the whole component works together.

• 34:09Wes Bos?

  Yeah.

• 34:10Speaker 01

  And so you can put that into Storybook if you want to. And my recommendation would be to put the data loading somewhere else, because it makes the component more testable.

• 34:21Wes Bos?

  Yeah.

• 34:22Speaker 01

  But now, then we get into a discussion of like, oh, I want to do load my data the same place where I have the UI. And that's a bigger discussion, of course.

• 34:30Speaker 01

  Especially if you don't write, if you don't write tests for components today, then some of the things that we're discussing here might seem weird. Why would you split all these things up? Well, to make it testable. And so make sure that it doesn't break tomorrow.

• 34:44Wes Bos?

  Those are people that have not had the pain. It seems like a pain to have to split all this stuff up and to have to jumble, pass everything in as a prop. But, you know, it's certainly a far larger pain to have to try and test that stuff when it's all one big mess.

• 35:02Speaker 01

  My general recommendation is that you can put all of it into Storybook if you want to, and you will get some great results. But sometimes it's easier if you split it up and do it more granularly.

• 35:14Scott Tolinski?

  Yeah. I have noticed that there's an accessibility add-on, and I typically do most of my accessibility testing by hand in Polypane. It's like, let's load it up in Polypane, let's do it once over on the site. I am enticed by the idea that you could be getting some accessibility help while you're actually developing. Can you tell me a little bit about like, what's going on with accessibility and like, what the features do here?

• 35:45Speaker 01

  Sure, so we have an accessibility add-on. And when you add that, what it does is that when the story is done rendering and when the play function is done playing, so you've done all your interactions, then it will use Axe Core, the Axe package, to say, are there any accessibility violations here? You can configure it however you want to, like with different levels and different rules. But essentially, it will show you the violations. You don't have the correct color contrast here, or this heading is the wrong level. And then it'll also highlight it in the UI, so you'll get a little square on top of the element that is violating, which makes it a lot easier to reason about. But of course, it's only on the component level,

• 36:29Speaker 01

  so it doesn't tell you if it works in the actual site with the tab index and the heading level might be off. So it's like an easy win to get a lot of violation reported to you per component, because they're easy to fix on a component level. But you don't get the full test that you would get if you manually did accessibility testing on your site. So we think you should do both, but start with getting like the automated accessibility testing stuff and then do the manual QA afterwards.

• 37:00Scott Tolinski?

  Yeah, it does feel nice like it would have to have at least a little bit of a net there when developing in isolation, rather than building the whole app and just being like, alright, let's now find all the, let's find all and fix all of the accessibility issues from top to bottom and then you're, yeah, you're doing that then.

• 37:22Speaker 01

  And it also plays into the new VTest integration that we have. So if you use the VTest integration and you run your stories in VTest, then you'll also get the accessibility violations shown there, depending on if you enable them or not. And then that really allows you to just block PRs and say, oh, that button is not good anymore.

• 37:42Scott Tolinski?

  Yeah.

• 37:43Speaker 01

  And that's really cool. What we're seeing though, so it's been an early access for some time, what we're seeing users is that when they enable that, they have 500 violations in their storybook, like all over the place, which is fair. I mean, for many, this is a new thing to do accessibility testing. So mostly, they start by... Having accessibility violations as warnings. And then they gradually fix them and then turn them into errors so that they don't regress afterwards again.

• 38:14Wes Bos?

  I like that, being able to do it at a component level as well as like a page level. Because like, like I'm just looking at the React Spectrum storybook, right? And they have, they have a slider, which is simply just a range input where you can slide from one to another, right? But there's, the slider itself, there's probably thirty different permutations of the slider, you know? It's editable with the default value, multiple sliders in it, two handles. Ordered values where the first value can't go behind the second one. There's so many different possible ways. And so there's thirty different possible permutations of the slider.

• 38:57Wes Bos?

  And for every single one, there is twenty-two accessibility tests that you need to make sure. There's no possible way that you could make a webpage with every single permutation of every single input on the page and make sure that you're doing it. But you can with this type of thing, right? You can check that you're passing the accessibility for every possible. What's the, what's a word for that? I keep calling it permutation. What's the word in storybook?

• 39:24Speaker 01

  It's a story.

• 39:26Wes Bos?

  A story, yes, okay. Well, I thought the story was the whole thing.

• 39:30Speaker 01

  No, the whole thing is a component and then each is a story.

• 39:34Wes Bos?

  Each of them is a story, okay.

• 39:36Scott Tolinski?

  That's something I had to get used to when I was developing stories. Because it's like, I would give it a name and then this story is like also the same name. I'm like, well, it's the same story. And the storybook's like, you gotta have a unique name for this. I'm like, all right, what is the name for this story? So like, once I figured out, yeah, story is more micro.

• 39:53Speaker 01

  Hmm.

• 39:54Scott Tolinski?

  Yeah.

• 39:54Wes Bos?

  Okay, the story is the smallest possible implementation of it.

• 40:00Speaker 01

  Right, for now.

• 40:01Scott Tolinski?

  You got a book full of them.

• 40:02Wes Bos?

  For now.

• 40:05Speaker 01

  Now, so we are, we have an RFC open for a test syntax. So in the future, you might be able to, for one story, write multiple tests. So that would be the slider. In this specific configuration, you both want to test that it opens when you click it and that it does something else when you hover. So there would be two tests on that.

• 40:24Scott Tolinski?

  Oh, yeah.

• 40:25Speaker 01

  It's a future thing, but it's been requested a lot. It makes it easier if you're transitioning from a Vtest or Jest mindset, because the syntax is closer to that.

• 40:36Scott Tolinski?

  Yeah, I could see that.

• 40:39Speaker 01

  No, but you're right about the slider. Like, it's 30 different ways that you need to do accessibility testing. You wouldn't be able to do that in your website.

• 40:46Scott Tolinski?

  Plus dark mode, you know? Plus someone has skinned it.

• 40:51Speaker 01

  Wide viewport and narrow viewport and different backgrounds.

• 40:54Scott Tolinski?

  Oh, yeah, yeah, you're right.

• 40:56Speaker 01

  There's also, if you have the accessibility add-on, this is a little-known feature. I don't think many people know this, but in the top, there's toolbar item that allows you to simulate vision disabilities.

• 41:06Scott Tolinski?

  Oh.

• 41:06Speaker 01

  So how does this component look with your green-red colorblind? Or how does this is blurred? I think that's really cool as well and helps a lot of edge cases out.

• 41:17Scott Tolinski?

  What are some of the most interesting add-ons that exist? Because I have not done any add-ons really outside of like the testing. Yeah, what are some of the most interesting ones? I see there is a theme switcher, like switch between light and dark mode. I should probably get that going.

• 41:34Speaker 01

  Or any theme that you can define 10 themes.

• 41:36Scott Tolinski?

  Really?

• 41:37Speaker 01

  You can define a billion themes in the theme switcher.

• 41:39Scott Tolinski?

  I love that.

• 41:40Speaker 01

  You just define what it should do when you change it, and then your component will react to that. There's a new add-on that I'm super excited about by a contributor called Igor. Like, he just came out of nowhere and built this, and it's incredible. It allows you to record your interactions and save them as play functions. So you don't have to write the assertions, you don't have to write interactions. You just press record and you click around. And then you press save, and then it saves the play function to the story file.

• 42:11Scott Tolinski?

  I'm glad that exists. Yeah, that's something that Cypress had that I really liked. I was gonna ask about that, so I'm glad to hear that.

• 42:19Speaker 01

  So for Svelte, it doesn't work with saving to the file, but you can still copy paste it in into the file.

• 42:24Scott Tolinski?

  That's fine.

• 42:24Speaker 01

  There's also a solo states add-on, which allows you to force solo states on your CSS. So you can say, now I want this hover, this button to be hovered.

• 42:36Scott Tolinski?

  Okay.

• 42:37Speaker 01

  And then what does that look like? Which is pretty hard to do because there's no browser API to do that today.

• 42:42Scott Tolinski?

  Yeah.

• 42:42Speaker 01

  But it does magic behind the scenes.

• 42:45Scott Tolinski?

  Oh, I'm gonna use that.

• 42:46Speaker 01

  The viewport stuff is now, it's not an add-on anymore because we moved it into core in Storybook 9, or we are. But it definitely, it allows you to define the iPhone, how does this look on an iPhone? How does this look on the desktop or whatever? And then, of course, write different stories. So you can write a story on the desktop view and the story on the iPhone view. I think that's pretty handy as well.

• 43:08Scott Tolinski?

  What are some areas where Storybook still falls short in your mind?

• 43:13Speaker 01

  One thing that we're already discussing for Storybook 10 is we've talked about this transition from the old parallel to the new, and we're not done yet, and we want to continue with that transition. And one of the things is the add-on API is still very strange. And especially if you've ever written a Vee plugin or something like that, that's very natural. And so we want to change that API to be more natural to write add-ons. You get type safety in define add-on function, and you can import them and stuff. Hopefully, we're going ESM only in Storybook 10. So it should reduce a lot of more load, but also reduce a lot of pain points with people having issues with Storybook CSS. Doesn't import my component correctly and whatever.

• 43:58Speaker 01

  So there's still some pain points there in us having just technical depth, basically.

• 44:03Scott Tolinski?

  Is there anything else that we didn't get to since we're coming up on time here? Anything we didn't cover that you wanted to make sure that people know about Storybook? I personally have been so like blind to the advances in Storybook that when we started using it at first, I was like, I, my past history with Storybook makes me not want to use it. And then I used it and I was like, oh, it's like that meme of the bird eating a cookie.

• 44:25Speaker 01

  Right.

• 44:25Scott Tolinski?

  And being like, oh, hey.

• 44:27Speaker 01

  I think, like, we've talked about testing, right? But I would like to spend just one minute on the VTest integration because I think this is huge.

• 44:33Scott Tolinski?

  Yeah, let's do it.

• 44:34Speaker 01

  There's a VTest add-on that you can add if you're using a Vite setup in Storybook. That allows you to, first of all, allows you to run all your stories as VTest tests. So just similar to regular VTest setup, you do VTest run and then it just tests all your stories.

• 44:51Scott Tolinski?

  Oh, okay.

• 44:52Speaker 01

  Whereas beforehand, you had to visit them manually, which didn't make sense. But it also gives you a little UI in the bottom left corner, like a widget where you can press play. And that goes through all the stories behind the scenes. So you get a little check mark and a little red dot for the stories that pass and fail in the sidebar. And that's pretty cool. We have not talked about documentation at all, but that's, I guess, a whole topic in its own.

• 45:14Scott Tolinski?

  Give us a quick rundown, yeah?

• 45:16Speaker 01

  So basically, you can write documentation for anything, your component or your stories in MDX. And you can, you can, you can define your own React components inside MDX and basically build up a full doc site for your application or your design system. Storybook has this doc GN feature that you use a lot without knowing it, which is basically we look at your component and then we say, oh, because you've typed it with TypeScript, we know exactly what props it takes in. And we know that it, that the label should be a text field and that the background color prop should be a color picker. And that also helps with the documentation part because then some user of your design system can come in

• 46:01Speaker 01

  and just play around with the props. You didn't have, you don't have to manually define. These are all the props that my component takes because we infer that directly from your TypeScript types.

• 46:11Scott Tolinski?

  That makes sense.

• 46:12Speaker 01

  I mean, and then there's like a billion other things. I don't think we need to go into the whole.

• 46:17Scott Tolinski?

  Yeah. Well, I mean, this has been real. You know, it's a, again, it's one of those things that I was such a, not an unexpected pleasure for me to, to get into Storybook again, but like, I was delighted. And when, when we spoke, you were like, give it to me harshly. Like, I saw you being a little critical and I was like, honestly, it's like, I probably would have before I tried it. And then now that I tried it, I'm like, feeling very different about it. So I am glad that we made that choice to develop in isolation in Storybook. And really just thank you so much for coming on and even clearing up a ton of stuff or letting the audience know what's been going on. Now's the part of the show where we get into sick picks and shameless plugs.

• 47:02Scott Tolinski?

  Sick pick is anything that you might be just enjoying right now in life. Could be anything, podcasts, some chocolate, a garden tool, just literally anything. So, and a shameless plug, whatever you want to plug.

• 47:16Speaker 01

  I brought a sick pick with me. It's a huge, transportable speaker.

• 47:21Scott Tolinski?

  Oh, man, this guy parties.

• 47:24Speaker 01

  It's a JBO Boombox 3 Wi-Fi. And the reason I brought this on is because it both has Wi-Fi and Bluetooth, which is fantastic in my world because when we're at home and then the kids will say, can you put on an audiobook? I'll just do the Chromecast thing or the Spotify Cast 2 and that just works with the Wi-Fi part. It doesn't take over my phone. I can still do calls. I can still do whatever, right? But then I live on a pretty big property and we do a lot of work in the woods and stuff. And when we're going to go outside for a full day of work, we just bring the speaker with us and then use the Bluetooth functionality instead. And it's just, it's fantastic. I love that it has both. They also have a smaller version called Charge, I think.

• 48:10Scott Tolinski?

  Yeah, the Wi-Fi connection for sound is way more reliable and less annoying than Bluetooth. I love being able to say in Spotify, just play this on the kitchen speaker.

• 48:17Wes Bos?

  Yeah, Bluetooth's the worst for that type of stuff. Yeah, and like, and like, your, your phone's like, still goes on and on. You can't walk far away.

• 48:27Speaker 01

  Yeah, yeah, yeah.

• 48:28Wes Bos?

  That's really frustrating. Wi-Fi's the best. I, I, at our cottage, I have been working at getting like the outdoor Wi-Fi, just like dialed in for, for that exact reason. It's not that you just necessarily need Wi-Fi outside, but like speakers and cameras and, and things like that. It's, and even like phone calls, the cell service is not great there, but you can do phone calls over Wi-Fi. And I have almost a kilometer, it goes into the lake now, blanketed in Wi-Fi. And it's, it's so nice to be able to like not have to fuss with Bluetooth or like some like direct connection type for that type of thing.

• 49:06Scott Tolinski?

  Right. And what would you like to plug?

• 49:10Speaker 01

  Obviously Chromatic. If you, if you like to use Storybook, if you like component testing, then try Chromatic as the visual testing tool. You can put it in your CI, you can integrate directly into your Storybook and see the diffs there. I really honestly believe that visual testing your components is a huge time saver. So really give it a try if you, if you haven't already.

• 49:37Scott Tolinski?

  Sick. Well, thank you so much. This has been, this has been great. I feel like I learned a ton and I've been already diving into this stuff. So hopefully the audience out there has gained a new appreciation or is learning what's been going on in the Storybook world. So thank you so much for, for coming on.

• 49:53Wes Bos?

  Yeah, thanks a lot. Appreciate your time.

• 49:55Speaker 01

  Thank you for having me. This was a lot of fun and I hope to be here again one day.

• 50:00Scott Tolinski?

  Yeah, totally. Cool. Well, we will catch you later.

• 50:03Speaker 01

  Peace.