Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast. Episode 362, Storybook with Daniel Williams.

Mazen Chami:

So Robin, did you watch the latest Artemis II stuff that happened recently?

Robin Heinze:

Obsessively.

Mazen Chami:

Obsessively. Okay. I—

Robin Heinze:

Obsessively watched.

Mazen Chami:

Oh wait, didn't you change your computer background to the rocket?

Robin Heinze:

Yeah. All my wallpapers are the moon pictures they sent back. I had the live stream going pretty much all the time. You could say I hyper-focused on it for 10 days, but yeah, I had a lot of fun. I love space. I love space and space travel and stuff. So yeah, I had a lot of fun following the mission. Did you watch it?

Mazen Chami:

I did. So I was off that week when they launched, and we took a little family trip. As soon as we arrived to where we were, I looked at the times like, oh, they're launching in an hour. So I put it on TV and we watched it while we were prepping dinner.

Robin Heinze:

Oh yeah. I watched it with my kids and they're like, "Oh my God, it's a rocket."

Mazen Chami:

Exactly. Same. Yeah. With my son. He was like, "Wait, so where are they going? The moon." Yeah. And that just opened up a conversation with a four-year-old about space travel and stuff. But no, that was great. And then I missed... Not that I didn't miss. I saw when the capsule was in the ocean right as—

Robin Heinze:

The splashdown is less. It's less exciting than the—

Mazen Chami:

Ones. You don't get to see the flames, right? Because it's like 3,000 degrees or something.

Robin Heinze:

No. Yeah. You kind of just see them coming down with the parachutes and then they're bobbing in the water for an hour before they're finally pulled—

Mazen Chami:

Out of the capsule. Someone gets there, starts opening it up, sort of thing. But yeah, I think when they reenter Earth, if there's all the flames you see in the movies and the cartoons, I think that people would watch that.

Robin Heinze:

Yeah, but they just don't have a camera. A camera's not going to be able to capture that because it's super hot.

Mazen Chami:

Well then why don't you just launch a camera close enough to capture it? Because then—

Robin Heinze:

That camera would be burning up if it was in the— Well,

Mazen Chami:

It could get far enough, right? You could just still zoom in. We have zoom. I can zoom on my iPhone.

Robin Heinze:

They're smart people. They'll figure it out.

Mazen Chami:

Exactly. Well, I wonder what SpaceX is thinking right now through all of this stuff too.

Robin Heinze:

I do know some SpaceX fans on Reddit were a little salty that everyone was super into this NASA mission.

Mazen Chami:

Yeah. Well, NASA and SpaceX use React Native, so we have to be nice to both of them. True.

Robin Heinze:

It's true. Space is cool all around.

Mazen Chami:

Well, as always, I'm Mazen. I'm your host. I'm a staff software engineer at Infinite Red, and I'm accompanied by Robin, my co-host. Hello. Director of engineering here at Infinite Red. And today we have Danny Williams with us. Welcome to the show, Danny.

Daniel Williams:

Hey, thanks for having me.

Mazen Chami:

Yeah. Well, before we begin, can you introduce yourself to our listeners?

Daniel Williams:

Sure. Yeah. So I'm Danny. I'm a senior React Native developer at CallStack, and I'm also the maintainer of React Native Storybook. A few other packages, something called Vite Plugin React Native Web. So that's React Native Web support for Vite. And also, I recently started taking over Repack, which is an alternative bundler for React Native. Other than that, I'm half English, half Brazilian. I live in Porto in Portugal. I'm into sci-fi and coffee.

Robin Heinze:

I love it.

Mazen Chami:

That's awesome. Sci-fi and coffee. Love it.

Robin Heinze:

This is maybe getting into the topic too much ahead of time, but does the Repack stuff and the Storybook stuff overlap? Do you find that being the Repack person is actually feeding into the Storybook stuff at all?

Daniel Williams:

Interesting. I mean, that's a good question. I think it will. I'm very much at the beginning.

I joined CallStack back in December, and before then I got to know the CallStack guys when I went to React Conf and I met the Repack maintainer there and we got to talking a lot, and I got a lot more interested in it since then. And it just so happened that I started taking on some of the work on maintaining Repack recently. And what I've done so far really is I've added a Storybook plugin for Repack and just started to look for the issues and stuff. So I'm not that deep into it, but I think that it will in some ways. In other ways, not really at all, because the bundler world is quite different from other types of libraries or building apps or design systems. There is overlap because there is a lot of stuff with Storybook where it involves bundler configuration and doing clever things with that.

