901: JS News: New React & Svelte APIs, RSC Updates, Redwood and Storybook

Scott and Wes break down the latest in JavaScript news, including new async patterns in Svelte, React Server Component tooling with Parcel, and Redwood’s push into Cloudflare with its new SDK. They also cover what’s new in Storybook 9 Beta, from visual testing to a sleeker, lighter build. Show Notes 00:00 Welcome to Syntax! 02:50 Brought to you by Sentry.io. 03:37 Syntax Meetup! 04:09 React View Transitions. 08:58 addTransitionType. 11:18 Activity API. Offscreen Renamed to Activity. 14:22 Maintaining state in search queries. 16:29 Asynchronous Svelte. Playground. 19:04 Svelte Boundary. 25:13 Parcel RSC. 27:15 Redwood SDK. 30:55 Storybook 9 Beta. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. We are in the 900s, 901. Yes. I guess if we did zero-based indexing and normal-based counting, 900 was officially entering the 900s, but we're past that barrier now, 100. And guess what? There's been a massive amount of JavaScript news. Just a little bit ago, there's been all kinds of new updates to both React, Svelte, and all kinds of stuff. So we're going to be talking about what's been going on in the web dev world, from new React APIs to new Svelte APIs, React Server Components, Redwood JS, Storybook, and more. So, as always, my name is Scott Tolinski, and with me, as always, is Wes Boss. What's up, Wes?

• 0:43Wes Bos?

  Yeah. It's so funny because the React Server Component stuff. So we did a show saying, like, where are we at with React Server Components? And we recorded it and went off, and like, before it dropped, there was two major updates to React Server Components, which quite honestly shakes up the whole story of not a ton of people supporting it. And it's just like, ah, that always happens to us. Same with the Payment episode. We were talking about Stripe. And like, two days before the Payment episode dropped, they announced that now they charge you when somebody, regardless of if you win a chargeback or not, they're still charging you 15 bucks, which is ridiculous.

• 1:28Wes Bos?

  So there's always something new that pops up, which is, we try to record them like a week, week and a half ahead of Vance. It's not too far, but there's always something new popping up.

• 1:37Scott Tolinski?

  Yeah, it's down-stoppin'. Even, man, I just heard about another like, payment system that I hadn't really heard about. It functions along the lines of like Lemon Squeezy or whatever, where you are, like Lemon Squeezy is the merchant of record, yeah.

• 1:53Wes Bos?

  Yeah.

• 1:54Scott Tolinski?

  I couldn't even find it. Polar? Have you heard of Polar?

• 1:58Wes Bos?

  Polar?

• 1:59Scott Tolinski?

  Yeah, dot S H, polar dot S H.

• 2:02Wes Bos?

  I believe, yeah, I believe I did see this, which is a payment infrastructure for the 21st century, the modern way to sell your SaaS and digital products. All right, what's the pricing immediately? 4% plus 40 cents per transaction. Immediately I am out.

• 2:20Scott Tolinski?

  Yeah.

• 2:21Wes Bos?

  That's the problem with, with a lot of these things is you're not gonna get any cheaper than Stripe unless somebody literally builds another payment processor.

• 2:31Scott Tolinski?

  I think the benefit here is strictly that they are the merchant of record, right? You know, like that is the sell there. It's like, yes, you're paying and now you don't have to deal with all kinds of complications.

• 2:41Wes Bos?

  Well, lemon squeezy went up to like 10% or something like that. So I guess if you're looking for that, then yeah, man, this is, that's a, that's a good deal.

• 2:49Scott Tolinski?

  Woof. Also, also, big woof if your site is not functioning well, because you have no excuses for that, especially with something like Sentry out here in the world. Sentry can make sure your app is functioning great, whether that's your cron jobs, collecting user feedback, getting alerts for all kinds of things, or even uptime monitoring, or heck, if your pages are slow or fast, you get user misery score if they're buggy. You get access to all of the errors that are existing on your, your site. In fact, there's always going to be errors because let's say, you know, we're not perfect. And if you're not perfect like me, you'll want a tool like Sentry to make sure you can fix your issues. So head on over to Sentry dot I L forward slash syntax, sign up and get two months for free.

