Welcome to Syntax. Today we're talking with Jeppe Reinhold about... storybook storybook has announced a a new version that'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 jeppe welcome to the show thank you i'm super happy to be here this is going to be a lot of fun awesome so Give us a rundown of who you are and what you do, and then 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 Storybook. And it's sort of like something that builds on top of Storybook, essentially. And I've been working in the Storybook team for almost three years now. 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. 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? Right, so Storybook is, we call it a workshop for your front end. So essentially, if you're building your...
or a website or a 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 as a pure component. 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 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 going to go more into today, where you write tests for your components, not for your full application. Oh, interesting. That's sort of the rundown of our story, I guess. Cool. Yeah, so if you have like a podcast component, right? 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... a good design process you know that's not you haven't coded that very well because 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 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 story makes storybook makes that a lot easier
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 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. 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. It's getting into these states. So in the past, I had used Storybook, and it felt like a... 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 then this recent installation, I was what like on version
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? So it started... at the end of of storebook six that's where we did the first uh beat integration it was actually a community a contribution to do the wheat builder integration and then for storebook seven which was around
end of 22, I think. That's where it was like an official integration to VEED. Essentially, 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 lead 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 7, 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 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 Veet? It still works with Webpack and all the other tools out there? It works with Webpack and with Veet, and then the RSPack team has built their own. builder that combines storebook and RSPack. And there's also one for, I think it's called Modern Web Dev, where the idea is there's no bundler. Yeah. But it's mainly Webpack and Veep that's being used today. And that still works today.
Mostly at least. One thing that I noticed in the announcement of the new version 9, which is not out yet, I think it's in beta, right? Mm. 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. Yeah, significantly smaller and like less nested, right?
It's been a long-time complaint of Storybook users that Storybook is bloated. That word bloat has just been over and over again repeated. And so with the rise of the E18E community, that's like... how can we make stuff smaller and faster? What is that community? The E-A-T-E? E-A-T-E? E-A-T-E. I can't even remember what it is. E-A-T-E. E-A-T-E. Okay. Ecosystem Performance.
oh that's a new one i've not seen before because it's like accessibility is a11y so yeah system performance is e18e 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 going to do this officially. And so we sort of split it into two parts.
We called it actual bloat and perceived bloat. And the actual bloat is what you have reacted to, is 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 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 polka which is like way smaller has two dependencies yeah i know polka and then we we removed some dependencies because
like you know uh 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 okay 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 uh were huge when you pulled them in but if we bundled them into storybook and we only used a tiny part of it we would like lose hundreds of of magnitude of size from that
I joked about that. I was like, Scott said, yeah, I don't know how they did it. And I was like, they're probably just bundling it before they ship it, you know, instead of the alternative is like shipping like a package JSON, right? 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. Yeah. And so it's not what we do for all of them at all. 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 the actual bloat of the megabytes and the dependency tree, which 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 Storybook 9, which is when you initialize a new Storybook project, we would historically, we would add 15 packages, I think, to a package station. It was like the main storybook and then 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 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, all right, 95% of users are using this add-on. We should just put it into the core package 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. Yeah. So those two things were like what we did to reduce the bloat of storybook. There's still more to do, and we are still collaborating with that.
ecosystem performance community. But we're pretty happy with results, at least. 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 blood 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 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.
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 Storbrug.
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 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 uh so it's just
like way easier for us was that kind of transition like perilous uh because like i can imagine again we we talked about storybook in 2017 on this show I can imagine there was a lot of debt in that code base, or possibly, I don't know. Was that transition difficult? 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 VEAT 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.
Yeah, I believe that. Yeah, I bet that'd be crazy. What about the transition for someone who's been on previous versions of the storybook to this most recent one? What does that look like? It really depends on which previous version, because the biggest change we ever did was Storybook 6 to 7. That was a huge change. It was almost a rewrite of...
a lot of the stuff. And if you're going from Storybook 6 to 7, you're going to need to do some manual work. But we also learned at that point that we need to write a lot of auto migrations, we call them. So if you run the Storybook upgrade command. We will analyze your code base, your dependencies, and we will tell you it looks like you're using X.
We're going to help you migrate to using Y instead, because that's what has changed in Storybook 8 or 9. And if you're following the chosen path or 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 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 things that we're seeing now is that we have created a...
Next.js integration that's based on leads, which is weird because in Next.js you use Webpack and Turbo Pack, right? Yeah. But there was just a lot of users that wanted. a faster next.js integration and so okay we're going to do it for read and that also allowed us to integrate with vtest from component testing while still using next.js and those kind of transitions should be seamless for users.
And how does that work? If Next.js has to use Webpack or Turbo Pack, how are you using Vite? Is that just to render the individual components out? Yeah. So all of the Next.js APIs in Storybook. they're mocked because like you wouldn't want to call go to this link and then actually... Like a router method or something. Yeah, exactly. Okay. And so we just have re-implemented all of those mocks in the Vite.
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 V to render all your React components. Oh, that's great.
That's significantly faster 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. But I would say... potentially 10 times faster like vid is a lot faster at the initial build yeah for sure uh 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 turbo pack as well or i guess like rs pack you said there was a already implementation uh so the rs pack team they've done the implementation yeah okay and and we have seen a lot of users migrating from their Webpack setup to RSPack setups. And it seems to be going good. We don't get a lot of complaints, at least. But it's just because the RSPack team is killing it. I mean, they're just amazing. They've spit out packages.
The problem with Turbo Pack is that there's no open API. We wouldn't be able to integrate with Turbo Pack even if we wanted to. It only exists inside an XTS application. Oh, yeah. They actually recently moved the entire Turbo Pack repo. into the next js repo as well so like a i was like looking at i was like will this ever be something other than like a next js speed up
I don't think so now that it's that way. 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 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 thinking about it. Are you too worried about that right now? No. Imagine being on a team.
that you could call the turbo team. That sounds like a cool-ass team. I'd love that. It also puts a pressure on your shoulders. Everything you have to do just has to be super fast. Yeah.
You mentioned VTesta 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 got to say It kind of 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 can write the test in a standard, you know, testing language with VTest or anything like that.
testing going to be just like 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 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, okay, 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 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 the complexities of UI and not about like doing something in sequence.
Usually when you think about a unit test, you'd go from A to B to C, but UI is more than that. It's about interacting with it, and it's about having 10 different prompts to your component. 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.
Can you explain real quick for anyone listening? We'll stay on 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 stories file is what we call, it has a format that we call component story format, CSF for short. And it all starts with a default export.
of the meta information where you say, this is the component, and these are the default props I would like to pass into this component. In storebook, we call them arcs, but you could consider them props. and then you can do a lot more meta information and then after that you do uh 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 args 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. Okay.
For Svelte, we have a special Svelte syntax called Svelte CSF, Svelte Component Story Format, where it's slightly different, but it's way more intuitive for a Svelte user because you write it in Svelte syntax. But it's still the same idea. Okay, so you just basically import the component, and then you try to think of every possible combination of that component. A red one, a green one, a big one, a small one, et cetera, et cetera. Obviously, much more complex than that.
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. 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 Vtest or Jest, where you have element get by role.
or expect this to be in document like that's the exact same api 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 you can define these play functions for each story, essentially.
Yeah. And so it's a bit hard to explain the visual stuff. But 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 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. Yeah, if you've 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 that are very visual. I found that to be a 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 Storybook is that you can share your Storybook. So Storybook is an application that you can build and publish to Netlify or wherever you want to go. And then you can take that link and you can 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 said this failed and you have to go through it whereas in storybook you actually just to share the visual part with the actual DOM. Not even 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 sentry.io forward slash 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 century.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right.
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 kind of 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 a service that you pay for, but there's a very generous fruit 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 a 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 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 component level there. Because in the past, I've done regression testing and it's always been... page by page. And 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 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 catch when certain, I call it like website rot, you know, when things start to rot in your application where, ah, the...
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... 15 20 of those little rots over a couple years your website starts to feel kind of icky and old yeah it could also catch like that that i don't know if this is a problem that you have less maybe it's
I got lots of problems. Let's see. You think you got like 10 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 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 also help you to develop in a way that like you're not making those kind of choices 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, reproduce that instance where somebody's name is extremely long and then they click on the button. Then you go ahead and make that instance in there and then you go ahead and fix it, right?
Historically, if you've done visual testing in an end-to-end setting, as you say, it can be flaky. Because 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 where you have full control over what's rendered. And one of the biggest flakes we see is when people, they use Google Fonts and then the font just doesn't load.
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 Pelvetica or whatever, right? But you can configure your storybook to say, 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. That makes it a lot easier, I think, to write the visual tests. Yeah, because a flaky test is a test you ignore. Yes.
This is a guarantee. So I guess that leads definitely into the question of like storybooks 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 have an open collective where people donate, but it's like...
99% is funded by Chromatic. Stolberg'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. Let's talk about like best practices and whatnot when you're writing stories or building, 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 bad practices or best practices that pop up 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 a lot of components, and then they start to add Storybook in it. And as you say, 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 uh 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. 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.
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, in Next.js, 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 not end-to-end because you still don't have the database. You don't have the network requests to your auth provider and stuff. You're just marking all that out. It's just the UI still, even though it's a page. Does that make it tough to mock deeply nested components that might be loading their own data? Yes, for sure. 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 a recommendation. You shouldn't be afraid to mock things. It might feel dirty at first, but sometimes 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. I want to go back to the first thing you said, which was like splitting your components up into like functionality and presentational. So for anyone listening, what that would mean is like you'd have one component that handles all. 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 Storybook... Obviously, the presentational one, you would just do one on its own. Well, maybe not obviously. You would do the presentational one on its own.
But what about the one that has all the logic? Does that also go into Storybook for testing or is that something that should be tested differently? It depends on 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 storebook 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 want to 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 yeah 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 i mean that's a bigger discussion of course uh 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 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 It's certainly a far larger pain to have to try and test that stuff when it's all one big mess. My general recommendation is that you can put all of it into a store with you 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. Yeah. I have noticed that there's an accessibility add-on. and i typically do most of my accessibility testing by hand and 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 X.
the X 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.
uh you don't have the correct color contrast here or this heading is the wrong level and then it will also highlight it in the ui so we'll get a you'll get a little square on top of the the element that is violating which makes it a lot easier to to reason about but of course it's only on the component level 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 the automated accessibility testing stuff.
and then do the manual QA afterwards. Yeah, it does feel nice 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, all right, 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 uh then you're yeah you're you're doing that then and and it also plays into the new v test integration that we have so
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. And that's really cool. What we're seeing, though, so it's been in 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. I like that, being able to do it at a component level as well as like a... a page level because like like i'm just looking at the um 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. 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 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 it's a story a story yes okay well i thought the story was the whole thing
No, the whole thing is a component and then each 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 name and then this story is like also the same name. I'm like, well, it's the same story. And the storybook is like, you got to 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.
Yeah. Oh, okay. The story is the smallest possible implementation of it. Right. For now. You got a book full of them. For now. What else is there? Now, so 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 that would be two tests on that story. It's a future thing.
uh but it it's been requested a lot it makes it easier if you're transitioning from uh from a v test or just mindset because the syntax is closer to that yeah yeah i could see that uh no but you're right about the slider that like it's 30 different ways that you need to do accessibility testing you wouldn't be able to do that in your website dark mode you know plus uh someone has wide viewport i mean a narrow viewport and different oh yeah yeah you're right
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. Oh, yeah. So how does this component look with your green, red?
colorblind or how does this come is blurred i think that's really cool as well and helps a lot 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 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 theme. You can define 10 themes. Really? A billion themes in the theme switcher. Oh, I love that. I make themes. 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. 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. I'm glad that exists.
Yeah, that's something that Cypress had that I really liked. I was going to ask about that, so I'm glad to hear that. So for Svelte, it doesn't work with saving to the file, but you can still copy-paste it into the file. That's fine. There's also a SotoStates add-on. which allows you to force server states on your CSS. So you can say, now I want this button to be hovered. And then what does that look like? Which is pretty hard to do because...
There's no browser API to do that today. Yeah. But it does some magic behind the scenes. Oh, I would use that. The viewport stuff, 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. What are some areas where Storybook still falls short in your mind? One thing that we're already discussing for Storybook 10 is... We've talked about this transition from the old paradigm 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 VEAT 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 uh type safety in 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 bloat, but also reduce a lot of pain points with people having issues with Storybook CJS, doesn't import my component correctly and whatever.
So there's still some pain points there in us having just technical depth, basically. 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 i was like
Well, it's like that meme of the bird eating a cookie and being like, oh, hey. I think we've talked a lot about testing, right? But I would like to spend just one minute on the vTest integration because I think that's huge. Yeah, let's do it. There's a vTest add-on that you can add.
and if you're using a vt setup in storybook that allows you to uh first of all allows you to run all your stories as vtest tests so just similar to your regular vita setup you do vtest run and then it just tests all your stories Oh, OK. 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. We 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 us a quick rundown, yeah. So basically, you can write documentation for anything, your component or your stories, in MDX.
And you can define your own React components inside MDX and basically build up a full dock site for your application or design system. Storybook has this... doc gen 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 the label should be a text field and 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 don't have to manually define these are all the props that my component takes because we infer that directly from your TypeScript types. That makes sense. I mean, and then there's like a billion other things I don't think we need to go into though.
the whole thing yeah well uh man this has been real you know it's uh again it's 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 we spoke, you were like, give it to me harshly. 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 mean, I'm glad that we made that choice to develop an isolation in storybook and really just thank you so much for coming on. even clearing up a ton of stuff or letting the audience know what's been going on uh now is the part of the show where we get into sick pics and shameless plug sick pic 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. I brought a sick pig with me. It's a huge transportable speaker. It's a JBL 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 say can you put on an audiobook i'll just do the chromecast thing or the spotify cast 2 and that just works with this 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 then 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 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 in spotify just play this yeah bluetooth for that type of stuff yeah and like it and like you're
your phone's like still goes on and you can't walk far away. Yeah, yeah, yeah. That's really frustrating. Wi-Fi is the best. I, at our cottage, I have been working at getting like the outdoor... Wi-Fi just like dialed in for that exact reason. It's not that you just necessarily need Wi-Fi outside, but like speakers and cameras and things like that. Even like phone calls, the cell service is not.
great there but you can do phone calls over wi-fi and uh i have almost a kilometer it goes into the lake now uh blanketed in wi-fi and uh it's It's so nice to be able to not have to fuss with Bluetooth or some direct connection type for that type of thing. Right. And what would you like to plug? Obviously, traumatic. If you... If you like to use Storybook, if you like component testing, then try Achromatic 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 haven't already. Sick. Well, thank you so much. 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 is...
gained a new appreciation or is learning what's been going on in the storybook world. So thank you so much for coming on. It's been great. Yeah, thanks a lot. I appreciate 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. We will catch you later. Peace.