One of the main features nowadays with Storybook is that it can automatically import all your story files. You used to have to import them all manually, and now there's this require context thing that the Expo team pushed in to help with Expo Router, and that made it like there's a lot more of these sort of bundler features that you rely on now in Storybook. So there's definitely some overlap.

Robin Heinze:

Well, spoiler alert, we'll get into that a little bit more, I'm sure, but we should probably hear from our sponsor.

Mazen Chami:

Well, before we do that, for our listeners, if you haven't heard, Repack is basically an alternative to Metro. So if you're looking for something other than Metro, Repack is the other solution out there. But yes, before we get into our topic, let's hear from our sponsor. Infinite Red is a premier React Native consultancy located fully remote in the US. We're a team of 30 senior-plus level React Native developers and support staff, and have been doing this for over a decade. If you're looking for React Native expertise for your next project, hit us up at infinite.red/radio. Don't forget to mention that you heard about us through the React Native Radio podcast. And also, as you probably mentioned, Chain React is coming again this summer, July 30th to 31st, and the 29th will be workshops also if you sign up for that. Get your tickets at chainreactconf.com.

And I'm sure if you listen to future episodes, we might have some coupon codes going out there, or even just on Twitter. I know I'll be making a special announcement by the time this episode comes out, you'll know what I mean by that.

Robin Heinze:

Come see us in Portland.

Mazen Chami:

Yeah. Just pack your bags. Let's do this. Well, let's do it. Let's get into today's topic. As we teased earlier, we're going to talk to Danny about Storybook and all the latest stuff that's going to come into Storybook, specifically Storybook 10, because I feel like that's a big jump that you all did and improvement on Storybook, and we'll kind of dig into everything that's happened since then. So let's rewind a little bit, Danny. For our listeners who haven't heard of Storybook before, what's your elevator pitch for it?

Daniel Williams:

Storybook is a toolkit for building UI components, and it's also a really extendable toolkit. So there are all kinds of ways that you can use Storybook. But I think the main one is building out your design system

and having a place where you can see all of your components together, and there's a documentation component to that, whether it's just having them all listed in one place or if the actual documentation features of Storybook. And so you can really take it quite far because there are all kinds of add-ons that extend the functionality. You can even bring in a Figma plugin that shows you the design. And it gets a bit more complicated when we start to talk about, okay, well, how does React Native Storybook fit into that? But React Native Storybook is almost like an extension of that, but it's also separate in the sense that the web Storybook works quite differently. It spins up its own web server and runs on its own in some ways. But

Robin Heinze:

The goal is largely the same.

Daniel Williams:

Yeah, exactly. And there's just limitations with how React Native works where you have to rethink how Storybook works.

Robin Heinze:

I've used Storybook for a long time. I've probably several versions behind what's the latest and greatest, but it is really useful for showing the implementation of your design system because obviously your designers have the complete design system, like how everything works in Figma, but it's all theoretical until you actually have a component built in React Native that does all the things that it's supposed to do. And Storybook is like, "Hey, here's the actual component in the app." And it's like a demonstration of how it works with all its different configurations and whatever, but it goes from the theoretical to the actual.

Daniel Williams:

Yeah, exactly. And I think that's an interesting point to hit on as well, which is that sometimes it's quite difficult to collaborate with designers without... Let's say you make a component that was specced in Figma and then you want to show them the component, and sometimes your component's nested in their app somewhere and you can't really—

Robin Heinze:

Get it. And it's only doing one permutation of its props and it's hard to... Yeah, Storybook is really, really useful for that.

Daniel Williams:

Yeah. So you'll have all these different states that can be really difficult to recreate. And sometimes you create a component, or you might want to create a component before you then go ahead and use it in a bunch of places. And what you end up doing is making your own sandbox for displaying the component and its different states, and then you're sort of messing around with it in real time. And what you end up doing is almost like recreating your own Storybook. The Storybook is kind of for that purpose. It's for many purposes. It's for sharing your design system, it's for developing your components, and it's also for testing in a lot of ways. I mean, at the web more so, because it actually has a testing framework now built into Storybook. It uses Vitest browser mode. But even in terms of React Native, you can still get a lot of what testing does for you.