• 3:31Scott Tolinski?

  Use the coupon code TASTY TREAT, all lowercase, all one word. This podcast presented by Sentry.

• 3:37Wes Bos?

  One more thing, real quick. May 29th, Denver, Colorado, we're doing a syntax meetup. You gotta be there if you're anywhere within a horse ride of Denver, Colorado. We got the folks from Vercel, the folks from Mux, folks from Sentry. We're all coming out, of course. We're gonna have Scott there, CJ is gonna be there, I'm gonna be there. It's gonna be a really great time. If you want to grab some tickets, they're free, but you gotta get tickets. Go to syntax.fm forward slash meetup.

• 4:09Scott Tolinski?

  Alright, let's get into it with the first item on the docket today, which was React released in a blog post about experimental features in React. Now, I had heard that there was some stuff brewing on the animation side in React. It was presented as like no other framework has animation features quite like this. I don't know about that, but this is giving you a nice, smooth way of using view transitions in React, as well as another new API called Activity. So, let's talk about these both. First and foremost, these are experimental, so to use them, you have to opt in to React @experimental, but it brings through two new APIs for view transitions and one for rendering.

• 4:53Scott Tolinski?

  So, viewTransition is a element that will wrap, I guess a component, that will wrap your components to make view transitions easier within React. And then addTransitionType is a function that lets you specify the reason for a transition, just to give you a little bit more control. But if you haven't been using view transitions, they're a really well-supported browser API that allows for awesome animation features transitioning in your app. And a lot of people get this wrong, where they think it's just for when you change pages, but in reality, anytime you're doing any state change on your application, you can wrap it in a view transition, and it can either interpolate that transition, or you can write custom CSS to do that transition.

• 5:37Scott Tolinski?

  It's just an incredible API. I love this thing.

• 5:40Wes Bos?

  It's kind of like a tween. You can tween between one state to another. So, if you can think of, yeah, there's a lot of things in CSS you can transition from, but if you literally wanted to transition from a dog to a cat, you could. And where that's really useful is, like, you could do it with CSS Grid. If you're changing what the grid looks like, you can do it for sliding panels back and forth, when you're not necessarily changing the... The URL, there's, there's a lot you can do with it and it's extremely powerful API. All you really have to do is just say like start transition.

• 6:20Wes Bos?

  And then when the DOM is updated, the old DOM and the new DOM will just be tweened between each other and or the old element and the new element.

• 6:31Scott Tolinski?

  Big fan. The best part about this API for me is that by default, just by calling, you know, the start transition, or in this case with React, by wrapping your components in a view transition component.

• 6:44Wes Bos?

  Yeah.

• 6:44Scott Tolinski?

  Just by doing that bit, you get a really basic fade animation, which honestly is like such a great default functionality, just to have a basic fade animation as being the default. You don't even have to write anything other than, hey, do this transition and you get a fade. And then to get that tween, you do need to give your transition a name. So that way it has like a name. Those are called shared element transitions because what you're doing is you're saying, hey, this one thing on the page is the same as this one thing on this other page, even if they're not the same. But what they'll do is they'll tween between the two and you, we're actually sharing our screen. So if you're watching on video, you can see exactly how that looks within this animation and how you're able to do that.

• 7:30Scott Tolinski?

  In this React API, you're specifying a name with a unique identifier. That's the same as a name with a unique identifier on the other page or element. And in HTML CSS land, this is done with CSS property. In this API, it's being done with a prop on the view transition.

• 7:50Wes Bos?

  Important to note as well, that in order to trigger these, it doesn't just trigger on, on any update. You do have to fire off either a start transition, use deferred value, or a suspense that's resolving. So if you have a suspended component that's showing like a loader state, and then it, and then it resolves, it will transition between the two of those. So it's kind of nice. I like that React seems. To be putting a lot of these things in as first party implementations, because that means that you don't have to bring in some some plugin for it. And then it, but it also means that if you're using a third party component,

