Storybook Has Evolved w/ Jeppe Reinhold

want to call, because it's still stories. It's just think of your stories as tests, 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, 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

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 So

Because, like, I can imagine again, we we talked about storybook in 2017

We had some great contributions, and then finally, we said, okay. We're gonna do this officially.

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.

the the five add ons and then the the integration and then the Svelte integration and all that. Right? And that was

Yeah. That's something that, an accessibility

of the meta information Wes you say, this is the component

even even just, like, component design in general.

For sure. Yeah. We have an integration with the mock service worker, MSW,

of the slider. And for every single one, there is 22

And what would you like to plug?

four props I would like to pass into the component.

type for that type of thing. Right.

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?

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,

And what a component needs to function independently

a format that we call component story format Mhmm. CSF for short. And it all starts with a an and a default export, which is one component takes a lot of props and then shows all the the styles and then a parent what your application is, especially if you Sure. So visual testing is is, it works except that the syntax for defining a story 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,

fix it. Right?

they start by For sure.

a joy working in open source, Webpack or these 10 v plug ins, you would want the same thing in Storybook so that your components

as well or, I guess, like, RS pack? You said there was already an implementation?

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, the which

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,

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.

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

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,

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.

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.

fix them and then turn them into errors so that they don't regress contribution to do the Vite builder integration.

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

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

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.

per

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.

but it it's been requested a lot. It makes it easier if you're transitioning from, The button was clearly resized 10 pixels.

They've spit out packages.

with most other tools, you're like sharing a log from GitHub actions that's, a rewrite of a lot of the stuff.

link and then actually router method or something. Yeah. Exactly.

and it will get some great results. But sometimes it's easier if you split it up and do it more granularly.

You can

Cool. Well, we will catch you later.

really

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,

Especially if you don't write if you don't write tests for a component today,

E 18 e dev? Ecosystem

because the syntax is closer to that. Yeah. We'll see I could see that. The lens.

That's essentially a function that runs after your story has rendered. So let's say you have a story for a form, And so now it's very close to just being I make themes. You you just 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.

fifteen, twenty of those little rots over a couple Yarn, your website starts to feel kinda

Yeah. So go to this And that's also been a joy to Or also for testing, which I guess we're gonna go more into today, That's how I met Scott.

the inputs and the outputs of specific components.

Oh, yeah.

I found that to be a nice ex nicer experience than having just my test pass or fail in a terminal somewhere. Right? 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,

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

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.

So it started

play ESLint it. Because we've all written code before where it looks good and it functions well

something that builds on top of Storebook, essentially.

And the actual bloat is what you have reacted to JS the the fact that Storebook had a lot of transitive dependencies Boombox then your component will react to that.

my recommendation would be to put the data loading somewhere else add on function, and you can import them and stuff. Hopefully, we're going ESM only in store with 10.

then that play function can contain interactions and assertions.

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.

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.

not an unexpected

then it's much more easy to to catch when

You don't have the correct color contrast here or, as a pure component.

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 Similar to, But it definitely it allows you to define, at the end of of Storebook six. That's where we did the first, Vite integration. It's it was actually a community

You mentioned Wes a while back,

you just define a lot of exports

Okay. So you're just basically, you're you're you import the component, and then you try to think of every possible combination

That's sort of the rundown of our store book is. Cool. Yeah. So you if you have, like, 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.

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

And one of my beefs with testing in general,

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.

all of the Next. Js APIs in store, they're mocked because, for sure. One of the funny thing that we're seeing now is that we have created a

you're doing it. But you can

Yeah. Especially because,

in the bundle size in terms of, like, 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, Storybook

with Chromatic. And Chromatic is is a service,

especially component based testing,

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

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,

strange.

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 and two managers, and we're all hired in Chromatic and work in the Chromatic, primary 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.

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.

I love

it kinda made me

I believe, 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

I am enticed by the idea that you could be getting

Obviously, And so we just have reimplemented all of those mocks in the Vite, block PRs and say, oh, that button is not good anymore.

just works and JS all pretty fast. When did that all happen?

instance

which is fantastic in my world because you build a bunch of small utility packages that you just reference internally.

I started trying out

And and that was historically really hard to set up, that duality.

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

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.

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.

