Storybook Has Evolved w/ Jeppe Reinhold

Welcome to Syntax. Today, we're talking with Jeppe Reinhold about Storybook.

Storybook has, announced a a new version that's in beta Vercel 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, Jeppe, welcome to the show. Thank you. I'm super happy to be here. This is, gonna be a lot of fun. Awesome.

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

stuff. Right. So I'm Jeppe. I'm a software engineer at the storybook team in, Chromatic.

Chromatic is the company that funds the development of Storebook.

And, it's sort of like something that builds on top of Storebook, essentially.

Mhmm. And I've been working in the Storebook 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.

Oh, yeah.

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 and whatever. 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 of what it is and why you might wanna use it?

Right. So Storybook is we call it a a workshop for your front end. Wes, 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.

Mhmm. Storebook has three pillars. It's development, documentation, and testing.

So you can choose to use Storebook however you want just for developing on your components, or you can use it to document. Maybe you just 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, where you write tests for components, not for your full application.

Oh, interesting.

That's sort of the rundown of our store book is. Cool. Yeah. So you if you have, like,

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 ESLint 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 know, that's not you haven't coded that very well because it it it is so brittle, and it depends on it living in a specific part of your website.

So simply just developing them and designing them in in isolation allows you to just focus in on that as well as 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 and story makes Storybook makes that a lot easier.

Yeah. I found it's been very helpful for us in in this process because I 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 Node, 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. So Starboard 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 Scott? That would be really hard to get into in the application.

That's that's a common problem with developing in the application first. Wes. It's getting into these states.

So in the past, I had used Storybook, and it felt like a and I'm gonna 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 Wes, what, like, on version eight when we made the choice to 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 JS all pretty fast. When did that all happen?

So it started at the end of of Storebook six. That's where we did the first, Vite integration. It's it was actually a community contribution to do the Vite builder integration.

And then for Storebook seven, which was around end of twenty two, I think, that's where it was like an official integration to Vite. Essentially, like, to give some context, the problem with Storebook 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 v plug ins, you would want the same thing in Storybook so that your components render equally the same. Right? And and that was historically really hard to set up, that duality.

But starting with Storebook seven, we made it easier to just integrate into your existing beat 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 use some of the, official application integrations that we have, like Next. Js and SvelteKit. So if you just plop that in, it should work exactly like your SvelteKit application does.

And what about someone who's not on Vite? It still works with Webpack and all the other tools out there? It works with Webpack and with Vite. And then the RS Pack team has built their own builder that's combined Storebook and RS Pack. And there's also one for I think it's called modern web dev where there JS the idea is there's no bundler. Yeah. But it's mainly Webpack and Deno that's being used today, and that still works today, mostly, at least.

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

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

tree complexity. Yeah. Significantly Significant.

And, like, less nested. Right? 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 e 18 e community, that's like, how can we make stuff smaller and faster? What is that community? The e a t e. E 18 e? E 18 e. I can't even remember what it says. E 18 e.

E 18 e dev? Ecosystem

performance.

Oh, that's a new one I have not seen before. Because it's like accessibility is a 11 Wes. So e system performance is e 18 e.

Cool. It's a community of some really smart people that are transforming the, JavaScript ecosystem by building smaller packages and replacing packages. And they kick started our journey towards reducing this bloat.

We had some great contributions, and then finally, we said, okay. We're gonna 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 JS the the fact that Storebook had a lot of transitive dependencies Mhmm. 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.

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

Yeah. I know poker. And then we we removed some dependencies because, like, you know, some of the Lodash utilities, you can just do them in plain JavaScript today. You couldn't do that five years ago, but now you can. Oh, okay. And then we pre bundle a lot of dependencies also. That's a that's a more advanced TypeScript, essentially, some of the dependencies, were huge when you pulled them in. But if we bundle them into Storybook and we only use a tiny part of it, we would, like, lose hundreds, of of magnitude,

of of size from that. So I 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 bun they're probably just bundling it before they ship it, before they ship it, you know, instead of the alternative is, like, shipping, like, a package JSON, right, and that 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. Right. Wow. Yeah. And so so it's not it's not what we do for all of them at all. Like, we we Yeah. 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 the best trade off. So that was that was, like, the actual bloat of the of the the megabytes and the the dependency tree, which, like, it makes it it makes it faster to download Storybook also because you don't have to download a ton of dependencies.

And then we tackled the perceived bloat in Storebook nine, which is Wes you initialize a new Storebook project, we would historically, we would add 15 packages, I think, to pnpm It was like the main store group and then the the five add ons and then the the 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 Storybook that nobody uses.