I think for UI, when you do unit tests, it's a lot of just like, oh, I set the color to red and then the style prop is red. And that's completely pointless. I've always hated those kinds of unit tests. I think that Storybook is a much better way of being like, "Oh, it's actually red because I can see that it's red." And that's what you actually care about.

Mazen Chami:

And you're hinting at visual regression testing too. Yeah. I think we'll get into that a little bit more because I know testing specifically is something that people overlook when it comes to Storybook, because people are like, "Oh, Storybook, my design system. And hopefully you have a design system. If you don't, please do." And it's just your way to show your design system to product, to designers, and be like, "Hey, did I miss anything?"

Robin Heinze:

And to help you develop your building components. Yes. You put it in Storybook, and as you add stuff, you're watching the Storybook before you even put your component in a screen, you're using it—

Mazen Chami:

To— You're saving yourself a lot of time as you're developing too. If your designers are disciplined in using the component name and the props that they set out in the design system, and you can replicate that in React Native, building is just going to be like Lego blocks, I guess. Speaking of every parent here where you're doing Legos every night, it's just like Lego. You just put A and B together and all of a sudden you have your car, I mean your app.

Daniel Williams:

Yeah. It's—

Mazen Chami:

Interesting.

Daniel Williams:

I think now as well with Figma, Figma has some newer features like the variables and stuff, and

you can almost... In a way, there's a lot of the stuff that you get in Storybook in Figma to some degree where you can change the variables in real time, but obviously that doesn't translate to your actual code base. But what that does is it means that you can have your designers almost on the same page where they're thinking about the different properties and variables. And then now with AI tooling and Figma MCP, a lot of that can really translate over really well. And I kind of see that as a future of the way people develop with Storybook is going to be more and more that integration with the design tools, where a lot of the work is going to be setting up your variables and stuff correctly in Figma, that kind of thing. And then you're just setting up a sort of pipeline, a workflow with Claude or whatever, where it can really take those variables and it knows your design system and sort of spans out and just creates your component and all its states and things.

I can sort of picture that in the future.

Mazen Chami:

Cool. Yeah. I think while we're talking about testing, I think let's just continue on this topic for a second because I have a couple of questions to ask you. As the maintainer of Storybook from a React Native capacity, how would you set up your, let's say, let's start with something I hope—me saying simple, this is simple—but how would you set up some sort of visual regression testing with Storybook?

Daniel Williams:

Yeah, so there are multiple facets to this. I would say for React Native, there's not one correct way right now. I mean, I have in mind some ways that I would do it, but when you look at the web, there are some really well-defined solutions like Chromatic, which is the company that's really behind the maintenance of Storybook, especially on the website. Chromatic is a solution that is visual regression testing for web, and it's very much sort of plug and play. If you have Storybook set up, it's just going to work. And that's possible because you can do a lot more with bundlers on the web and you don't have to think about all the different devices and stuff that you have to target. You have to think about different browsers, but browsers nowadays, they're very easy to run headless browsers and you can spin up whatever you want in there.

With React Native, you're thinking about like, oh, which device do I want to run my Storybook on? You're—

Robin Heinze:

Getting into device farms and it gets complicated quickly.

Daniel Williams:

Yeah. And so to answer that question, I would just use the tools that people already use for testing. And Maestro historically hasn't had visual testing, but they recently added a solution for taking screenshots. And one of the things that is built into React Native Storybook that isn't really built into the web yet is that you can control your React Native Storybook remotely with web sockets, and there's also an option to use REST. So you can just remotely control your Storybook, and then you can imagine, especially if you're doing Detox or Appium, you can just call fetch on the Storybook endpoint and just set the story and then take a screenshot, and you would just use the tools that you would already use to do screenshot testing for React Native Storybook. But mini teaser is that there is going to be a more official solution pretty soon, but it's kind of not something I can really get into the details of at this point because I'm not really working on it, but I know that is underway basically.

Robin Heinze:

Oh,

Mazen Chami:

Okay. I know personally, speaking with clients who are always asking about visual regression testing, that's something that is untapped in React Native because like you mentioned, we have web, you have one browser, you can just open it, expand it, shrink it, and you can almost get what you need out of that small, simple interaction. With mobile, we're talking about iOS, Android. And then within that we're talking about pixel densities, lower-end devices, tablets, foldables. I mean, I could keep going, and that just unlocks a lot with not just the testing of your components, but the visual aspect. What happens to your app when you open it up on a foldable device? Are you going to test that with Storybook and then get a test from that? So it opens up a large can of worms, and to hear that there's potentially a solution coming down the line, that's pretty exciting.

I know it's something that I personally want to try out.

Daniel Williams:

Yeah, I'm pretty excited about it as well. I mean, over the years, I've made a lot of examples and I've been working towards something that can just work with existing tooling, but it always just feels kind of lacking because I don't think that there is much focus on visual testing. I mean, we saw Owl come out a while back. I don't know if you guys... Yeah, you probably heard of it. So basically it's fine, but it didn't really work that well for me. I tried setting it up in some new Expo projects and couldn't quite get it to work the way I wanted. And I've tried doing it with Detox, but they basically tell you, "Oh, go off and make your own thing." So it's like, what's the point then? You're not going to offer it. Then we may as well build our own thing essentially, and I've done some of that work, but now essentially that's being taken on by Chromatic.

I think I can tell you that, but Chromatic will have their solution for React Native. Maybe I'll check with them if I can actually share that. But yeah, we'll have an official visual testing solution, and I think it's going to be, in the beginning, maybe not the perfect solution, but I think anything is going to be good because what we have right now just doesn't really check all the boxes like you would want it to.

Mazen Chami:

Yeah. And I remember there was a tool that I was very excited about, Percy. They were also planning to do visual regression testing or visual testing in general, which included regression. I know they're still around, but I think they're just mainly web. And actually, I think at Chain React 2019, I believe they announced that they're starting work on Percy for React Native, but I don't know where that ended up and hoped— Seven

Robin Heinze:

Years ago.

Mazen Chami:

Yeah.

Daniel Williams:

I mean, they should get in touch.

Mazen Chami:

Yeah. Well, they should reach out if they're working on React Native and stuff, and that would be very helpful. But yes, kind of to end off on your point, Danny, you and I will sit down on React Native Live soon, in about June, I believe, where we get to show some of this stuff off. So hopefully we can answer some questions that our listeners might have based around that. So coming back to your latest release, version 10, that just dropped, what should people be most excited about with version 10 and what's come out of it?

Daniel Williams:

I guess it depends. Are we talking just Storybook in general, or?

Robin Heinze:

I would say Storybook in general, but also Storybook React Native.

Daniel Williams:

Okay. Yeah. I think for Storybook in general, there's been a lot of work, to be honest, with Storybook to slim things down and to cut the fat and make it faster. And that work just keeps moving forward. I think in version 10, there was a 30% bundle size reduction, and a lot of that was just removing CJS, so CommonJS. And that actually ends up being an improvement for React Native Storybook as well, because you had to do all these hacks to make sure that it would resolve the right bundle that you wanted. And now it's just like, okay, well, it just has to work with the ESM, and

Mazen Chami:

That

Daniel Williams:

Kind of simplifies the things in the process. But it also means that we have to make sure that everything is being handled in terms of ESM. And if you know anything about the ESM and CJS trade-offs, you've probably run into a million different problems with like, "Oh, my TypeScript config doesn't work with... It doesn't let me put TS extensions." So I mean, that's been mostly a maintenance thing, but it's really just slimming down Storybook, making it more modern. And I think that's been a problem or a complaint that people have had with Storybook because it's just, "Oh, it's too bloated." And I think that argument, people could still make that argument potentially, but I think it's hard to make that argument anymore because there's been so much work put into the performance and to the bundle size, and you have that, I think it's like E18, the performance guys, the web performance guy, there's a group that works on performance.

So they've gotten involved with Storybook and replaced pieces of it. Lodash has become ES Toolkit, and all those sort of slimming-down things where, okay, this is the modern version,

and let's use more of the browser built-ins and all that kind of thing. So that's been one large part of it, is just making the fundamentals better. And then there was this old mocking feature. So it's kind of the second iteration actually of mocking in Storybook. And mocking is pretty important if you want to do bigger pieces in Storybook, and that's become a lot better in the latest version where it just kind of works seamlessly. I think it's based on the Vitest mocking. So if you're familiar with that, it's the same thing basically. And it's really nice if you have a big Storybook and you're showing screens, which especially on the web is, I think, a solid use case that people underutilize where you can really get your screens into specific states, right?