• 8:35Wes Bos?

  those components can fire off transitions. And then if you want to take advantage of those components that are transitioning, then you can just wrap it in a view transition yourself. So I hope that this lands in stable, but certainly go and try it for your application right now. So we can get feedback on what the API looks like.

• 8:57Scott Tolinski?

  Yeah, and it's neat, too. There's also this add transition type function, which we mentioned, where you you can then basically say this this transition is a like their example that they have here is like, let's say you navigate forward or navigate back. That way you can have like on iOS, when you click into something, it like moves over to the one side on in, and then moves out to the other side on out, right? Because you're then able to specify a specific animation for navigating forward or navigating backwards, because you've now given that a name. And then you can write your custom CSS for each of those animations, which is really great to have. That's a nice thing to have, because it is always kind of weird when you have just like the same animation on in and out,

• 9:42Scott Tolinski?

  especially if that animation is like, let's zoom in. And now you're like, let's zoom in again on the way out, you know? So it's always important to know like that that feels kind of natural in the way you're doing it. Now, the one thing I want to say is that the reason why this is necessary, if you're wondering why, it's mostly because of the virtual DOM, right? Is that is that like why these are needed? Because in most of the DOM forward frameworks, you just use the straight up JavaScript. Is that accurate to say that you think?

• 10:11Wes Bos?

  Um, I don't think so.

• 10:14Scott Tolinski?

  You think these are just helpers, really?

• 10:16Wes Bos?

  You want to be able to specify. The, the direction and name what is happening. Cause like, like go to syntax.fm and show the, like, the number that gets bigger and smaller as you click through.

• 10:31Scott Tolinski?

  Well, that's a, what's it called? That's a shared element transition, which will, those will always work forward and backwards, no matter what.

• 10:38Wes Bos?

  Oh, yeah.

• 10:38Scott Tolinski?

  Yeah.

• 10:39Wes Bos?

  I don't know if that, if it's necessarily a, I don't think it is something to do with the virtual DOM. Maybe it is. We'll have to, we'll have to play with it.

• 10:47Scott Tolinski?

  Yeah, I know. It's one of those things where, um, my apologies, folks. My React, my React is a little rusty, but I am stoked that these are in here specifically because this isn't going to add a ton of JavaScript to your app to do these transitions. You're not having to add a library to do the interpolation between your elements. That's all being handled by the browser. The amount of code here is simply just the, the wrapping elements and the functions that you need here rather than anything to handle the animations themselves, which we gotta love. The next API that they introduced in this experimental, uh, release here is the Activity API. It's an, it's another component.

• 11:28Scott Tolinski?

  And Activity is kind of interesting because what it does is it basically allows you to pre-render a component without having it be visible. And it's interesting that there is a non-Boolean flag for this, which, um, David K. Piano, gotta be very stoked about this. He hates Boolean APIs. So it's basically an Activity element with a mode prop. Um, and that mode prop can either accept a visible or a hidden value where visible allows it to be just rendered as normally, where hidden is going to, uh, keep the component unmounted, but, uh, save its state and continue to render at a lower priority than anything

• 12:13Scott Tolinski?

  visible on the screen. Basically, it's preheating your elements for you. So that way, if you have already loaded it, then it like kind of stays loaded. Or if you are going to load it, then that way it's going to like make that transition for when it actually shows up to be, uh, very fast. So, um, so it says that you can use the Activity to save parts of the UI that the user isn't using or pre-render parts that a user is likely to use next.

• 12:40Wes Bos?

  Yeah, that, for example, like, maybe we should say, like, why would you possibly ever want this? So if, if you have like tabs and you want to be able to hide and show content, you kind of have two options. First, you can just not render them. And then when somebody clicks a button, you can go ahead and render those. And then the other option is you can simply just hide them with CSS. And that might also not be what you want. You might want to, because if you're hiding them with CSS, you may not be getting all, all of the benefits. And you also are firing off things like effects, which you might not want.

• 13:21Wes Bos?

  Because you, you want your effect to run when the component is, is mounted, right? But if you're pre-rendering it, should it, should it also run the effect? Maybe, maybe not, depends, right? If you're like auto playing some, some video, you probably don't want that.

