Speaker 1: Hello everyone, welcome to another episode of Svelte Radio. I'm joined this time by my
Speaker 1: beautiful co-hosts, Anthony, Brittany. Hello.
Speaker 2: Hello.
Speaker 1: Hello. Hey, Anthony's audio is a bit
Speaker 1: weird because he's at a castle in Portland, specifically not the US Portland.
Speaker 2: Yeah, luckily right now. Specifically
Speaker 3: Pennsylvania Castle, which is also not the Pennsylvania next
Speaker 3: to New York.
Speaker 1: Oh, wow. It's absolutely beautiful though
Speaker 2: for listeners. Sorry.
Speaker 1: Yeah, it is. Yeah.
Speaker 1: And then I was going to say, we also have a very beautiful guest.
Speaker 1: Jeppe is back.
Speaker 1: I think you've been on the podcast once before, right?
Speaker 1: Or at least on the YouTube
Speaker 4: channel.
Speaker 4: I have not.
Speaker 4: I've been
Speaker 1: on the video thingy.
Speaker 4: Yes.
Speaker 4: That makes
Speaker 1: sense.
Speaker 1: I have not been on the radio.
Speaker 1: Welcome, Jeppe.
Speaker 1: Great to see you.
Speaker 1: I
Speaker 4: haven't been referred to as the beautiful before, so I'll take that.
Speaker 1: Every guest that we
Speaker 3: have
Speaker 1: is beautiful.
Speaker 4: Oh, that made
Speaker 1: it less cool.
Speaker 3: Beautiful storybook.
Speaker 1: Yeah, so you work at Chromatic, right?
Speaker 1: I always mess that up.
Speaker 1: I always say, oh, you work at Storybook.
Speaker 1: But no.
Speaker 4: I work on Storybook at Chromatic.
Speaker 1: Yeah, yeah.
Speaker 4: Maybe you can tell us a bit about yourself.
Speaker 4: Yes, so I'm a software engineer at Chromatic.
Speaker 4: And I am from Denmark.
Speaker 4: But all my colleagues are not.
Speaker 4: So I work from home.
Speaker 4: And that's great.
Speaker 4: I love that.
Speaker 4: Everyone should do that.
Speaker 4: And so I work on the Storybook team.
Speaker 4: And Storybook is open source.
Speaker 4: Storybook is free.
Speaker 4: But we're quite a big team.
Speaker 4: We're actually eight maybe now.
Speaker 4: And everyone is in the core team.
Speaker 4: It works at Chromatic.
Speaker 4: So Chromatic funds the development of Storybook.
Speaker 4: And that's awesome.
Speaker 4: I've been doing that for three years now.
Speaker 4: And three years ago, the Svelte integration was
Speaker 5: not that great,
Speaker 4: but maybe it is now.
Speaker 4: So maybe there's something going on there.
Speaker 4: Well,
Speaker 1: before that, let's maybe explain to the listeners,
Speaker 1: what is Storybook?
Speaker 1: Give us
Speaker 4: the elevator pitch.
Speaker 4: Yeah, so Storybook is sort of like a workshop
Speaker 4: for a component development,
Speaker 4: where usually when you're building components in Svelte,
Speaker 4: you will put them in your application,
Speaker 4: and they will work fine.
Speaker 4: But then as you put them in some other page,
Speaker 4: it'll start to break
Speaker 4: because that use case wasn't part of the component.
Speaker 4: And so Storybook is a way for you
Speaker 4: to look at your components in isolation
Speaker 4: so that you can really just focus on the component
Speaker 4: and make it great with the props
Speaker 4: and what state it needs to be.
Speaker 4: And then you can specify different stories,
Speaker 4: which are like use cases for a set component.
Speaker 4: And then once you're ready, saying now the component is great,
Speaker 4: you put the component into your application,
Speaker 4: and then it's there, right?
Speaker 4: Storybook is sort of like a companion app,
Speaker 4: similar to vTest being something that runs alongside your application.
Speaker 4: It's not part of the application as such.
Speaker 4: And then you can use it for testing and for documentation as well
Speaker 4: and for development.
Speaker 4: And yeah, that's Storybook and the Nutshell.
Speaker 3: Am I right in saying here that Storybook runs alongside
Speaker 3: your main application, but it shares the same source code
Speaker 3: so that what you're testing is the real thing.
Speaker 4: Exactly.
Speaker 4: So similar to when you have some unit function file,
Speaker 4: you will write a.test file next to it
Speaker 4: and import your actual code.
Speaker 4: You'll also write a.stories file next to your components
Speaker 4: and then import your actual components.
Speaker 4: So it's using the same source.
Speaker 4: It's even using the same Vite config if you want to.
Speaker 4: And so the setup is the same, more or less.
Speaker 1: All right, cool.
Speaker 1: So this episode is titled Storybook is Actually Good Now
Speaker 1: because I remember back in the days,
Speaker 1: like before I even started using Svelte,
Speaker 1: back when I was using the Cursed Framework, React.
Speaker 1: It wasn't very good.
Speaker 1: I shall not speak of React.
Speaker 1: It wasn't very good back then either.
Speaker 1: There's...
Speaker 1: There's
Speaker 2: probably still a video of me on this Felt Society YouTube channel just struggling to get Storybook set up.
Speaker 2: And I think that might have spurred some of this.
Speaker 4: That was a very important video.
Speaker 4: That's for sure.
Speaker 4: And I can tell you all about the backstory here.
Speaker 4: So Storybook was originally for React.
Speaker 4: Like Storybook's old.
Speaker 4: Storybook's like eight years old now or something for React.
Speaker 4: And then it expanded into other frameworks as well.
Speaker 4: And it also expanded into Svelte via community contributions.
Speaker 4: And that was before my time.
Speaker 4: So I'm just relaying information I've heard, right?
Speaker 4: But essentially, these contributions were pretty great.
Speaker 4: It created an okay integration between Storybook and Svelte.
Speaker 4: But the problem with this was that
Speaker 4: these were often like drive-by contributions.
Speaker 4: because you would have like this very passionate engineer
Speaker 4: that got hired into a Svelte project
Speaker 4: and he wanted to use Storybook.
Speaker 4: And so he spent a bunch of time contributing stuff.
Speaker 4: And then six months later,
Speaker 4: he got moved into another project that didn't use Svelte.
Speaker 4: And then he left it.
Speaker 4: And then the next engineer came in
Speaker 4: and then that kept happening over and over again.
Speaker 4: And so they built something great,
Speaker 4: but then it wasn't really maintained by the same person.
Speaker 4: And that sort of made it rot a bit
Speaker 4: up to the point where
Speaker 4: Brittany posts a video of her setting up
Speaker 4: Storybook with Svelte.
Speaker 4: And the interesting thing about this video
Speaker 4: was that Brittany was very enthusiastic about it.
Speaker 4: Brittany really wants to make this work.
Speaker 3: Enthusiastic
Speaker 4: is such a diplomatic way to put it.
Speaker 4: Right.
Speaker 4: No, but she wanted it to work.
Speaker 4: It wasn't just like, I'm going to do a video
Speaker 4: and then rant about all this not working.
Speaker 4: Like that just happened because the experience was so bad.
Speaker 4: And that was an eye opener for sure.
Speaker 4: And the biggest reason was from my remembering,
Speaker 4: this was maybe three years ago,
Speaker 4: the biggest reason was that Storybook was only Webpack back then
Speaker 4: and Svelte had already moved over to VEAT.
Speaker 4: So when you try to set up the same thing in Webpack and VEAT,
Speaker 4: you're going to run into something you don't like.
Speaker 2: It was a webcat config, man.
Speaker 2: It was awful.
Speaker 4: And I believe the video ends with Brittany just saying,
Speaker 4: I can't do this.
Speaker 4: It doesn't work.
Speaker 4: Brittany is a reverse influencer.
Speaker 5: And so at
Speaker 4: that same time, I was actually,
Speaker 4: I was interviewing for Storybook.
Speaker 4: And one of the things that I said was like,
Speaker 4: I really like Svelte.
Speaker 4: So if there's anything we want to do about Svelte,
Speaker 4: I would love to help out.
Speaker 4: And then combining that with Brittany's video was like,
Speaker 4: oh, we need to do work here.
Speaker 4: And so that started our first integration to SvelteKit.
Speaker 4: We did an official SvelteKit package,
Speaker 4: which was basically, if you have SvelteKit,
Speaker 4: here is a zero config setup for you
Speaker 4: because there's some stuff that you need to modify
Speaker 4: and we'll modify that behind the scenes in your read config.
Speaker 4: And that really kick-started the whole,
Speaker 4: let's improve the Svelte integration.
Speaker 4: And with me being on the core team,
Speaker 4: with me being sort of enthusiastic about Svelte.
Speaker 4: I love Svelte.
Speaker 4: That was like sort of one hand
Speaker 4: that just could keep maintaining it
Speaker 4: instead of these drive-by maintainers.
Speaker 4: And so I've been building on top of what we had previously.
Speaker 4: I haven't started anything from scratch.
Speaker 4: I don't want to take the work away from them.
Speaker 4: Yeah, and so it also kick-started a collaboration
Speaker 4: with the Svelte core team.
Speaker 4: I think Ben McCann, who's like a fantastic guy,
Speaker 4: He was the first one to reach out and say,
Speaker 4: hey, can we make this integration better?
Speaker 5: And throughout the
Speaker 4: years...
Speaker 4: I was going to say, Ben feels
like he's the glue.
Speaker 4: Yeah,
Speaker 1: he's the glue between
Speaker 3: everything.
Speaker 3: Yeah.
Speaker 3: He's like the integrations guy.
Speaker 3: He just kind of reaches out to every third party
Speaker 3: and then says, hey, let's integrate in both directions,
Speaker 3: which is really cool.
Speaker 4: Yeah, I agree.
Speaker 4: And he keeps doing that with the new package overview ecosystem thing, right?
Speaker 4: So that's amazing.
Speaker 4: And essentially, that collaboration between the Storybook core team
Speaker 4: and the Svelte core team just kept improving.
Speaker 4: We kept having more and more people chiming in.
Speaker 4: Dominic also helped out a lot.
Speaker 4: Lately, Simon has also helped out.
Speaker 4: Paolo, of course, has contributed stuff.
Speaker 4: And it's just really powerful.
Speaker 4: So because in Storybook,
Speaker 4: we integrate with all the major frameworks now.
Speaker 4: We have like Angular Review and React
Speaker 4: and web components and such.
Speaker 4: And there's no other framework
Speaker 4: that we are more close to collaborating with as Svelte,
Speaker 4: like by far.
Speaker 4: And we can really see the impact
Speaker 4: in every day, basically.
Speaker 1: So in terms of like functionality
Speaker 1: that has gotten better.
Speaker 1: I have some vague memory of,
Speaker 1: was it slots that was a bit problematic
Speaker 1: to do stories with?
Speaker 1: Or am I misremembering?
Speaker 4: Yeah, so.
Speaker 1: That's working now.
Speaker 1: Well, I guess slots aren't a thing
Speaker 1: kind of ish anymore, so.
Speaker 4: Well, what's little snippets?
Speaker 4: It's just as awful, honestly,
Speaker 4: if we hadn't done anything, right?
Speaker 4: And so there's a specific format
Speaker 4: in a storybook
Speaker 4: that you write your stories in.
Speaker 4: And it's based on JavaScript ESM.
Speaker 4: And so you have these objects.
Speaker 4: And then you reference your components,
Speaker 4: but then Svelte components,
Speaker 4: and you want to pass in slots to them,
Speaker 4: you can't really define a Svelte component in JavaScript.
Speaker 4: And so that's like the API for that.
Speaker 4: It's really bad.
Speaker 4: And therefore there exists an alternative syntax
Speaker 4: called Svelte CSF.
Speaker 4: which also existed before my time
Speaker 4: I just improved it
Speaker 4: where you write all your stories in svelte syntax
Speaker 4: so that way you can get in slots or snippets
Speaker 4: and you can do your svelte states
Speaker 4: and you're derived like all the runes work
Speaker 4: and that is what we hear at least from users
Speaker 4: that like they really like that way better
Speaker 4: because they're used to their svelte syntax
Speaker 4: so they just want to write their stories in their svelte syntax
Speaker 4: like imagine if you could do the same thing for your vtest unit tests writing that in svelte right
Speaker 2: well i've been saying that for a while that i do all of my testing in storybook now because it uses
Speaker 2: vtest and you just write a play um prop on your svelte csf and you write your test just straighten
Speaker 2: that and
Speaker 4: i'm happy to hear that i mean that's that's what we want people to see uh because like
Speaker 4: So for people that don't know,
Speaker 4: stories is like this snapshot of your component
Speaker 4: with specific props in a specific environment.
Speaker 4: Maybe you have a component
Speaker 4: that is encapsulating your other component
Speaker 4: or maybe you have svelte context.
Speaker 4: And then as Brittany said,
Speaker 4: you can also write a play function is what we call it
Speaker 4: where essentially you interact with components as well.
Speaker 4: So you might do click the button
Speaker 4: and assert that the form has opened
Speaker 4: or assert that you got a form error or whatever.
Speaker 4: and then when you see this in the storybook UI
Speaker 4: you will see the interactions play out
Speaker 4: so you can actually see the mouse clicking and whatever
Speaker 4: and we feel that that's pretty powerful
Speaker 4: because UI is visual
Speaker 4: why does it have to live in the CLI?
Speaker 2: You can see each step
Speaker 2: you can stop each step
Speaker 2: you can replay the test
Speaker 2: it's such a nice visual to go along with it
Speaker 2: I love it
Speaker 2: I think that's
Speaker 3: a really powerful thing
Speaker 3: the ability to step through something,
Speaker 3: which kind of relates to how debuggers work, I suppose.
Speaker 3: But a lot of early testing frameworks for UIs,
Speaker 3: and I've had many years of experience with them
Speaker 3: as a contributor and a person who uses them day to day,
Speaker 3: the thing that's really missing from everything
Speaker 3: was a way to properly debug it, properly step through,
Speaker 3: go and watch visually what's happening
Speaker 3: as the steps of the test execute.
Speaker 3: And I think when I saw, what was it called?
Speaker 3: I haven't used it so long, I've forgotten.
Speaker 3: The browser testing framework, Cypress, right?
Speaker 3: You know, when I see that, and I didn't like the syntax,
Speaker 3: it wasn't like I was used to,
Speaker 3: but the fact you could stop a test
Speaker 3: and just see what's going on right there,
Speaker 3: it makes debugging go from probably hours of time wasted debugging
Speaker 3: to instant debugging.
Speaker 3: And I think that's a super valuable feature.
Speaker 4: And also there's some playwright also have like traces videos
Speaker 4: where I can see the recording, which is also very powerful, right?
Speaker 4: Our take on that is interactability.
Speaker 4: So what Storybook allows you to do,
Speaker 4: you build a static version of your Storybook
Speaker 4: and then you can publish that with Chromatic
Speaker 4: or with Netlify or whatever you want to do it.
Speaker 4: And then if there's a problem in your interaction test,
Speaker 4: you can send the link, the published link,
Speaker 4: you can send that to your designer or someone and say,
Speaker 4: hey, why is this not working as you intended it to work?
Speaker 4: And then they can actually interact with it.
Speaker 4: They can stop at the step that it's broken in
Speaker 4: and then they can write stuff in the,
Speaker 4: it's not just a static image or a static video.
Speaker 4: I think that's super powerful.
Speaker 1: Yeah, I need to really like set up storybook
Speaker 1: for the new Svelte Society website.
Speaker 1: Maybe I can invite you to, with testing, yeah.
Speaker 1: Oh no,
Speaker 2: with the new SV integration too,
Speaker 2: like it's literally a one-step thing.
Speaker 2: just select that you want to add storybook and it's so easy to just
Speaker 4: get in there that was also
Speaker 4: like i was like spelt people's i should redo
Speaker 2: the video but it would be like five minutes of me just
Speaker 2: setting up a spill kit site
Speaker 3: it's
Speaker 5: super decent you'd
Speaker 3: be an influencer then and we don't want that
Speaker 2: i should do a tiktok video of it uh
Speaker 4: we also recently modified the or contributed to the
Speaker 4: Svelte docs. And so now Storybook is described how you test
Speaker 4: with Storybook in Svelte docs. So that should
Speaker 1: make it easy to get started.
Speaker 1: Nice. Yeah. I might need more hand-holding
Speaker 1: so I might just invite you to do a video with me.
Speaker 1: That's a good idea. I had
Speaker 4: a great chat with Scott
Speaker 4: Talinsky at the Svelte Summit where he basically told me that
Speaker 4: they were doing component-driven rewrite of their website
Speaker 4: syntax
Speaker 5: and
Speaker 4: they were doing it like storybook first which was like amazing to hear because he
Speaker 5: has been
Speaker 4: not a fan of it previously and so now hearing that they're doing it with a component first and then
Speaker 4: putting it into the application afterwards that was pretty amazing to hear
Speaker 3: yeah i say i'm being
Speaker 3: people who
Speaker 4: get to rewrite the websites that's
Speaker 2: how i build my design systems now i'm i'm on my second
Speaker 2: design system where i've started building components put them in storybook test everything and then
Speaker 2: they get dished out to the apps.
Speaker 3: It's like the dream.
Speaker 3: It's like how dev should have worked, right?
Speaker 2: Yeah.
Speaker 3: Greenfield is best field.
Speaker 1: Yeah.
Speaker 1: Yeah, brownfield, not so much.
Speaker 5: Everything feels like brownfield.
Speaker 1: Yeah, I've been working on way too many, like, not greenfield apps lately.
Speaker 4: It's a bit painful.
Speaker 4: It's healthy, though.
Speaker 4: So, I mean, getting a brownfield application to work is, like, way harder than them.
Speaker 4: Yeah, we
Speaker 2: learn
Speaker 4: from mistakes and all that.
Speaker 2: My latest company is taking a greenfield design system and putting it back into other things now.
Speaker 2: But
Speaker 1: that's,
Speaker 2: like, even harder, I feel like.
Speaker 1: Rainbow field.
Speaker 2: We have a new application it's being used in, but then they're like, oh, this old application can use it too, right?
Speaker 2: So now we're just migrating everything.
Speaker 1: Right.
Speaker 1: Well, you got to start somewhere.
Speaker 2: Yeah.
Speaker 2: Storybook
Speaker 1: got us
Speaker 2: there faster.
Speaker 1: I mean, probably, right?
Speaker 2: Oh, for sure.
Speaker 2: Yeah.
Speaker 1: Yeah, it would be bad if it was the other way around.
Speaker 1: It took longer.
Speaker 2: No, I
Speaker 1: think it's such
Speaker 2: an easy integration and building out your components, making sure they work.
Speaker 2: I mean, you have less bugs for your users once it does get used.
Speaker 2: So we're able to put those into older applications easier.
Speaker 2: and know that it's trusted.
Speaker 1: Yeah.
Speaker 1: I had a question about,
Speaker 1: so I don't know if you've thought about this much,
Speaker 1: but these new remote functions
Speaker 1: that have been released in SvelteKit,
Speaker 1: now that we have a way of basically combining data loading
Speaker 1: and interactions via functions,
Speaker 1: are you thinking about how to maybe integrate that into Storybook?
Speaker 1: Like you could have a remote, let's say you have like a widget of comments or something,
Speaker 1: and then you have, you want to make sure that the remote function does its thing
Speaker 1: and maybe different variations of like failure states, success states, et cetera.
Speaker 1: Is that
Speaker 4: something
Speaker 1: you've...
Speaker 4: For sure.
Speaker 4: So there's one important limitation about Storybook to know
Speaker 4: is that everything you do happens on the client.
Speaker 1: Yeah.
Speaker 4: And that's why we can also do static builds
Speaker 4: because there's no server really.
Speaker 4: And that's, of course, a big issue for remote functions
Speaker 4: because they're meant to run on the server.
Speaker 4: And there's really just two ways to think about it is
Speaker 4: what is it that, if you consider Story like a test,
Speaker 4: what is it exactly that you want to be part of that?
Speaker 4: Because sometimes you may say that you just want to look at the component and the UI
Speaker 4: and that the remote function is not part of that.
Speaker 4: And so
Speaker 5: you mock
Speaker 4: it out.
Speaker 4: Since
Speaker 5: Storybook
Speaker 4: has a mocking API similar to vTest,
Speaker 4: so you will just say, mock this remote file
Speaker 4: and replace it with something that you fully control.
Speaker 4: When this function is called with these parameters, return that.
Speaker 4: And I think that's easy and that makes your stories deterministic.
Speaker 4: You don't want your
Speaker 5: stories at all
Speaker 4: to depend on externalities at all.
Speaker 4: But then you say, well, but then I'm not testing the fact
Speaker 4: that the interaction with the remote function works.
Speaker 5: And so you
Speaker 4: can also say, keep the remote function,
Speaker 4: but then mark out all the server-dependent parts.
Speaker 4: So maybe you have a database that you're calling,
Speaker 4: and so you want to mark out the database modules instead.
Speaker 4: And so it really is up to you where you want to define the layer,
Speaker 4: but you are probably going to need to mark something
Speaker 4: because the remote functions work on the server,
Speaker 4: which we don't have.
Speaker 1: And that's fine that you would have to mark it
Speaker 1: because you would have to mark any kind of call
Speaker 1: to remote service anyway, right?
Speaker 4: Exactly.
Speaker 4: Yeah, you don't want the remote service to have an impact.
Speaker 4: I must say that I haven't tried remote functions in Storable yet.
Speaker 4: So there's the API of remote functions with like query and command and that jazz.
Speaker 5: I'm not actually sure how that works
Speaker 4: in Storybook form.
Speaker 4: Maybe it works, maybe it doesn't.
Speaker 4: I need to have a chat with someone from Svelte team about what it does behind the scenes
Speaker 4: and can I make that work on the client as well.
Speaker 4: But so for now, the safest bet would be mark out the full remote function.
Speaker 1: Yeah.
Speaker 1: And then I'm sure we'll figure
Speaker 4: it out.
Speaker 1: Yeah, so that would mean, so at the moment,
Speaker 1: you would just import the function, right, in your component,
Speaker 1: and then you would use it.
Speaker 1: So you would have to rewrite, you would either have to import
Speaker 1: the function from somewhere else or pass it in as a prop.
Speaker 1: So you kind of run into some weird.
Speaker 1: You can even, because you can mock
Speaker 4: the module.
Speaker 4: You can
Speaker 5: import the remote function.
Speaker 5: Oh, I see, okay.
Speaker 4: That's a strong suit about Svelte, because if you compare that to
Speaker 4: react server components which are i have all my server stuff at my component and the store books
Speaker 4: just chokes on that for now we have ideas but we you can't really just say i want to mark mark uh
Speaker 4: certain parts of my file right it's either
Speaker 5: okay and
Speaker 4: that's really the benefit of of the i know
Speaker 4: that this is rich harris's uh big thing is that you need to have separate files for your server and
Speaker 4: your client always
Speaker 5: yeah and
Speaker 4: that definitely that makes storebook way easier because then you can
Speaker 4: say all these server files over here i'll just i'll just mock those out because they don't
Speaker 3: mean
Speaker 3: even even you know it makes sense in terms of not getting confused between dependencies and
Speaker 3: accidentally importing certain things
Speaker 5: when it shouldn't be
Speaker 3: imported and get exposed in a bundle
Speaker 3: or something but even beyond that if you look at how mocking has worked for a million years
Speaker 3: no matter what framework or
Speaker 3: testing library you use, they always
Speaker 3: struggle with partial mocks.
Speaker 5: Partial mocks
Speaker 5: themselves
Speaker 3: feel like an anti-patter anyway
Speaker 3: but
Speaker 5: they're
Speaker 3: kind of like a last
Speaker 3: case resort but they always, always struggle
Speaker 3: because you're trying to
Speaker 3: take something real
Speaker 3: and just kind of half fake it.
Speaker 3: The whole concept is balmy.
Speaker 4: Yeah, so you just put in
Speaker 4: mock and then you pass in the path to
Speaker 4: the remote function file and then that whole
Speaker 4: file is marked out. You don't have to do dependency injection or anything.
Speaker 1: Yeah. All right. Yeah.
Speaker 1: It's a good answer. So what is
Speaker 1: coming up in Storybook? What's a new cool thing
Speaker 1: that we can talk about?
Speaker 4: Storybook 10 is in beta
Speaker 4: and Storybook 10 is not... We did some
Speaker 4: Svelte fixes. So in SvelteKit, you've had this module
Speaker 4: called $app.state for a while since full five.
Speaker 4: And we didn't support mocking that.
Speaker 4: But now we do in Storybook 10 at least.
Speaker 4: So essentially, maybe you're writing stories for your page,
Speaker 4: which is totally fine.
Speaker 4: You don't have to do it for design systems.
Speaker 4: And this page, it imports what is the current URL?
Speaker 4: What is the current queue parameters from app state?
Speaker 4: And then in the stories, you just define,
Speaker 4: well, this is a story where the URL is X.
Speaker 4: And this is a story where the parameters are.
Speaker 4: And so you set up these scenarios for each page state, essentially.
Speaker 5: Yeah.
Speaker 4: And we just added support for that
Speaker 1: now,
Speaker 4: even though it's been a while.
Speaker 1: That sounds really nice, especially if you want to test a full page
Speaker 1: and you're relying a lot on query params and stuff like that.
Speaker 4: Yeah, because doing this manually is often really tedious.
Speaker 4: You have to keep visiting this page over here
Speaker 4: with this exact user logged in and whatever.
Speaker 4: And that's where a store book really shines
Speaker 4: in that you just predefined that in your story
Speaker 4: and say, this is when the user is logged in.
Speaker 4: We also added support for async components,
Speaker 4: which is great.
Speaker 4: It should just work out of the box.
Speaker 4: And you can even, in your play functions,
Speaker 4: You can even do some assertions like when the async stuff is still loading.
Speaker 4: And then you can await it being done loading.
Speaker 4: And then you can do some more assertions.
Speaker 4: So you can really do it in between the async stuff.
Speaker 2: You're actually giving me ideas right now because I have not been testing my pages.
Speaker 2: We just have the components in Storybook, but then the pages go in the app.
Speaker 2: And
Speaker 6: we
Speaker 2: send them to QA and then they come back like 15 times because it's like manual process.
Speaker 2: She goes
Speaker 5: and she checks
Speaker 2: everything.
Speaker 2: It fails.
Speaker 2: It comes back to me.
Speaker 2: And so I could just run these tests and make sure everything works.
Speaker 1: Yeah.
Speaker 1: And you'll speed up development as well, right?
Speaker 1: Because you'll just skip the back and forth because you'll see the
Speaker 4: errors yourself.
Speaker 4: Yeah.
Speaker 4: And you can run.
Speaker 4: I don't know.
Speaker 4: Maybe you do that, Brittany.
Speaker 4: But if you run the tests, like the storybook story tests in the CLI and CI, then it'll fail.
Speaker 2: I do it.
Speaker 2: locally. I don't have it set up in RCI right now, but
Speaker 4: yes.
Speaker 4: One thing that you need to do, like when you do think about SvelteKit pages in Storybook is that
Speaker 4: there's no way of automatically adding the layouts, similar to like what SvelteKit does.
Speaker 4: So when you write a story for a page, you also need to
Speaker 4: write that it is within this layout and this layout. That's also sort of powerful because
Speaker 4: then you can look at the page in different layouts
Speaker 4: but it's also like sort of painful
Speaker 4: because SvelteKit does that for you automatically
Speaker 4: so it's
Speaker 4: you win some, you lose some
Speaker 1: I guess
Speaker 3: that also means you could
Speaker 3: yeah, you could
Speaker 3: theoretically create a scenario
Speaker 3: that can't exist in real world
Speaker 3: maybe? For sure,
Speaker 4: oh yeah
Speaker 4: if you just put in the page and you ignore the layout
Speaker 4: but the layout would always be there
Speaker 4: then you have created a scenario that doesn't really
Speaker 4: exist in the application
Speaker 2: Yeah.
Speaker 2: So you just create a layout component and wrap it
Speaker 2: and everything kind of like React like you would have to.
Speaker 4: I
Speaker 2: mean, you just import the--
Speaker 5: You just import the layout component
Speaker 4: and then put it
Speaker 2: around.
Speaker 2: Yeah, that's what I mean.
Speaker 2: Yeah.
Speaker 4: Yeah.
Speaker 4: And if you're very curious about that,
Speaker 4: that's the video I did with Kevin two years ago or something.
Speaker 4: So I don't think much has changed since then,
Speaker 4: maybe even the syntax.
Speaker 1: Nice.
Speaker 1: All right.
Speaker 1: So Storybook has gotten faster, better, smaller?
Speaker 1: Faster and
Speaker 4: smaller.
Speaker 4: Storybook 9 was a lot smaller
Speaker 4: because we just spent like month and month
Speaker 4: of making it smaller with fewer dependencies,
Speaker 4: better dependencies.
Speaker 4: And then for Storybook 10, we're going ESM only,
Speaker 5: which is huge
Speaker 4: for us as maintainers.
Speaker 4: Yes.
Speaker 5: But it's
Speaker 4: also huge for users
Speaker 4: because users ran into a lot of issues like,
Speaker 4: oh, this is the CSS file that you really did not want.
Speaker 4: and we're just eliminating a huge chunk of bugs.
Speaker 4: It is a breaking change for a lot of people,
Speaker 4: but I think for the Svelte community,
Speaker 4: it's not so much a breaking change
Speaker 4: because everything is E-Sem only anyway in Svelte.
Speaker 4: So I
Speaker 2: wouldn't
Speaker 4: expect a lot of issues there.
Speaker 2: I have kind of
Speaker 4: a random
Speaker 2: question too.
Speaker 4: Good.
Speaker 2: So we have a very large icon library,
Speaker 2: like the entire material library.
Speaker 2: It's like over 2000 icons.
Speaker 2: And at first I was importing it and it was not tree shaking it very well.
Speaker 2: We have to import the direct file rather than the entire library.
Speaker 2: And Storybook, it will still even freeze up sometimes when there's a lot of icons on the page.
Speaker 5: Is there
Speaker 2: something I'm doing wrong there?
Speaker 2: Or does that need to be done in a different way?
Speaker 4: It's still in Stories only, right?
Speaker 4: You're not putting the icons in the manager UI, are you?
Speaker 2: The icons are in the components, not
Speaker 4: in Storybook,
Speaker 2: no.
Speaker 4: I mean, I don't know.
Speaker 4: I think so Storybook in that regard just does the same sort of bundling
Speaker 4: as your application would do.
Speaker 4: And so I would expect that the output would be the same as you should have.
Speaker 4: We do have some performance regressions that I'm fixing,
Speaker 4: which is essentially Storybook does some automatic code doc gen
Speaker 4: where we parse all your cell files,
Speaker 4: and then we see what are the props
Speaker 4: so you can have a nice props table and such.
Speaker 5: And right now we do
Speaker 4: that for all your cell components
Speaker 4: in your whole module graph.
Speaker 4: And so that means that you have 5,000 icons.
Speaker 2: Yeah.
Speaker 2: We'll
Speaker 4: parse all those icons, and that's a waste of time.
Speaker 4: So maybe that's what's happening,
Speaker 4: and then there's a way to disable that.
Speaker 4: But otherwise, I would still, even with the E18E community,
Speaker 4: also says it's like avoid the barrel files.
Speaker 4: Just import the components or the icons explicitly.
Speaker 6: Okay.
Speaker 4: Yeah,
Speaker 6: that's what we're doing.
Speaker 6: I just
Speaker 4: still
Speaker 6: have that sometimes.
Speaker 4: Yeah.
Speaker 4: I don't know.
Speaker 4: It could be the performance forgave I'm talking about.
Speaker 4: I think sometimes we'll auto import
Speaker 2: stuff and it will come.
Speaker 1: Over a podcast.
Speaker 4: Auto imports are sometimes annoying.
Speaker 4: That's true.
Speaker 2: Yeah.
Speaker 1: Any other questions for Jepa?
Speaker 1: Or do you have any other topics?
Speaker 1: Well, you asked
Speaker 4: what we're working on.
Speaker 4: And so I can also say that we readied our documentation for Svelte.
Speaker 4: Before it was just a readme in a repository.
Speaker 4: Now I have to put it in the official Storybook
Speaker 5: Docs.
Speaker 5: That's great.
Speaker 4: We also rewrote the, we have like an introduction tutorial for each framework.
Speaker 4: And we rewrote that from scratch.
Speaker 4: So it's Svelte 5, and so it's SvelteKit and such,
Speaker 4: and with the new Svelte CSF syntax.
Speaker 4: That's really important to us because that specific tutorial
Speaker 4: actually ranks pretty high in Google,
Speaker 4: so we have a lot of visitors there.
Speaker 4: Yeah.
Speaker 4: Oh, nice.
Speaker 4: Yeah, other than that, I mean,
Speaker 4: we rely heavily on snippets in the new Svelte 5 world,
Speaker 4: And that's great.
Speaker 4: I mean, snippets are great for Storybook.
Speaker 4: I don't know how much they're used outside of that use case,
Speaker 4: but in Storybook, it's an awesome API to leverage.
Speaker 4: So hopefully we can do that more in the future.
Speaker 1: Yeah.
Speaker 1: Snippets are such an improvement over slots,
Speaker 1: even just like an application developer.
Speaker 1: Right.
Speaker 1: So what, after Storybook 10, what can we expect?
Speaker 1: Is it going to get even better, faster, and smaller?
Speaker 1: Or is this secret?
Speaker 1: All of them, all the time.
Speaker 4: So we have a lot of, especially chromatic customers,
Speaker 4: but also Storybook users that are asking for better AI support.
Speaker 4: And you can have your opinions about AI and agents.
Speaker 4: I certainly have mine.
Speaker 4: But the matter of fact is that we want to give something
Speaker 4: to these users that are asking for it.
Speaker 4: And so we're building a few Storybook MCP servers,
Speaker 4: especially for design systems.
Speaker 4: So if you build your design system,
Speaker 4: then we'll make a tool that makes it easier
Speaker 4: for consumers of that design system to use it.
Speaker 4: So the agents will understand what is actually the components
Speaker 4: that it can use from the design system and such.
Speaker 4: Yeah.
Speaker 1: Nice.
Speaker 1: So this would interact then with some deployed storybook.
Speaker 4: Exactly, right.
Speaker 1: So
Speaker 4: the idea is that when you deploy a storybook,
Speaker 4: when you publish a storybook,
Speaker 4: it'll also publish some JSON files
Speaker 4: that includes all the information that you put in,
Speaker 4: like components and props,
Speaker 4: and maybe you have descriptions,
Speaker 4: and maybe you have like examples.
Speaker 4: And then the MCP server will pull from that information.
Speaker 4: So that's exciting.
Speaker 4: there's at least a lot of people that are excited about that
Speaker 4: but as we know there's also people that hate that
Speaker 4: and that's totally fine
Speaker 1: well I mean you don't have
Speaker 4: to use it
Speaker 4: if you don't want it
Speaker 4: exactly
Speaker 4: and the cool thing about this is that it's solely separated
Speaker 4: so because we have a lot of
Speaker 4: maybe Brittany can understand
Speaker 4: but we have a lot of design system users over the years
Speaker 4: that have been asking us
Speaker 4: can I please have this information that I put into Storybook
Speaker 4: can I get a way to get it out of Storybook again
Speaker 4: because you want to build your own documentation website
Speaker 4: or you want to I don't know whatever
Speaker 4: And so we're
Speaker 5: building that as part of this
Speaker 4: because we're now building these JSON files or these JSON endpoints that, well, you can consume them however you want.
Speaker 4: You don't have to use the MTP server.
Speaker 4: You can also just use them as information.
Speaker 2: That's cool.
Speaker 2: I actually just wanted a better way to document within Storybook because I wanted it to live in one place.
Speaker 2: I was building a separate documentation site at my last job, and that would have been useful.
Speaker 2: Yeah, like just pulling over the stories.
Speaker 2: I would just throw the storybook link in there if they wanted to go to the story.
Speaker 2: But then you're like, you're pulling props out again and like having to list all of those,
Speaker 2: all of your types are being listed out separately.
Speaker 2: Like it would be
Speaker 1: useful.
Speaker 1: And making sure that like, oh, you changed the component.
Speaker 2: Yeah, you got to change it in
Speaker 5: three different places.
Speaker 5: Yeah.
Speaker 1: Right, right, right.
Speaker 1: Exactly.
Speaker 1: Just bound to become a mess.
Speaker 1: So that's nice.
Speaker 1: So does that also mean that we can kind of almost build our own front end for storybook?
Speaker 1: sure just consuming the json files
Speaker 2: yeah uh
Speaker 1: i mean i guess you could already do that
Speaker 4: somehow
Speaker 4: but yeah well so so storybook does a lot of automated uh like we automatically extract
Speaker 4: the prop types from your components
Speaker 5: and put them
Speaker 4: in right and so so that information will be now
Speaker 4: available to you at runtime
Speaker 1: uh
Speaker 4: for anything right um you can also it's always been possible to
Speaker 4: embed stories as iframes.
Speaker 4: And so you could potentially combine this
Speaker 4: into whatever you want, right?
Speaker 4: Yeah.
Speaker 4: There's some really like the power users
Speaker 4: of design systems, they want their own UI.
Speaker 4: And that's totally fine.
Speaker 4: We're also working on, speaking of that,
Speaker 4: we're also working on improving
Speaker 4: the theming support of Storybook.
Speaker 4: So
Speaker 5: if you want to use
Speaker 4: Storybook as like the front for your company,
Speaker 4: then making it look great is also important for a lot of people
Speaker 4: or making it look like your brand.
Speaker 4: And the APIs we have for that now are okay.
Speaker 2: Yeah, it's kind of difficult now.
Speaker 4: And so we want to rely more on like the standards,
Speaker 4: CSS variables and whatever the web platform provides.
Speaker 2: You should see my storybook CSS file.
Speaker 2: It's hitting every specifier down the chain trying to get to the right thing.
Speaker 4: Yeah.
Speaker 2: That does not sound fun.
Speaker 2: No.
Speaker 4: So that's also been a requested feature for many of our power users for years
Speaker 4: that they can make it easier to make their storybook look however they want,
Speaker 4: like with dark theme and stuff.
Speaker 1: Yeah.
Speaker 2: cool
Speaker 1: that
Speaker 2: sounds exciting yeah
Speaker 1: all right so i think we are actually running out in
Speaker 1: running out of time britney you need to leave in six minutes i think four minutes
Speaker 5: i
Speaker 1: don't know
Speaker 1: something like that tight
Speaker 5: all right can
Speaker 1: we can we do unpopular opinions and picks before that
Speaker 1: i'm gonna skip my unpopular opinion does anyone have a short unpopular opinion
Speaker 4: I have one
Speaker 4: so I'm doing a lot of project planning
Speaker 4: lately, not just coding but also planning projects
Speaker 4: and I like GAM charts
Speaker 5: I like
Speaker 4: you know
Speaker 4: if you have a project and you have multiple
Speaker 4: team members, then everyone
Speaker 4: in their head has like, I have to do this task
Speaker 4: and then after that I do that task and then that task
Speaker 4: and for me, that lives
Speaker 4: inside my head, but when I put it on screen
Speaker 4: as a GAM chart, it's like this timeline
Speaker 4: chart. I can see, oh wow, this task
Speaker 4: completely is
Speaker 4: completely impossible to do. I have to move it over to
Speaker 4: that member instead.
Speaker 4: It appears that I'm the only one.
Speaker 5: Well, my old designer
Speaker 5: used to like them.
Speaker 4: Exactly.
Speaker 3: He liked drawing them.
Speaker 2: It was a good visual for people, I think.
Speaker 3: I have
Speaker 3: an opinion about an unpopular
Speaker 3: opinion, if that makes sense.
Speaker 3: My opinion is that
Speaker 3: there are certain CEOs have
Speaker 3: popular opinions right um and i think that my opinion on that that fact is that ultimately i'm
Speaker 3: quite happy um to see the way the community is responding to should we ditch swelts felt should
Speaker 3: we ditch react should we ditch next js whatever like the way the community is responding around
Speaker 3: these things is actually really positive and i've not seen much kind of like knee jerk yeah throw
Speaker 3: all the bins start with whatever else angular whatever's going on nowadays but you know it's
Speaker 3: it's been a bit more positive.
Speaker 3: It's been a bit more like, you know,
Speaker 3: Svelte is an independent project,
Speaker 3: direction is not defined, you know,
Speaker 3: it's all this kind of cool stuff,
Speaker 3: which is really heartwarming
Speaker 3: because it's usually the opposite.
Speaker 3: So that's my opinion.
Speaker 4: I agree. Fair enough.
Speaker 4: Yeah.
Speaker 4: I mean, the Svelte community in general
Speaker 4: is very heartwarming.
Speaker 4: I learned
Speaker 1: that in Barcelona.
Speaker 1: People
Speaker 4: are just so nice to each other.
Speaker 1: Yeah, it really is the best.
Speaker 1: I agree.
Speaker 1: All right. Picks? Anyone?
Speaker 1: I
pick... Can I go?
Speaker 1: Yeah, go for it.
Speaker 3: I pick Pennsylvania Castle.
Speaker 3: Not just because I'm in it, but it is really cool.
Speaker 3: It's really nice.
Speaker 3: A lot of castles you go to are kind of falling apart and cold and everything else.
Speaker 3: This castle is really plush and nice inside.
Speaker 3: There's lots of big old rooms.
Speaker 3: apparently Eisenhower and someone else, three very famous old president-type people,
Speaker 3: President Eisenhower is one of them, met in one of these rooms to discuss the invasion of,
Speaker 3: was it the Battle of Bastille? It was somewhere in France.
Speaker 3: My history is not wonderful, but they met in one of these rooms to decide to invade in
Speaker 5: historic times.
Speaker 3: So this
Speaker 5: castle's got
Speaker 3: quite a bit of a history behind it.
Speaker 3: But it's now also got a heated swimming pool, which is right behind me, which is awesome.
Speaker 3: And it's just cavernous and you can wander around.
Speaker 3: And there's a room that's in like, I mean, none of the listeners can see,
Speaker 3: but there's a room that's in the turret over there,
Speaker 3: which is a really cool round bedroom.
Speaker 3: And one of them's got an armoire that opens up full of clothes,
Speaker 3: like rotating doors and stuff.
Speaker 3: It's
Speaker 5: very cool.
Speaker 5: It's very cool.
Speaker 1: Sounds like a very modern kind of castle.
Speaker 3: Yeah, it's an ancient castle that's modern.
Speaker 3: It feels comfortable.
Speaker 3: I can't explain it yet.
Speaker 3: But everything inside is old.
Speaker 3: It's just well maintained.
Speaker 3: And Bianca hired all of it.
Speaker 3: We had the whole castle
Speaker 5: for the last four
Speaker 2: days.
Speaker 2: So we're just having like a retreat.
Speaker 2: Oh, my God.
Speaker 2: That's amazing.
Speaker 3: And it's been blazing sun apart from today.
Speaker 3: So we've been swimming in the sea, which is just
Speaker 5: incredible.
Speaker 3: Yeah, it's great.
Speaker 3: On that
Speaker 2: theme, I'm going to pick Spain because a lot of people like go into Europe.
Speaker 2: I mean, we don't hear very much like Spain is the place to go.
Speaker 2: But when we were there in Barcelona and then we traveled around Spain and it was just not just the history because you get that in all of Europe, but it's just so beautiful.
Speaker 2: There's so many castles.
Speaker 2: Every city was like its own culture and history.
Speaker 2: And it's just it's crazy.
Speaker 2: So I'll pick Spain.
Speaker 1: Good pick.
Speaker 4: Keep it.
Speaker 4: Still like Spain.
Speaker 4: I'll pick something more developing.
Speaker 4: I'll pick Truval.
Speaker 4: so tubal is this app for pairing like screen sharing you call your colleague and then you
Speaker 4: you pair and you share and it's just it has the best video quality it has the best
Speaker 1: uh like
Speaker 4: t-u-p-l-e dot app
Speaker 1: oh yeah yeah i think i've heard about this yeah it's
Speaker 4: amazing like it's just you
Speaker 4: don't have this lag that you get from from slack and you can type in each other's uh screens and
Speaker 4: whatever
Speaker 5: it's just it's
Speaker 4: really and they i think they built the whole streaming video from the
Speaker 4: ground up in some
Speaker 5: assembly
Speaker 4: language just to make it fast and it is super fast
Speaker 5: um is
Speaker 1: it is it tuple
Speaker 4: tuple maybe tuple like like two like a pair
Speaker 1: yes like the data structure well you're
Speaker 4: yeah
Speaker 1: like a data structure oh
Speaker 4: look who's like a native english speaker oh look at me i know words
Speaker 4: oh yeah
Speaker 4: anyways it's great
Speaker 4: I can really recommend
Speaker 4: I'm sure it's also cost stuff
Speaker 4: I don't know
Speaker 1: 30 bucks per user per month
Speaker 4: right it's really great
Speaker 4: we use
Speaker 1: it every day
Speaker 4: multiple hours a day
Speaker 1: I mean that is worth it
Speaker 3: for sure
Speaker 3: yeah if it works it's definitely worth it
Speaker 1: yeah alright
Speaker 1: and I think with that we are done
Speaker 1: because I don't have time for my pick
Speaker 1: So thanks everyone for listening.
Speaker 1: And thank you, Jephthah, for joining us.
Speaker 1: Even if it was a bit short, we can do another one that's longer later.
Speaker 2: Yeah, do a video one with
Speaker 7: you too.
Speaker 7: Yeah, we
Speaker 5: should do the video one.
Speaker 7: All right.
Speaker 7: And with that said, goodbye, everyone.
Speaker 7: Bye.
Speaker 5: Until next time.
Speaker 5: Bye.
Speaker 5: Bye-bye.
Speaker 5: Take care.
Speaker 7: Bye.
Speaker 7: I'll see you all.