Mini Ep 52623
===

EMily: [00:00:00] happy Friday developers. Today is May 26th, 2023, and welcome back to our Roundup episode where you can catch up on episodes you missed, or get a quick rundown of the past two weeks in between meetings. So let's get started. 

Last Wednesday we welcomed on Lee Robinson vp, a developer experience at Versace to talk about his experience there and talk about the recent Versace ship week that happened earlier in May, where Versace introduced a slew of new tools and features. In this clip, Lee talks about next J S's app router and how developers can utilize it.

Lee Robinson: The key thing here is how do you invest years of research and development time into. A new platform for the framework without leaving the community behind. This is the core challenge. You don't want everyone to feel like, well, 13.4 came out, all my stuff is old. I either gotta update or you know, I'm out of luck.[00:01:00] 

And this was something we really thought super deeply about. Because we didn't want to have a moment where the community felt divided on, oh, I have to move to this new way, or I'm gonna, you know, have some trouble. So a core principle here with the app router is that it's designed to be incrementally adoptable.

And we actually recommend people do it this way versus a one large PR to move your entire app over from the pages router to the app router. And because of that, both of the pages and app router can kind of harmoniously live together in your application. This is what we're doing at Versace right now too.

It also helps signal this message to the community that I think is really important, which is the page's router isn't going anywhere. There's many, many applications live in production today that are relying on it that will still want updates, and we're still adding new features there as well too. So I'm really excited about that as like the core framing of getting people on board of like, okay, why would I even consider this?

Now the challenge and the interesting part is my goal is to convince folks that the app router is worth [00:02:00] checking out and trying out and incrementally adopting to. Because there's some really, really exciting stuff. I think the biggest one for me, Is a simplified programming model. In our keynote video, we basically said it was like bringing the best parts of PHP Rub on rails and react into next js, there were some really fantastic things about those tools that. We want to have that same type of experience. When you get down to the details, that's where you start to see the power of the architecture that React has been building out with server components and suspense.

You can kind of think of the app router as one of the first places that is combining. A lot of the architecture direction that React has laid out into a framework that folks can get their hands on today and start building with. And I say first because I don't believe it will be the last. I think we are helping build out this architecture.

With the React community at large. And I'm really hopeful [00:03:00] some of the initial work done by frameworks like Gatsby, , some community members have also started building their own server components, frameworks. I'm sure this is gonna continue to pick up in the future, but the router in the framework is the key of what brings all of these pieces together.

So I'm very excited to see the community's reaction to all of this, and hopefully they enjoy the programming model of just writing Async Await. In my component to fetch data and layouts being a primitive, that is just composing react components. There's no specific next JS api. You're just. Passing in the child of a rat component, I think that's gonna be the thing that's very exciting about the new direction of n gs and the deep integration with not only fetching data, but also mutating data with server actions., 

EMily: we also had on Tim Kins last week, who's the co-author and lead for Next JS at Versace to talk about what's new in Njs 13.4. Including talking about the chatter around React server components.

Tejas: Next, [00:04:00] JS 13.4 introduces some new features. I think the most popular feature, the most discussed, the most controversial. And sometimes the most misunderstood feature is the use of React server components. I've heard a lot of people honestly divided on these. Some love it because, oh, that's fantastic. That means everything's getting smaller.

We're shipping less code because a lot of the computation is done on the server, and we only ship minimal rendered components over the network. Also, it improves the data fetching store. You can have async components that execute. Only on the server, but I've also heard a ton of criticism where people say, oh my God, this really conflates my mental model because now I have to think about which component is which.

And also context. A lot of people complain about server context, client context, et cetera. I'm curious if you could speak to that. 

Tim: Yeah, that makes sense so the thing is like in the next year as a community, like server components wasn't really a thing that people ask for a lot per se.

It was mostly layout streaming, suspense boundaries, not waiting on get service props to get results and things like that. So it's really [00:05:00] like there's these very large amount of issues and feature requests that are now solved by changing the underlying architecture of Nexuses. That's been our main goal with this.

It's like solving the actual problems that people have a lot in Nexuses apps today. So one of these is. This layout thing, , like we could have added layouts into pages, but it would've been less ideal than what you get today. The server components part is basically taking this gears of nexus, having server side, , integration.

So, , the good example here is you had gut server or props, got static props get set parts, and all these next shift specific APIs. And these kind of influenced the React team in a way where they were like, yeah, this server side thing, like we kind of proved that works, but in the end, it's not the best DX or like not the best way to compose your component.