We moved a lot of them into core because we saw that, alright, 95% of users are using this add on. We should just put it into the core package so you don't have to work with that. And then I think we've cut that in half, so now you only get four pages, I think, in your packages. I can't remember. Yeah. So those two things, whether, like, what we did to reduce the blow to Scott book, there's still more to do, and we are still collaborating with that ecosystem performance Sanity.

But we are pretty happy with the results, at least.

Yeah. Yeah. I I do have to say, there is something nice about a shorter list in my package dot JSON that just makes me feel a lot easier about picking to use something. I 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 blood noticeably less blood, I will say, because I was a a complainer that there was too much bloat before. So, has this made working on it easier or more difficult?

It's a lot easier. I think to explain that well, we have to do sort of a history lesson because storybook is is old in Japanese 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 and then storebook followed that pattern and had, like, 70 small packages. And then throughout store book eight and then finally in store book nine, we consolidated all this into one store book package.

And that just made everything easier in terms of our own bundling and development and how 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 at all at all.

So it's just, like, way easier for us.

Was that kind of transition, like, perilous? Because, like, I can imagine again, we we talked about storybook in 2017 on this show. I can imagine there JS a lot of debt in that code Bos or possibly. I don't you know, I don't know. I don't know. Wes that transition difficult?

It requires a lot of effort, for sure. I mean, we pnpm a lot of time doing that transition, and we're still not done. We have more planned, in what I call the the modern paradigm, getting into the the the APIs and the the structures that have been defining for Vite and you spilled 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 month and month before to do that transition.

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

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

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 Storebook 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 auto migrations, we call them. So if you run the Storebook upgrade command, we will analyze your code base, 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 store book eight or nine. And if if you're following the chosen path or, like, following the documentation on how to set up a store book, that will help you a lot.

If you're doing a lot of custom stuff with importing configs from five different files and stuff, we 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 Next. Js integration that's based on Veets, which is weird because in Next. Js, you use Webpack and TurboPack. Right? Yeah. But just there was just a lot of users that wanted a faster Next. Js integration. And so, okay, we're gonna do it for Veet. And that also allowed us to integrate with Wes, from component testing, while still using Next. Js.

And and those kinds of transitions should be seamless for users. And how does that work? If Next. Js has to use Webpack or TurboPack, how are you using Vite? Is that just to render the individual components out? Yeah.

Yeah. So all of the Next. Js APIs in store, they're mocked because, like, you wouldn't want to call, go to this link and then actually router method or something. Yeah. Exactly.

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

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

I don't know because I haven't worked much on the Webpack side for years. Yeah. But Yeah. We're I would Sanity, potentially, 10 times faster. Like, Vite is a lot faster at the initial build. Faster. Yeah.

For sure.

I don't think it's comparable at all. No. No. That's great. Yeah. Have you guys have you guys ever dipped into using TurboPack as well or, I guess, like, RS pack? You said there was already an implementation?

So the RS pack team, they've done the implementation themselves. They've done it. Okay. And and we have seen a lot of users migrating from their Webpack setup to RS 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 Pnpm team is killing it. I mean, they're just Yeah. Amazing.

They've spit out packages.

And the problem with TurboPack is that there's no open API. There's Yeah. We we wouldn't be able to integrate with TurboPack even if we wanted to. It only exists inside a Next. Js application. Oh, yeah. They actually recently moved the entire TurboPACK repo

into the Next. Js repo as well. So, like, I I was, like, looking at it. I was like, will this ever be something other than, like, a Next. Js speed up? I'm not I don't think so Node 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.

Yeah. I mean, we can only guess. I I have I have spoken with the Turbo team before, and Yeah. They said that at some point, they want an open API. But I mean, it could be Yarn. So we're not

we're not thinking about it. Worried about that right now? No. Imagine being on a team that you could call the Turbo team. That sounds like That's true. Last team.

I love that.

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

You mentioned Wes 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 Node, 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 nonvisual way. It always felt very odd to me. But I started trying out the Wes testing in Storybook, and I gotta say, it kinda made me be okay 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 I can write the test in a standard, you know, testing language with with Wes or anything like that. Is testing going to be just like a a major emphasis for you all going forward in general? Because I found the experience to be nice. It really is. And that's because what we're seeing our most successful users and and Chromatic customers, especially,

is that they are just testing a lot. And and when they really go into testing of their components, they see huge huge benefits in terms of their own development speed and and just their usage of of the storybooks.

And so we're like, okay. How can we make other people see the light like these bigger enterprise teams are seeing? And that's that's basically the component testing push that we're doing now. On the surface, we haven't 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 on around the complexities of the UI and not about, like, doing something in sequence.