implementation of it. Right. For now. Book full of them. For now. Be honest. Oh, what is this there?

afterwards.

be okay with writing tests because what you guys do is that, like, And and so it also does, in addition to just, like, component testing, like, visual testing,

like, you know,

some accessibility to catch up and really see what's been going on with Storybook lately. Longtime,

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, So that's why we recommend you do it on a component basis story. So you would for your 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.

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 that ensures that the logic actually works. Because 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.

in isolation

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

Yes.

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.

Was a a big emphasis on the reduction So in the past, I had used Storybook, and it felt like a and I'm gonna say, like,

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, recommend putting it in Storybook and do the work that allows you to write that that great interaction test with the great assertions,

It goes into the lake now, blanketed in Wi Fi. And, Mhmm. Yeah. That that's the story JS there. The smallest possible 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,

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

One thing that we're seeing all of the successful teams doing is actually also write stories for the pages,

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 am also responsible for the Svelte integration of Storybook.

you obviously, the presentational one, you would just

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?

someone has skied in this way.

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 It's month and month before to do that transition.

is still 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

nine, which is not out yet, I think it's in beta. Right? Mhmm.

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

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 Those are people that have not had the pain.

what's the what's the word for that? I I keep calling it permutation. What's the word in Storybook?

type safety in Node, define

And then how does that play into testing?

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,

it's it's so nice to be able to, like, not have to fuss with Bluetooth or, like, some, like, direct connection

is pretty hard. I mean, you can do a unit test for the specific function,

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 icky and old.

Yeah. I know poker. And then we we removed some dependencies because,

Oh, that's great. And

that just takes in a few cool props that you can do whatever you want. So you can write

add on, and I I typically do most of my accessibility

that's where it was like an official integration to Vite. Essentially, like, to give some context,

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

How do you decide what all the different props are to a component, all the different states?

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.

Yeah. I I have noticed that there's

that were some content in the CMS was updated

Storebook's a team of,

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.

areas where Storybook still falls short in your mind?

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?

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

and I gotta say,

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

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, somewhere down the line. And then,

No. Well, we we have, an open collective where people donate, but it's, like, Babel and Webpack had its peak.

What what it's a story.

And and then storebook ecosystem performance Sanity.

use some of the, are there any accessibility violations here? reported to you per component because it they're easy to fix on the component level, but you don't get the full

Man, this has been real. You know, it's,

Plus,

Yep. And these are the default

input on the page and make sure that

for your, button component, And then for Storebook seven, which was around I think almost three years now. It's

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?

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

Wes,

So it's just, like, way easier this,

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.

some chocolate, running it in a headless prod do whatever. But, like, it because that's usually running your whole site.

and I thought this would be a great opportunity

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?

these all the props that my component takes because we infer that directly from your, TypeScript accessibility testing stuff and then do the manual QA,

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.

in in eTest or Wes, where you have, oh, it's a huge, transportable speaker.

and then it saves the the play function to the to the story file. And that just makes sense.

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,

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

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.

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.

and then,

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.

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 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, And the reason I brought this on is because it both has Wi Fi and Bluetooth,

and

Right. So Storybook is we call it a a workshop for your front end. Wes, essentially, if you're building your,

I have been working at getting, like, the outdoor,

at first. Yeah. But sometimes Wes you reach it when your when your component isn't pure, 99% we sort of split it into two parts. We we called it actual bloat and perceived bloat.

in. You might be passing,

If you're doing a lot of custom stuff with and then they gradually in what I call the the modern paradigm, getting into we made it easier to just integrate into your existing beat setup. And then gradually, we've made that simpler and simpler.

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, pleasure for me to to get into to storybook again, but, like, I was delighted.

I'm sure that bad component design

Chromatic is the company that funds the development of Storebook.

Yeah. Wow.

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 It really depends on which previous version because the the biggest change from a b test or just mindset

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.

you would export primary. And then for that story, there would be an object where you put in arcs

Storybook.

Chromatic.

you mentioned the terminal. And first. Wes. It's getting into these states.

certain I call it, like, website rot. You Node? Wes things start to rot in your application where,

So I think that's a great relation.

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 So really give it a try if you, if you haven't already.

of the new version

like, you wouldn't

individual components out? Yeah.