It's not a way to compose your components, right? Like you're doing it separately from your componentry. What if we move [00:06:00] all of this data fetching logic and rendering logic that is not needed on in the browser, per se. So structural things in her page, for example. And move all that rendering to the server and solve many other problems in the current ecosystem around React.

One of them is, , we're shipping a lot of JavaScript to the browser. Everyone will say React is quite big, but if you start looking into real apps, it's like React is quite big, but then it's still only a 10% of your whole app or something like that. And with server components, we're basically shifting this back to.

React is quite big still. Unfortunately, we have some plans to get to a point where that's better, but that takes a lot of effort and time to develop a smaller bundle size basically. But now we don't have this client side code Bit that you are introducing yourself. If I write an access app. I'm going to pull in all these libraries stuff to format my currency or do internationalization or do data [00:07:00] fetching or all these libraries that you're using because a few years ago, MPM published at like 90% or so of your code is actually not your code, but someone else's code.

You pull entry mpm. And in practice that's like pulling in all these libraries to then do all this functionality for you, but you're also shipping into the browser and like with server components. Sure. Shifting that away to the server, which has the bundle obviously, but then it does other benefits as well, like it's closer to your database or it has lower latency to your database or your , APIs.

And this allows you to do data fetching in your components, cuz then if your database queries are less than a few milliseconds, then. You can just keep rendering components through the data fetching there and get the result out, send a result to the browser, which is what server components does, and then hydrate that without the actual need for all the a static bits in that.

You can still have dynamic pieces where you get client components, like if you used to react before server components. [00:08:00] That's basically like any component. Yeah It's really exciting to see like where people will take this cuz it allows you for way more.

Granularity and like what you're sending to the browser, but also it now allows you to decide between like, I want to render this component or this other component, and it could be separate bundles, for example. You get way more granular code splitting by default as well

EMily: And finally, Mark Erickson Redux, maintainer, and Redux Toolkit Creator came on again to talk about what the upcoming release of Redux Toolkit 2.0 will include.

Mark: We have a few different goals for 2.01 is that we want to try to have quote unquote correct ES module, common js. Packaging, which is both an annoyingly nebulous and seemingly continually changing goal. , being able to correctly import redux toolkit under node with ES module flags turned on. Another is we wanna modernize the JavaScript build output and we've always been transing our code, so it would work outta the box [00:09:00] in i E 11.

Elevens dead. We want to stop supporting it, and that'll help shrink bundle sizes a little bit. Oh, nice. Another is that we have accumulated a number of APIs or options that we've deprecated, and it's time for those to go away, which is technically breaking changes. We do have a few new features we're working on.

And along with that, we actually converted the Redux core library to type script back in 2019, and then it sat in our master branch for three plus years and never got released. So it's time for that to actually get published. And along with that, we are making some tweaks to the types in both the core and R T K to try to be a little more, slightly more correct behavior.

noel: Is that redux, like 4.2 to five is type script in that? 

Mark: Yeah. There's no meaningful functionality changes. Uh, but the difference is we went from JavaScript source code. With a handwritten type definitions, file [00:10:00] to type script, source code, and generating the type definitions along with tweaks to those types.

noel: Back to rtk. I saw Alpha one was like beginning of this year. Now you're on five. What's that timeline looking like? What are you looking out for? What are your signals? 

Mark: I don't know when, when it's done, it's done. Part of the issue is we don't have a a fully defined scope of exactly what. We'll go into 2.0 before we know it's done.

I'm hoping to try to keep it somewhat constrained. It would be very easy to get caught up in a trap of what's 2.0. Let's throw more features and more features in there if you think about it. Most features are new, like those can go in a minor release. We've got a couple we're putting in, partly because they're ideas that we've had and we've been working on, and they need some of the types changes and the other things we're doing right now, so they can't go in a one x version.

But strictly speaking, they could also probably have waited [00:11:00] until. After 2.0 was out and then mm-hmm. We add them in like a 2.1 or a 2.2 or something. Yeah. So I, I don't have a hard timeline. I'm hoping, quote unquote, sooner rather than later. , 

EMily: and that's it for today, Friday, May 26th. You can check out the full episodes linked in our show notes or on our feed.

And if you like what you hear, follow Pod rocket for more great web development content. See you at the next roundup. . This episode was brought to you by Log Rocket. Try it for free@logrocket.com .