Robin Heinze:

Right. I imagine a lot of people had trouble with things like mocking and said, "Well, no, we'll just keep it to the dumb components and not do it with screens," but it's really cool that it's possible.

Daniel Williams:

Yeah, I think that it's also the most obvious use case for Storybook is design systems. So I think that that's always the first thought, but I think it just sort of expands out of there. I think sometimes you end up with multiple Storybooks. People have really crazy setups with Storybook. I had one at a previous job where we had a Storybook in our app where we'd do the screens, and we'd have a Storybook on our design system, and that was the components on their

Robin Heinze:

Own. Right. I would never have thought of having multiple Storybooks, but it makes so much sense because you're like, okay, this is the Storybook, literally a book. This is the Storybook that's about the design system. But then there's this other Storybook that's about the integration basically

Daniel Williams:

Of

Robin Heinze:

Screens and stuff.

Daniel Williams:

Exactly. And I mean, Storybook is so flexible and extensible that you can do all these things. Right.

Robin Heinze:

It's a

Daniel Williams:

Tool.

Robin Heinze:

It's a palette. You can

Daniel Williams:

Use it

Robin Heinze:

For—

Daniel Williams:

You can even put multiple Storybooks into one. There's a Storybook Connect feature or something. I can't remember the exact name, but you can have multiple Storybooks inside one Storybook. So yeah, it gets kind of crazy. And then I guess another one of those new features in Storybook 10, getting back to that—I keep getting sidetracked. So there's a new syntax for stories basically called CSF Next, or it's CSF Factories. The name's changed a couple of times, but it's basically a new, more type-safe version of the Storybook stories syntax, and that's going to be really interesting. Not fully supported on React Native yet, but I have it in PR, and there are just some weird things to figure out before it's fully supported. So hopefully version 11 will have that working. I mean, right now it's in previews, so kind of safe for the moment, but yeah, I think that one's a pretty cool one as well.

The other one is we've got React Server Components testing in Storybook, which I think is actually one of the most interesting solutions I've seen for, or maybe the only solution I've seen for testing with React Server Components, because it's kind of complex to do because you need a sort of end-to-end test.

Robin Heinze:

Right. It was

Daniel Williams:

Like

Robin Heinze:

You have to have a server.

Daniel Williams:

Right. And that's where it's really

Robin Heinze:

Smart. Or like a mocked server somehow.

Daniel Williams:

Exactly. And in this version of React Server Component testing, it runs in the browser. So there's a server in your browser that serves the server components in the table. So wait, the—

Robin Heinze:

Browser on the device or the browser on your dev machine?

Daniel Williams:

So this is specifically for the web. There's basically— I don't know the full details of how everything works because that's been, I think it's Casper that's been working on that, and he's a super smart guy, much smarter than me. We

Robin Heinze:

Had him on the show just a couple weeks ago. Yeah. Oh,

Daniel Williams:

Nice. Yeah. I mean, I don't know the internals of it, but I just know that it sounded really cool when they showed me. Yeah. So that one's really cool, and there's a new testing syntax, but a lot of those things are web-specific. In React Native version 10, the main thing was basically just making it easier to strip Storybook from the bundle and a simpler... There's a wrapper function you put around the Metro config.

Robin Heinze:

Because what I remember is, because I've been using Storybook since forever ago. But what I remember is I had to go into App.js and change a variable that's like, "Is Storybook true or false?" So I take it it's a little bit more...

Daniel Williams:

It's still getting better, let's just say. It's always been a kind of complicated question because I think for React Native specifically, it has generally been better to just have a separate app for Storybook. And I think that's something that people maybe don't realize they could do, or maybe you don't want to do it because you don't have a monorepo. So that's, I think, probably the better way. In the web, it makes a lot more sense to have, or you can just have a Storybook next to your code because it will just spin up its own web thing and none of that's going to get into a bundle, and it's more straightforward. But in React Native, it's like, oh, well, Metro doesn't really do tree shaking and it doesn't really do anything fancy with bundling. I mean, there's some cool stuff that's getting there now with— I think Evan and team are pushing really hard to make Metro better.