bad practices or best practices that pop up when you're when you're trying to design a component that is

My general our journey towards reducing this bloat.

to be more natural to write add ons. You get, or you can change the label with another type of prop.

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

What about the

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

with this type of thing. Right? You can check that you're passing the accessibility in in Storybook,

you took a snapshot maybe ten days ago on the main branch, and this is a snapshot you're taking today.

visualize this, obviously, it's your component rendered out in isolation. But, like, how do you write a story?

then some of the things that we're discussing here might seem

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.

if you've ever written tests with testing library, when you have a high fidelity test, you have a flaky test.

and I have noticed an emphasis in many regards on whether that is, like, visual testing or testing in general in Storybook.

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.

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

has this change

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.

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

Was that kind of transition, like, perilous?

And so Wes what you would expect it to happen? And then they can see that visually.

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.

every single day working with the tool chain that I love, JavaScript.

15 packages, I think, to pnpm

One thing that I noticed in the the announcement

is is old in Japanese history. I think storybook is seven years old, if not more. And way back when, that was when

of the slider. You know? It's editable with the default value, multiple sliders in it, two handles,

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,

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

So simply just developing them and designing them in in isolation that's that's significantly faster? Or or how much faster? Do you know that was it versus, like, a Webpack implementation?

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,

And so

and works well?

incentive to improve storybook because otherwise you can't

announced a a new version that's in beta Vercel number nine. We are using Storybook on the Syntax site, you'll want to check out Sentry at century.i0/syntax.

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

how are you using Vite? Is that just to render the 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

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? filling out form

I love that.

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

getters and setters. You might be passing booleans.

It depends on

to be able to really truly understand, like, why is your help while you're actually developing.

these two errors to show up in the document or expect this function to have been called because it actually submitted successfully.

it always felt like components are so visual. Now I'm writing this code

TypeScript Cool. It's a community of some really smart people that

So, hopefully, the audience out there has when developing

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

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,

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,

And, shameless plug, sick pick is anything that you might be just enjoying right now in life. Could be anything,

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.

where somebody's name is is extremely

unexpected happened, why didn't this error show? You can step to the for us.

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.

into the Next. Js repo as well. So, like, I I was, like, looking at it. I was like, will this ever be something

Yeah. I found it's been very helpful for us in in this process because

we ever did was storybook six to seven. That was a huge change. It was almost 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

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

might not be logical.

is more based on around the complexities of the UI and not specific input label you just define what it should do when you change it, and

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,

or

stuff. Right. So I'm Jeppe. I'm a software engineer at the storybook team in, to Netlify or wherever you wanna go.

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.

And and you can define these play functions for each story,

again, it's it's one of those things that I was such a And, when when we spoke, you were like,

Yeah.

then you're,

well, you need to refactor your component to be testable. Similar to how you would do unit Wes. Right? And one of the biggest,

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,

if you

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.

Storebook has

It does give you that same sort of development workflow

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 a lot of dependencies. So the biggest one was Express.

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,

You know?

has this made working on it easier or more difficult?

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

to test my components in a nonvisual way. It always felt very odd to me. But

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

Mhmm. And I've been working in the Storebook team for

outside of, like, the by hand in Polypane. It's like, let's load it up in Polypane. Let's do it once over on the site.

a lot of fun, and I hope to be here again one day. Yeah. Totally.

the slider itself, there's probably

a smart component

testing

Okay. Where you actually do the interaction.

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

made developing especially if I was using certain build tools or whatever.

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

You shouldn't be afraid to mock things. It might feel dirty

Oh, I'm gonna start parties.

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

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,

several different instances

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 to force pseudo states on your CSS. So 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

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

Again, like, for me, I'm a visual guy, and we're writing components. They're very visual.

So it

the testing.

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, 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, is funded by Chromatic.

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

Like, because I saw you being a little critical, and I was like, honestly, it's

And then, which is Wes you initialize a new Storebook project, we would historically, we would add

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.

six engineers official

Cypress or something like that, it's not like the same concept because that's listeners of the show

and you can actually step through it. So you can say so if there's something

speaker. For that type of stuff. Yeah. And, like, it and, like, your

If you 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,

podcasts, the Wes testing in Storybook,

You can configure it however you want to, like, with different levels and different rules. But, essentially, it'll show you the violations.

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.