• 13:40Scott Tolinski?

  Well, this is, it does not, by the way, the activity.

• 13:42Wes Bos?

  Yes, it does not do that type of thing. So this, this is the ability to, I guess, a third way to get in there. And it also is more performance. So I guess React will figure out, it will deprioritize the, the rendering. So I, I don't know, like, I, I guess if you have something that is absolutely massive and it does take quite a bit of rendering, this could certainly speed you up. But like, I don't know that I have a ton of parts in my application that are, are like sluggish enough that I would need to do something like this, but certainly there, there can be.

• 14:22Scott Tolinski?

  Here's a very practical use case here. And the React blog post, they did a really good job of kind of saying, here's a really interesting use case for this, why you might want this. So they have a listing page, on that listing page is a search box. And then there's a detail page, right? They're using the view transitions to show a detail page. These are completely separate components. So this is a different component and this is a different component. And what you do is, let's say I type in, in the search bar first.

• 14:52Scott Tolinski?

  And then I transition to the last or to the detailed page. Now, keep in mind, the listing page is now unmounted, or it's not visible, right? But it is wrapped in an activity, so the state is preserved. So when I go back, the state is preserved and the search box that's there still has the value in it.

• 15:11Wes Bos?

  Oh, yeah.

• 15:12Scott Tolinski?

  So it's like maintaining that state that the user had. And in my view, this is a great user experience. Uh, and like one of those things that will drive you absolutely nuts if you're using an app. Now that said, there's tons of other ways to get by this by one, having the search box outside of that, like in the layout.

• 15:32Wes Bos?

  That sucks when you have to like change it, or you have to use like an external state management that like maintains it.

• 15:38Scott Tolinski?

  I do like external state regardless, uh, but hey, this is, this is not bad. And, and I think this will make many React apps feel nicer if people actually use it, so.

• 15:49Wes Bos?

  Totally. Plus, like, there's that, again, there's that benefit of you can use a component that you can npm install it and that component doesn't necessarily need to know about what your state management is uh, in order to maintain that type of thing. Cause all of these updates are like really nice. They're just adding more features in. Same with React Server Components is standardizing these features so that hopefully one day we get to a point where the interop between all of these um, third-party components will be much nicer.

• 16:22Scott Tolinski?

  Yeah, pretty sick. Uh, big fan of this. Uh, shout out to the React team. I think these are some great little uh, updates here.

• 16:29Wes Bos?

  Kind of on the same idea here, we have a proposal in Svelte, or maybe not even a proposal. There's, it's certainly, a lot of it has been coded as well, is the idea of asynchronous Svelte. And this is actually kind of exciting. We've talked about this quite a bit where I said, my one gripe with Svelte is that you can't load your data at a component level. You always have to do it in, you always had to do it at like a page level, right? And this, I believe, I'll let Scott take it from here as he's a bit more of the Svelte guy. But this, I think, will solve that. One of my main gripes with Svelte.

• 17:08Scott Tolinski?

  Yeah, it will absolutely solve that because this isn't saying anything about Svelte Kit here. This is a Svelte API, so this is not tied to the meta framework. This is tied to the actual like front end framework. And it basically is just like, oh yeah, if you use this new version of Svelte with async enabled, you can now use the await keyword inside of the script tag at the top of a Svelte component, inside of a derived, which is just like a way to derive state from other state in your markup in general.

• 17:42Wes Bos?

  It's an await inside the template tag, which is wild.

• 17:47Scott Tolinski?

  It's wild. So this is Svelte's answer to React Suspense, to Suspense in Solid, to Suspense in View. And they're not, they're not calling it suspense, which is, which is fine by me because I don't like, we already have words for sus- like for suspending, like it's async await or async or whatever people on YouTube say we're saying it wrong. You know what? That's gotta be one of the most confusing comments we get often is async or async. I don't even know what these people are saying. Like which one is the right one and which is the wrong one? They're all fine. Acing, async, it's the exact same. It's, there's such no difference between those two words. That's such a, like a regional pronunciation thing, but people are like, you're saying it wrong.

• 18:32Scott Tolinski?

  Like what? What are you talking about?