So usually Wes you think about a unit test, you'd go from a to b to c. Yeah. But UI is more than that. It's about interacting with it, and it's about having 10 different prompts to your component. And so that's basically what story JS, but then you can also add interactions on top of it and assertions. And we're gonna do even more of that in the future.

Can you explain real quick for anyone listening? Like, we'll we'll stay on the the testing stuff, but anyone who's not used Storybook before, if they're trying to visualize 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, all the different states?

So a story's file is what we call it's it has a format that we call component story format Mhmm. CSF for short. And it all starts with a an and a default export, of the meta information Wes you say, this is the component Yep. And these are the default props I would like to pass into the component.

In store book, we call them arcs, but you could consider them props. And then you could do a lot of 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 Wes each story is like a scenario of how this component could be represented. Okay. For Svelte, we have a Vercel Svelte syntax called Svelte CSF, Svelte component story format, where you it's slightly different, but it's it's way more intuitive for Svelte user because you write it in Svelte syntax. But Okay. But it's still the same idea.

Okay. So you're just basically, you're 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, etcetera, etcetera. Obviously, much more complex ESLint than a button, but a button is a really nice simple example.

And then how does that play into testing?

So for each story, what you can do is you can define a play function.

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 Wes, where you have, 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 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.

Yeah.

And so it's a bit hard to explain the the visual stuff, but what what you'll see inside the storybook 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 happened, 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. Yeah. If you've ever used store or, pnpm store. If you ever used,

Cypress or something like that, it's not like the same concept because that's running it in a headless prod 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 Wes, 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 nice ex nicer experience than having just my test pass or fail in a terminal somewhere. Right?

Yeah. Especially because, you mentioned the terminal. And one thing that I find really cool about Storebook is that you can share your Storebook. So Storebook is an application that you can build and publish to Netlify or wherever you wanna go.

And then you can you can take that Tolinski, and you can say send to your designer and say, hey. Is this Wes what you would expect it 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 Storybook, Wes actually just share the visual part with with the actual DOM, not even a a recording, of the DOM.

And if you want to see all of the errors in your application, you'll want to check out Sentry at century.i0/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 to reduce Sanity .i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

And 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 a hundred 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, it'd be kinda nice to do this. Can you explain how the visual testing part of it works?

Sure. So visual testing is is, it works with Chromatic. And Chromatic is is a service, that you you pay for, but there's a a very generous feature, that that you upload your storybook to Chromatic. And then behind the scenes, it takes bunch of snapshots of each story, and then it sends the results back to a storybook. And then it shows you this is the diff between, you took a snapshot maybe ten days ago on the main branch, and this is a snapshot you're taking today.

The button was clearly resized 10 pixels.

Mhmm. And so we're sending it to to the servers and then getting the results back. That's how it works behind the scenes. It makes sense to put the regression testing at the the component level there. Because in the past, I've I've done regression testing, and it's always been page by page. Yes. And and I've like, this was probably ten years ago or or maybe even more. And it it got to a point where it was just, like, it was too noisy because there Wes 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. Yeah. Things like that, where if your components are as 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 much more easy to to catch when certain I call it, like, website rot. You Node? Wes things start to rot in your application where, that 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 Yarn, your website starts to feel kinda icky and old.

Yeah. It can also catch like that that I don't know if this is a problem that you have Wes. Maybe it's maybe it's problems. Let's see. You you you think you got, like, 10 switches, and you flip one switch, and then this switch accidentally flips over Vercel. So then you flip that one Node, another one pops up, and you took Scott you know, it's like you change one thing and unexpected side effects happen, somewhere down the line. And then, this definitely seems like it would prevent that from happening and and also help you develop in a way that, like, you're not making those kind of choices or wouldn't warp those weird side effects. 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, instance where somebody's name is is extremely long, and then then they can click on the button. Then you go ahead and make that instance in there, and then you go ahead and fix, fix it. Right?

Historically, if you've done visual testing with like, in an end to end setting, I should say it can be a it can be flaky because, like, visual testing is the most high fidelity testing you can do. It's on a pixel basis. Right? Yeah. And so when you have a high fidelity test, you have a flaky test.

So that's why we recommend you do it on a component basis Wes 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. Mhmm. That happens a lot. And it just shows up as, like, these little tiny pixel changes because it wasn't time to enrollment. It was Helvetica or whatever. Right? But you can configure your storybook to say, I want I wanna use a local font. I wanna use a mock image.

I want to do all of this pure so that I can control the test.