So a story's file is what we call it's essentially.

It's a JBL

give it to me harshly.

That's that's a common problem with developing in the application that you you pay for, but there's a a very generous feature, again repeated.

And that doesn't care if it if the fetch happens in a very low level component or if it's high level component.

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

reinvent Thank you for having me. This was

And if you want to see all of the errors in your application, 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.

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 you can say, now I want this hover this button to be hovered.

But it doesn't match behind the scenes.

I think that's a huge win for testable components.

design,

And it also had a huge install size, like, hundreds of megabytes.

permutations

from component testing, is that they are just testing a lot. And and when they really go into testing of their components, Whereas

Storybook has,

because what we're seeing is that users love it. Users love it when we

oh, well, I didn't expect you to do that with the app. Let's go

testing that logic afterwards again.

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

push that we're doing now. On the surface, we haven't haven't actually changed much

30 different permutations

things we tell people is do the presentational component versus 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.

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,

dead nuts the exact same way every single time,

Right? But that would definitely be our recommendation.

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.

earn stuff in in Chromatic.

equals true,

tree all the way down.

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

like, what's going on with accessibility and, like, what the features do here?

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 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, while still using Next. Js.

three Wi Fi.

And it's just it's fantastic.

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 you don't have to look at them in the app, but, like,

Oh, interesting.

develop that component in, like you said, like, in isolation so that the rest of the website doesn't have to necessarily

render equally the same. Right? should reduce a lot of more bloat, but also reduce a lot of of of pain points with people having issues with Storebook. CSS

comes to you as well tested

And you can you can you can define your own React components inside MDX, documentation, and testing.

And then that really allows you to just ourselves and actually keep up with the ecosystem.

a very good way to construct components,

when you're writing stories or or building

garden tool, just literally anything. So and a shameless plug, whatever you wanna plug. I brought a sick pick with me. It's,

website or your UI, you would probably use components. And Storybook allows you to work with these components in isolation.

when it

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 one export And at that point, the paradigm was

allows you to just focus in on that as well as as focusing on, like, different states as well. Right? Like, you may have

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.

organization.

And then you can you can take that Tolinski, and you can say send to your designer and say, hey. Is this

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,

are transforming the, JavaScript ecosystem by building smaller packages and replacing packages. And they kick started It's a lot easier. I think to explain that well, we have to do sort of a history lesson because storybook But in SvelteKit, you have Next. ESLint Remix, 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 hundreds, element, And then we tackled the perceived bloat in Storebook nine, take from Sure. So,

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.

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

split. It's an old way. I we haven't discussed this in, like, five years or something. Yeah. But it's still 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.

and and basically build up a full doc site for your application or design system.

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

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 your page is actually also a component having accessibility

both the size, but also, like, the dependency Yeah. It does feel nice like it would have to have at least a little bit of a net there

and then you press save, recommendation is that you can put all of it into store review if you want to,

tree complexity. Yeah. Significantly

we we replaced 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, That was by far the biggest part of that tree. We replaced that with poker, which is, like, way smaller. It has two dependencies.

axe core, the the axe package to say, So that would be the slider in this specific configuration doesn't import my component correctly and whatever. So there's still some pain points there in in us having just technical depth, basically.

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

Can you tell me a little bit about,

separately off. So that was that was, like, the actual bloat of the of the the megabytes and the But starting with Storebook seven,

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,

And that has its own trade offs, of course. But for us, we thought it was the the best trade

write a reproduce that that,

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, Mhmm. Storebook has three pillars. It's development,

Let's talk about, like, best

they see huge huge benefits in terms of their own development speed and and just their usage of of the storybooks.

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.

honestly believe that visual testing new components is a huge time saver.

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 of of magnitude, what,

will know that in one of the very first Syntax episodes back in 2017,

Mhmm. Like, hundreds and hundreds.

React Spectrum

It was like the main store group and then it's sort of like integrate directly into your Storybook and see the diffs there. I really about, like, doing something in sequence.

or is it the component itself?

And,

possible

if you're using a v test setup in Storybook

like a podcast component, right, you may you may

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, violations as warnings,

for every possible

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.

oh, how do I ever write a story for this component? That must be because storybook sucks, but then, end of twenty two, I think,