This is one of those things where I get excited about things like Repack because I think we need more modern bundling for React Native.

Robin Heinze:

So I guess that's why I was curious with you working on Repack and also Storyback— Storybook—is there opportunities for Repack to be Storybook-first, really good at Storybook integration in particular, maybe more so than Metro and maybe...

Daniel Williams:

Definitely easier than doing it with Metro, I would say. I think this is one of those things where over time I think I'm going to see the solution and it's going to evolve out of different pieces of things. There's a lot of what's happened in Storybook as well. It's like you figure out one little thing and then another thing over here, and then suddenly all the pieces come together and you're like, oh, well, if I just did that, that's what I'm hoping for. I think over time that could be a really cool solution, especially Repack is the micro frontend bundler for React Native. So that's the main selling point, is that you can use Module Federation and have different teams working on fully separate parts of your app, which is a really interesting concept. It's a lot more used on the web, but being able to do that in React Native unlocks a lot of things for bigger teams.

If you have 10 teams and they're all trying to merge, you probably have a queue of 10 people waiting to see if they can merge today, and then they don't get to because the CI takes an hour to run. That whole process, you can just sidestep it, and that's what's pretty interesting, I think, about it.

Robin Heinze:

Mazen knows a lot about waiting on CI to be able to merge PRs recently.

Mazen Chami:

Yeah, that's been a huge issue with my current app. And I think just to mention on that, I've always pushed my clients to have multiple apps, one specifically for Storybook, which gets shared to just the designers. So you have a smaller scope where you don't have to go through all the device IDs, UDID collections when it comes to iOS and then doing all that. So it's always nice to do it where you're not only just doing— or like to call your atoms, your small stuff, like your text component, your button component and all that—but then also doing larger compositions. Let's say you're talking about an e-commerce app, your item row, you actually show a lot. You get into much—

Robin Heinze:

More business logic specific.

Mazen Chami:

Yes. Yeah. And then like you mentioned there, Danny, if you're able to combine all that into a monorepo that uses something like Mock Service Worker, if you're using that on your mobile side. I'm giving away the architecture of the app, kind of thing. We had Mock Service Worker handling all that, which we— As

Robin Heinze:

Sometimes we don't say which client it is.

Mazen Chami:

Exactly. So it was two apps all in a monorepo where the design system was its own quote-unquote package that got bundled there, and it kind of handled it that way. So it worked for us, and I think once we got to production, we decided to just drop Storybook and then just come down to a single repo. That was a large pull request before we went live. We had a full regression test go off of that. But our reasoning for doing that was no new components are going to come out of this. And if any new components did come out of it, new features that we were building, they would be feature-flagged and then enabled specifically for specific people to validate and go from there.

Daniel Williams:

Yeah. I mean, I know firsthand that Storybook isn't always the best fit. And a lot of the time you'll find is, like Storybook, you'll be using it a lot at the beginning of the project until you reach a certain level of maturity.

Mazen Chami:

Yes.

Daniel Williams:

And then unless you have a full design system team, it starts to dwindle because a lot of the work that you were doing then, it just set you up for everything else. Yes. And then as long as it does its job up until the point where you don't need it anymore, then we're happy, basically. I think there's still ways to bring it into the workflow, but every team works differently and I totally get it. There are projects where I've just not used Storybook even as the maintainer where I'm like, well, when I need it, I'll bring it in, kind of thing. Sometimes it's too big of a—

Robin Heinze:

Hammer and you mix it.

Daniel Williams:

Yeah, exactly. I mean, I've had thoughts about a Storybook light version in the past. I get these ideas sometimes and I never end up going all the way. Maybe now with all this AI stuff, I'll end up doing it. But I think there's potentially room for a way-simplified version of Storybook where it's literally just like, oh, look for all the files in this folder and render out the default view of them. And you could just not have any of those dependencies, just have a scroll view or something. And that could be something you could really basically— really simple thing you could just build into your app, maybe even just do a custom thing. And sometimes that's enough.

And it's really when you start having more complex use cases where you're like, "Oh, well, I actually definitely need Storybook." Or maybe from the beginning, you know that it's going to evolve in a certain way and then you're like, "Oh, I need Storybook because we're going to have to collaborate with designers, or we have multiple teams that are all going to use the same design system." Sometimes you have a big company where they'll have four different apps using the same design system, and that Storybook's never going away because there needs to be some way of testing those in isolation. So there are all kinds of different setups, right?