• 18:36Wes Bos?

  But like, the idea here is that you can have a component that has some asynchronous work in it, whether that is something that fetches data, whether that's something that just takes a little bit of time to compute. You'll be able to wrap a boundary around those components and show a, like a loading or pending state, right? Or a suspended state as the rest of us would understand it.

• 19:04Scott Tolinski?

  Yeah. So I'm scrolling all over this blog post, but yes, there is a, I'm trying to find the boundary specifically. Yeah, there's a new Svelte boundary because Svelte uses boundary for like errors and things like that, but you can now use pending inside of Svelte boundary to have it when it is loading. I do find this to be really wild where you can, yeah, you can just straight up await inside of your template tags, like await preload for an image, await on a function inside of a list item here in the template tag. It all looks nice. And I gotta say, the cool thing that I do love about this framework and one of the reasons why I am such a diehard fanboy of this framework is when you look at the

• 19:46Scott Tolinski?

  requirements section here, the very first one, minimal ceremony. We just want to write code using the await keyword, avoid framework-specific APIs and idioms to the extent possible. I gotta tell you, when like React introduced their suspense, they had start transition, use transition, all this stuff. And I get the functionality behind that, but like, there's all these names now, like, and you have to know that transition in a start transition for suspense, not related to view transitions, which is another thing they just added. So it's like, all right, now we have view transitions, but they can be, but inherently, they're not specifically.

• 20:27Scott Tolinski?

  So start transition, use transition suspense, like all these words are just there to replace words that we already had, which I don't know, it's fine. It's fine for me, but like, I like that there is minimal ceremony.

• 20:41Wes Bos?

  Sounds like it's not fine for you, Scott. It sounds like it's not. But no, I agree. I agree as well. Like, there's a lot of the React stuff is like, oh, it's, it's kind of like this, but there's, there's some gotchas. And you can't do X, Y, and Z, but like, Svelte's like, no, we just, we just want to be able to put in a weight inside of a Component.

• 21:02Scott Tolinski?

  Script tag and component.

• 21:03Wes Bos?

  Yeah, all that stuff. Component has a boundary around it at a higher level, then you can access that with a pending, new pending state. And you can show if it is pending. And then there's a whole bunch of work around doing stuff concurrently, which is really important because like whenever I talk about like, I just want to do my data fetching in the component. Everybody comes out and says, well, that's how you get waterfalls.

• 21:30Scott Tolinski?

  Right.

• 21:30Wes Bos?

  Uh, meaning that you have, you have one component, that component loads, oh, that component needs data. It goes off, fetches data, comes back. Oh, the data comes back now it needs to, that needs to render another one. And then that component loads and that needs to go do something right. And then you get these, these crazy waterfalls where one thing triggers another, which is why a lot of these frameworks have like sort of hard armed us into, no, no, no, do your, do your data fetching and loaders at a page level. So at least when you load a page, you can understand what's going on there. So they will do as much work as possible with concurrency. This, I think in every framework, this can be a bit of a foot gun.

• 22:12Wes Bos?

  You just have to be cognizant that you could possibly cause some performance issues with your, your application.

• 22:18Scott Tolinski?

  Yeah, I, I agree. I do, I'm, I'm just stoked to see this in here. And, and I, I think there is some discussion whether or not they will eventually need some API for orchestrating things like start transition. So, you know, maybe I'm speaking a little too soon on some of that stuff. But in the same regard, I think it's going to have better defaults. So you don't have to use those things. It is, it does say parallel by default. Since expressions in a template can be safely assumed to be pure, sequential await expressions need not result in sequential async work. Similarly, asynchronous work in two sibling components should happen simultaneously. So because they're a compiler, I think they can, you know,

• 23:01Scott Tolinski?

  you can just write your code as you would want to write it and not have to worry too much about that. But again, it seems like if you're deriving a value that's awaiting on a derived value, that's awaiting on a derived value.

• 23:11Wes Bos?

  Yeah.

• 23:11Scott Tolinski?

  I think there's no way to avoid a waterfall in that way.