That makes it a lot easier, I think, to write the visual tests. Yeah. Because a flaky test is a test you ignore. That JS,

that's a guarantee. So I 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?

No. Well, we we have, an open collective where people donate, but it's, like, 99% is funded by Chromatic.

Storebook'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 in Chromatic.

So I think that's a great relation.

Let's talk about, like, best when you're writing stories or 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 and the answer is often like, well, you you shouldn't be doing it in that way. Are 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?

I think what we've seen a lot is that when people, they have a big application with all of the components, and then they start to add storybook in it. And JS 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 Wes. 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. I we haven't discussed this in, like, five years or something. Yeah. 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 the styles and then a parent component that do all the logic. 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 the parent component Okay. Where you actually do the interaction.

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 SvelteKit, you have Next. ESLint 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 a story for your page and then navigate through that, but it's still not end to end because you still don't have the database. You don't have the the network Wes ESLint your auth provider and stuff. You're just mocking all that out. So it's it's just the UI still even though it's a page. Does that make it tough to mock, like, deeply nested components that might be loading their own data? Yes.

For sure. Yeah. We have an integration with the mock service worker, MSW, Wes 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 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. Yeah. But sometimes Wes you reach it when your 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 of mocking stuff because it's a huge win. I wanna go back to the the first thing you said, which was, like, splitting your Node 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 Node, 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 do one on its own. Well, maybe not obvious. You would you would do the presentational one on its own. And but what about the the one that has all of the logic? Does that also go into to Storybook for testing, or is that something that should be tested differently?

It depends on on your how much you want to put into it and how much you want to get out of your tests. Yeah. I would definitely recommend putting it in Storybook and do the work that allows you to write that 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 wanna test that the whole component works together. Yeah. 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. But now Yep. Then we get into a discussion of, like, oh, I wanna do load my data at the same place where I have the UI. I mean, that's a bigger discussion, of course.

Especially if you don't write if you don't write tests for a component 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 to make sure that it doesn't break tomorrow.

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 it's certainly a a far larger pain to have to try and and and test that stuff when it's all one big mess.

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

Yeah. I I have noticed that there's an accessibility add on, and I 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?

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 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'll 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 we'll get a you'll get a little, square on top of the the element that JS, violating, which makes it a lot easier to to reason about. But, of course, it's only on the component Vercel, 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 it's like an easy win to get a lot of violation, reported to you per component because it they're easy to fix on the component level, but you don't get the full 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.

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 Right. Building the whole app and just being like, alright. Let's let's now find all the let's let's find all and fix all of the accessibility issues from top to bottom, and, then you're,

yeah, you're you're doing that then. And and it also plays into the new Vitez ESLint integration that we have. So so if you use the Vitez integration and you run your stories in Vitez, 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.

Yeah. And that's that's really cool.

What we're seeing though so so it's 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 store book, like, all over the place, which is fair. I mean, it's 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.

I like that being able to do it at a component level as well as, like, a a page level because, like like, I'll 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 30 different permutations of the slider. You know? It's editable with the default value, multiple sliders in it, two handles, ordered values Wes the first value Sanity go behind the second one. There's so many different possible ways. And so there's 30 different possible permutations of the slider. And for every single one, there is 22 accessibility tests that you need to make sure. There's no possible way that you could make a web page 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 the word for that? I I keep calling it permutation. What's the word in Storybook?

What what it's a story.

A story. Yes. Okay. Well, I I thought the story was the whole thing.

No. The whole thing is a component, and then the whole

thing is a story. Each of them is a story. Okay. That's something I had to get used to when I was developing stories because it's like, I would give it a Node, 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, oh, wait. What is the name for this story? So, like, once I figured out, yeah, story is more micro.

Mhmm. Yeah. That that's the story JS there. The smallest possible implementation of it. Right. For now. Book full of them. For now. Be honest. Oh, what is this there?

Node. 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 open in your hopper. So that would be two tests on that store. Oh, yeah. It's a future thing, but it it's been requested a lot. It makes it easier if you're transitioning from, from a b test or just mindset because the syntax is closer to that. Yeah. We'll see I could see that. The lens.

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

You know? Plus,

someone has skied in this way.

A narrow viewport and different backgrounds. Yeah. Yeah. You're right. There's also if you have the xsvs add on there this is a little known feature. I don't I don't think many people know this, but in the top, there's toolbar item that allows you to simulate vision disabilities.

Oh. So how does this component look, with your green, red colorblind? Or how does this come it's blurred? I think that's really cool as well and helps a lot of of, edge cases out. What are some of the most interesting add ons that exist? Because I have not done any add ons