Mazen Chami:

Yeah. And I think what you mentioned there about a scroll view that has all your components, that screams to me Ignite, our boilerplate. We have a demo showroom that pretty much does that. It's literally

Robin Heinze:

ScrollView with—

Mazen Chami:

Every component, every iteration of components of it. And our objective there was Ignite is supposed to be small, and we weren't going to make a decision on whether to use Storybook or not because not all our clients use Storybook. It's our battle-tested boilerplate where we use it on most of our clients. We can have a discussion around whether to include it or not. But yeah, that's one avenue. At the end of the day, all this requires maintenance, and that's potentially a high burden for clients to allocate time to. The design team might be screaming for it, but then the product team will be like, "I'll put that in the backlog for you guys." But I want to also just be cognizant— we're getting close to time, but I want to bring us back to another release that you did right after 10, which was 10.3.

That big addition was the addition of MCP server for AI agents. Can you explain how that kind of enables development and what it would look like for day-to-day flow for a developer?

Daniel Williams:

Yeah. So I think nowadays, I think we're all developing in this new way where, well, still everything's evolving, right? Sometimes you're not sure if next week you're still going to be using the same flow because maybe some new model's coming out next week. And the funny thing about Storybook MCP is that it started getting worked on when MCP was the big hotness at the time, and then it was skills. And I think MCP will have a comeback, to be honest. But yeah, it's funny, the developer world right now, because everything is a bit up in the air. But I do think that we are adapting to a new workflow as developers, which is going to be: how do I give my agent the context it needs? And it's always about context, but it's also about giving the right context. And I think the problem that you can have, let's say for example, I'm developing an app and I'm on the login screen, and I just need to add a... I'm going to add a new state for the input component.

And this is the same old thing with Storybook: oh, I need to add an error state, and it's really annoying for me to get to this screen and then add the error state. And it's the same with a model. If you screenshot a whole screen and say, "Oh, look at my login screen. I need an error state for this input component." It's basically telling the random number generator what you want and hoping that it generates the right number.

And that's where I think that Storybook can fit in in an interesting way in workflows going forward where you can say, okay, let's say we bring up our design system app, maybe we're in our separate app that's just the Storybook, and we go to the input story, or we tell the agent, go to my— let's go and add a component—and it'll know because you've given it instructions that you're using Storybook and you've got the MCP there, so it knows that it can look at all your components that you have in your design system. And then it will say, okay, we need to look at this input component. And then for that input component, it can get the potential props that it has available, the different states that we have in our stories, and also any documentation that you've added there will be fed to the agent.

And then so you can sort of pinpoint the specific thing that you're interested in, and not only you but your agent, and in that way you don't get the whole screen anymore. If you're trying to just do that one input, you can target it specifically at what you're trying to do. And if you are using something alongside that with Figma, Figma MCP for example, and you're saying, "Oh, here's the Figma link, here's our Storybook," you could even give it the story name. And then I think the vision there really is to say, "Well, just look what we have, look what's in Figma and just fill in the gaps, and it'll just go away. You walk off, have your coffee, come back, and you've got a design system fully working." Crazy

Robin Heinze:

World that we're living in.

Daniel Williams:

And then you bring in the CallStack Incubator project, Agent Device—then me shilling CallStack a moment, basically—and then look at it on the device itself. I think that's where these things get really interesting, is when you combine all the different tools. You've got the React DevTools CLI, the Agent Device CLI, and then all of those things together, your device,

it's completely visible now to the agent. And I think Storybook's just fitting in there as another layer on that, which is like, oh, send me to just that story so I can screenshot just the input. Something like React Native Storybook as well has the ability to turn off all the Storybook UI, and because it has this ability to be controlled externally, you can turn off all the UI and just have your agent completely control Storybook, go to the story that you care about, try to have it create that error state. It can control the Storybook, it can fill in the props that are missing, all of those things. I think there's probably still work to do. Maybe we need skills to tie these things together, but I think it's going to evolve, especially now that the community's getting ahold of it, and we'll see what other workflows spin out of that.