• 23:14Wes Bos?

  One thing I did not see in here is anything about like form actions, meaning being able to call server functions from the client. I don't know, is that going to be something that that is is worked in here? Because again, right now, another thing you have to do is you have to put all of your actions at a page level, which makes makes no sense to me because your action is almost always tied to the component. Like, what does this thing do when it is clicked or submitted or whatever? I shouldn't have to like, put that on the page where whatever page it's going to live in. I just want to be able to pop a newsletter subscription function on the component and for it to just work.

• 23:57Scott Tolinski?

  I I actually agree, and it does say very specifically that like, they would like to use this API to replace things like all data loading within SvelteKit. Basically, today, we cannot reuse much code between server and client portions of SvelteKit. We rely on a lot of virtual models and generated code for historical reasons, but basically it's saying it's plausible. There's a lot of new interesting possibilities. We find ourselves drifting away from primitives like load, which I would assume that would also entail things like actions, considering that's the same concept of having to go to the server for data. So that's under the improving SvelteKit part of things where

• 24:38Scott Tolinski?

  basically you'd have to assume that this eventually would lead to better communication between the client and the server now that we don't have to, yeah. Like now that, yeah, you wouldn't be beholden necessarily to having it at a page level. So, pretty dope. There's a little playground where you can go and test it out today. You can give feedback. There is a branch you can try it on, but they are. There's a lot of discussion around it, whether or not you need things like start transition, etc., etc. But, uh, pretty dope. I'm, uh, I'm stoked for this one. Can't wait.

• 25:13Wes Bos?

  Next up, we have Parcel announced React Server Component in beta. I knew that they were working on this and I forgot to mention it in the React Server Components, but there was really nothing that you could use. But now it's in beta and this is kind of exciting because the thing about doing React Server Components is like both your client and your server needs to know about your entire application and you need something that can like transpile JSX on the server. So if your server is written in Hanno or Express

• 25:53Wes Bos?

  or whatever, you need some sort of integration to that to sort of mate them together. So Parcel's released React Server Component support. It's both a package you could just import on your server as well as part of the bundler. And this is pretty exciting. It's just another good example of someone that can use React Server Components. I think this is going to be big for anybody that's on an existing stack that doesn't necessarily want, you can't move to NextJS, can't move your entire application NextJS, but you want to use React Server Components. There's not a great option for that right now. So I think that this is going to really improve things.

• 26:36Scott Tolinski?

  Yeah. Yeah, we had a lot of people mention Parcel with React Server Components when we dropped our React Server Components episode, which I've always loved Parcel. So to hear that there's been like so many people being like, "Parcel!," it makes me feel good. I like that. Shout out to the Parcel, Devin and everybody at Parcel. Is there anybody else at Parcel?

• 26:58Wes Bos?

  Just Devin. Devin's holding up like 80% of the React ecosystem with, he's got Parcel

• 27:05Scott Tolinski?

  Lightning CSS.

• 27:06Wes Bos?

  Lightning CSS and React, Aria and man, all the way down.

• 27:13Scott Tolinski?

  Yeah, I love it. What a guy.

• 27:15Wes Bos?

  And then like a day or two later, Redwood. So Redwood is or was a

• 27:22Wes Bos?

  Kind of like a full stack framework for building applications in Node.js and React with GraphQL. So it had like a, like an ORM. And basically, every, all the time, we're asking like, where's the Laravel for JavaScript? And, and everybody says, uh, Redwood is that? Redwood is that, right? And then it looks like they're taking a bit of a pivot away from that. I think that it's, over the years, it never really got much uptake, unfortunately. And they've announced that Redwood is now Redwood GraphQL. So they've sort of moved the existing,

• 28:03Wes Bos?

  you built your app on it to Redwood GraphQL with all the ORM. And now Redwood SDK is being branded as a React Framework for Cloudflare, which is absolutely a wild pivot and something I'm honestly quite excited about. So what it is, is a VEIT plugin that allows you to use React Server Components and Form Actions and all of the stuff that we know about React Server Components. It allows you to use it with VEIT. And it's sort of like tuned for deploying to Cloudflare.