really outside of, like, the the testing.

Yeah. What are 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.

Or any any theme that you you can define 10 themes. You can define a billion themes in each theme switcher.

I make themes. You you just 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 JS play functions. So you don't have to write the assertions. You don't have to write the interactions. You just press record, and you click around, and then you press save, and then it saves the the play function to the to the story file. And that just makes sense.

Yeah. That's something that,

Cypress had that I really liked. I was gonna ask about that. So I'm I'm glad to hear that. So for Svelte, it doesn't it doesn't work with saving to the file, but you can still copy paste it in, into the file. That's fine. There's also a pseudo states add on, which allows you to force pseudo states on your CSS. So you can say, now I want this hover this button to be hovered.

Oh, okay. What does that look like? Which is pretty hard to do because there's no browser API to do that today. Yeah.

But it doesn't match behind the scenes.

Oh, I've used that. The viewport stuff JS now it's not an add on anymore because we moved it into Node and store Vercel nine, OER.

But it definitely it allows you to define, the iPhone. How does this look on an iPhone? How does this look on a desktop or whatever? And then, of course, write different stories so you can write a story on a desktop view and the story in the iPhone view. I think that's pretty handy as well. What are some,

areas where Storybook still falls short in your mind?

One thing that we're already discussing for storybook 10 is we we've talked about this transition from the old parent to the new, and we're not done yet, and we wanna 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 Vercel plug in 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 Node, define add on function, and you can import them and stuff. Hopefully, we're going ESM only in store with 10.

So it should reduce a lot of more bloat, but also reduce a lot of of of pain points with people having issues with Storebook. CSS doesn't import my component correctly and whatever. So there's still some pain points there in in us having just technical depth, basically.

Is there anything else that we did we didn't get to since we're coming up on on time here? Anything we didn't cover that you wanted to make sure that, people know about Storybook? I 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 Right. And being like, oh, hey. I think I like, we've talked a lot about testing. Right? But I would like to spend just one minute on the v Wes integration because I think that's huge. Yeah. Let's do it. There's a v test add on that you can add,

if you're using a v test setup in Storybook that allows you to, first of all, allows you to run all your stories as v test test. So just similar to regular v test setup, you do v test run, and then it just Wes all your stories in the ceiling. Okay. Whereas beforehand, you had to reset 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. Give Give us give us a quick rundown. Yeah.

So, basically, you have you can write documentation for anything, your component or your stories in in, MDX.

And you can you can you can define your own React components inside MDX, and and basically build up a full doc site for your application or design system.

Storebook has this, doc gen feature that you use a lot without knowing it, which is basically Wes look at your component and then we say, oh, because you've typed it with TypeScript, we know exactly what, props it takes ESLint. 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 and just play around with the props. You didn't have you don't have to manually define these all the props that my component takes because we infer that directly from your, TypeScript TypeScript makes sense. I mean and then there's, like, a billion other things, but I don't think we need to go into the the whole thing.

Yeah. Wow.

Man, this has been real. You know, it's, again, it's it's one of those things that I was such a not an unexpected pleasure for me to to get into to storybook again, but, like, I was delighted.

And, when when we spoke, you were like, give it to me harshly.

Like, because 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 I mean, I am glad that we made that choice to develop an isolation, in 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 is the part of the show where we get into sick picks.

And, shameless plug, sick pick is anything that you might be just enjoying right now in life. Could be anything, podcasts, some chocolate, garden tool, just literally anything. So and a shameless plug, whatever you wanna plug. I brought a sick pick with me. It's,

oh, it's a huge, transportable speaker.

Oh, I'm gonna start parties.

It's a JBL Boombox three 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 Scott too, and that just works with this Wi Fi part.

I it doesn't take over my phone. I can still do calls. I can still do whatever. Right? But then I I live on a pretty big property, and we do a lot of work in the woods and stuff. And Wes we're gonna go 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. Yeah. The Wi Fi connection for sound is way more reliable and less annoying than than Bluetooth. I love being able to say and then Spotify just play the Yeah. Bluetooth

speaker. For that type of stuff. Yeah. And, like, it and, like, your your phone's, like, still goes on to that. You can't walk far away. Yeah. Yeah. Yeah. That's really frustrating. Wi Fi JS 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. Right.

And what would you like to plug?

Obviously, Chromatic.

If you if you like to use Storybook, if you like component testing, then try Chromatic as a 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 new components is a huge time saver.

So really give it a try if you, if you haven't already.

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 what's been going on in the storybook world. So thank you so much for for coming on. It's been great. Your time.

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

Cool. Well, we will catch you later.