But I think it's the seed of a new type of workflow with design systems, and hopefully it's going to be really useful to anyone who's using Storybook now. And it's available in React Native Storybook out of the box on 10.3. You have to enable it. So maybe out of the box isn't the right way of putting it, but if you just enable it, it will start up— It's in the box. You just have

Robin Heinze:

To turn it off.

Daniel Williams:

Yeah, exactly. You just turn that on, and part of the functionality of the React Native Storybook, like Metro wrapper, is there's a web socket server that runs there and a REST server, which is a recent thing. And that's what sort of powers all this. With an MCP server, you need some sort of way of receiving the request from the agent. So it's basically just been added on there to that server, and it just becomes a part of Storybook and how it works.

Mazen Chami:

Yeah, that's pretty cool. I think, like you mentioned, the day and age that we're in, this is something that people are leaning more towards to help them get their flows.

Robin Heinze:

Right. They want their agents to be able to do everything that they would've done as a human, which includes like, "Hey, I have a design system in Figma and Storybook. Set up, make them match." And so yeah, your agent has to be able to talk to all your tools.

Daniel Williams:

Exactly.

Robin Heinze:

So you teased some stuff coming up in the future that you can't talk about yet. So where should our listeners go follow, pay attention to in order to be the first to know about the secrets that you've got coming?

Daniel Williams:

Yeah, I know. I think follow on Twitter, basically me, the Storybook guys, the Storybook accounts, not just Twitter, LinkedIn if you're not a fan of Twitter. I know if it wasn't the place where all the devs go, I might not be on Twitter, to be honest. The fact

Robin Heinze:

That

Daniel Williams:

We're

Robin Heinze:

Still calling it Twitter however many years later says all you need to know.

Daniel Williams:

Exactly. There's no way I can't—

Robin Heinze:

I know. I will never call it that. Never. Exactly. It's always Twitter.

Daniel Williams:

But yeah, I mean, it will be coming up.

Mazen Chami:

What is your Twitter handle?

Daniel Williams:

Yeah, my Twitter handle, it's kind of an awkward one. I didn't get a good one. Basically it's Danny__W.

Mazen Chami:

Awesome. Yeah. So hopefully our listeners can follow along there and kind of see what you all are working on. And I do know the Storybook Twitter, at least that's where I listen. I heard about the version 10. So that's also an active one that our listeners can go to. Well, unfortunately, I think we're at time here. Danny, I really appreciate— thanks for coming onto the show. This was enlightening.

Robin Heinze:

Makes me want to go try Storybook 10.

Mazen Chami:

Yeah. Give it a go. Oh,

Daniel Williams:

Thank you.

Mazen Chami:

Yeah.

Daniel Williams:

Yeah, it's been really good fun. Thanks for having me on. I was wondering, can I shout out one thing? Would that be okay? So

basically, I'm living here in Porto, and I started a community here in Porto for React Native developers, and we're going to have a... I don't know when this is coming out, but we're having our next meetup in June. I think it's June 11th. I can confirm that later, but basically there's a meetup page. If you're following me, you'll be able to find that through Twitter as well. It's called, on Twitter, it's React Native OPO, like OPO. And there you'll see that we have a new event coming up, and if anyone's in Porto or surrounding areas, then show up. And if anyone wants to speak, we're also looking for speakers, so that'd be cool.

Robin Heinze:

Oh yeah, we will put links to both of those, the Twitter and the Meetup page, in the show notes.

Daniel Williams:

Awesome. Appreciate it.

Robin Heinze:

So go to Danny's meetup.

Daniel Williams:

Thank

Mazen Chami:

You. Yeah. Thanks again, Danny. So that's it for our episode. Robin, to send us off, do you have a mom joke? Oh,

Robin Heinze:

I have a good one. Darren posted this in our Slack. I have a horse named Mayo. Mayo neighs.

Mazen Chami:

Yeah, I saw that one coming. Because

Robin Heinze:

He's a horse? Okay.

Mazen Chami:

Okay. Yeah, I get it. That's a good one. Okay.

Daniel Williams:

Nice.

Mazen Chami:

Awesome. Well, thank you all. See you all next time.

Robin Heinze:

All right. Bye.

Jed Bartausky:

As always, thanks to our editors, Todd Werth, Tyler Williams, and Jed Bartausky, our marketing and episode release coordinator, Justin Huskey, and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze, and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.