• 28:45Wes Bos?

  So you get tight integration with D1, which is their database. You don't have to use these things, by the way. This is just a, it's sort of like, I think maybe that was the problem with the original Redwood is that they very prescriptive. And as much as we say we want, we want things to be prescriptive. We want it to be the way that we want it. So this is just like, yes. So by default, you can get D1 and R2, which is things for like hosting, like, like files, images, stuff like that, durable objects, queues, has middleware, has some auth stuff built in. But it is just a VEIT plugin with Wrangler installed by default.

• 29:29Wes Bos?

  And, and then the VEIT plugin is probably the most impressive part because doing React Server Components with VEIT is not, not easy. I think, I think Waku is the only other one at the time that, that does this.

• 29:44Scott Tolinski?

  Waku.

• 29:44Wes Bos?

  So this is kind of exciting. Waku, I can't say it wrong every single time.

• 29:49Scott Tolinski?

  async, async, Waku, Waku. Yeah.

• 29:52Wes Bos?

  So this is cool. I think, I don't know, I think it was, it's an interesting pivot. And it's also just like another huge win for Veet as well.

• 30:03Scott Tolinski?

  How many wins can they stack up for real?

• 30:06Wes Bos?

  Publishing React to Cloudflare is, is getting easier and easier. Cause like I've, I've gone through the whole gamut of it, right? I did NextJS on Pages. Then they've moved it to open NextJS for Cloudflare, which is using NextJS on Cloudflare workers. It's pretty good, but still a little bit of a pain. They're literally just monkey patching the NextJS webpack output, which is, that's, that's a whole thing. And then I moved to Waku, which is multiple Veet builds. And now we have this, this redwood, which is, I'm assuming it's using the environment API in Veet,

• 30:49Wes Bos?

  which is new, to do both server and client Veet.

• 30:53Scott Tolinski?

  Dope.

• 30:54Wes Bos?

  Pretty sweet. Yes.

• 30:55Scott Tolinski?

  Yeah. The last one that we're going to be talking about today is that Storybook 9 entered beta in April 24th. And we started using Storybook on the new Cintex site, which there's, you know, Storybook is interesting. Because it does everything in an iframe, you know, if your components rely on.

• 31:15Wes Bos?

  Sir, can you explain what Storybook is for real quick for anyone who hasn't heard it?

• 31:20Scott Tolinski?

  Storybook is a place to develop your components in isolation, which allows you to essentially render an individual or even like chain of components, and then pass in mocked data. And therefore you can build your component in a little sandbox where you can make sure that this thing will fit all the specifications. And then you can change it with different data, see how it reacts, longer titles, longer this, change the image, all that stuff. And you can build out your entire component library outside of the bigger application. So that way, when you dump your stuff in the bigger application, it, you're playing with Legos, right? Which is a great way, because sometimes when we're working.

• 32:05Scott Tolinski?

  In a bigger project, or a project in general, we can build things that are really tightly coupled, one, but two like-

• 32:13Wes Bos?

  Too tightly coupled.

• 32:14Scott Tolinski?

  Yeah, possibly be relying on stuff outside of here, or stuff outside of here, and you might not recognize it until you're trying to use these things more flexibly. So, flexibly, flexably. Flex, I don't even know if that's a word. With flex. Yeah, so Storybook 9 has a number of really enticing updates. So I'll be updating to this because I'm a beta user all the time. But what does this add? It adds component test, wow, what is component test? Which, I don't even know what that is. It adds interaction testing, accessibility testing, visual testing, test coverage in general. It's a 48% lighter bundle, tag-based organization, and React native support.

• 32:59Scott Tolinski?

  So, oh, the testing widget is basically one that lets you run your tests. It's a widget for running tests. But the thing I like most about this testing feature, so you can have your integration tests inside of Storybook now in a visual manner, à la Cypress, or was it Playwright is the other one?

• 33:17Wes Bos?

  Yeah, yeah, Playwright. So Playwright is like both like a headless browser, like Puppeteer, but then it also has some utilities for running your tests, either headful or headless.

• 33:30Scott Tolinski?

  Yes, okay. So we have that. We have accessibility testing, which is a perfect fit for something like this. It now will complain about accessibility issues within your components, which, gotta love that. Anything we can, especially when you're there building, right? It's always great to, one thing I really like about the Polypane browser is it's just there when you're building. So to have this here when you're building, if you're building in Storybook, really nice. Visual testing. You could now visual regression test to make sure that your components don't get, like, let's say I changed some global CSS here, and it now affects a component here in a negative way. You're going to be alerted to that with a visual regression test.

• 34:15Scott Tolinski?

  I gotta say- Visual regression testing is one of those things that I've always looked at as being way more pain than it's worth. But if you can have it within isolation, to me, that makes so much more sense because you have a page, you have an individual component, whatever, on a page, all of those things change all the time, right? But when you have these things in micro-isolation with sandbox data or with mocked data, it shouldn't change unless you know it's going to change. So the fact that you have so much control over all the information coming in and all that stuff means that like I now could be confident if this is visually saying, hey, something goofed up here, that it's actually worth my time. So visual regression

• 35:00Scott Tolinski?

  testing, I've never been a fan. I'm gonna use it. I'm gonna straight up use it. Yeah.

• 35:05Wes Bos?

  That's nicer to do, I think, at a component level than, like, in the past, I've used it on like an entire page. And there's just so many things that could possibly nudge it left or right, you know, a little browser quirks or a little piece of text that is longer than the other. And it is just like a too much of a pain, too many like false positives, right? But I could imagine as part of your like, component test, right? Your components should not change anything about how they look unless you explicitly approve that. So I think that's great.

• 35:43Scott Tolinski?

  Yeah, I'm gonna use it. I've never thought I would say I would use visual regression testing, but we will add it. There's also a test coverage screen now, so you can see which components are tested and how much of these components have test coverage. Test coverage to me is one of those things that it's nice to have, but like, I don't know if I need it, but it's nice to have. I think one of the coolest things about this update for me is this 48% lighter, but it's not just that it's smaller in size. They have an image, and we're sharing our screen here, of the dependency graph before and after. And some of this has just been like, A result of the ecosystem, building packages that reference packages that reference packages, etc., until you're using

• 36:27Scott Tolinski?

  an isEven package somewhere. And there's been a bit of a resurgence in using packages that have no dependencies or small dependency graphs. And I gotta say, if you're comparing these two dependency graphs that I'm showing on the screen right now, nothing makes me happier than this. I am a spring cleaning kind of guy. I love picking up the stuff and putting it in where it should go and look at this and look at that.

• 36:54Wes Bos?

  I want to know what they actually did, though. Like.

• 36:58Scott Tolinski?

  There's a bit of a thread on Twitter. I think some of it is replacing common packages that had many dependencies with packages that, again, are primarily built to be a single dependency package.

• 37:12Wes Bos?

  Did they just bundle it into a a single package?

• 37:16Scott Tolinski?

  There's been a huge push for that in the Svelte ecosystem as well, where they've been rewriting common packages to use no dependencies. So there has been a bit of a push in my ecosystem.

• 37:30Wes Bos?

  As well.

• 37:30Scott Tolinski?

  Yeah. Lastly here, well, not lastly, there's two more things. The tag-based organization. You can now tag your stuff and filter by those tags, just a quality of life thing. And then React Native support. Cool. I'm not using React Native, but happy these folks have React Native support inside of Storybook. So shout out to all the teams releasing cool stuff. This is all great. I don't have nothing to complain about here. I think if the thing I complain about the most is naming of React APIs, then that's pretty good. I'm gonna do that anyway, so.

• 38:05Wes Bos?

  Yeah, that's great. Awesome, yeah, tons of stuff, tons of new updates. We haven't really done a news show very often, but it feels like just the updates just keep on coming. It's fun to be able to talk about what's been going on. Let us know down below in the comments if you have any thoughts on any of this stuff, if you're going to be using any of it, especially the React server components. I'd love to hear your thoughts on that.

• 38:29Scott Tolinski?

  Yeah. We'll catch you next time.

• 38:32Wes Bos?

  Peace.