React Remixed

Hello everyone. Welcome to my talk called React Remixed. For anything else let me start to introduce myself. I am Daniel Alfonso. I'm the person on the left on the photo, in case you didn't recognize me. The person on the right here is my programming buddy. I'm a developer advocate at the LLX group. I'm an Auth0 ambassador and a Getion instructor. And you can find me on Twitter and pretty much any social network at the handle DanielJCAlfonso.

So let's jump right into remixing and getting to know more about it. What is this talk about? Well, this talk is about web fetch APIs. It's about HTML, forms, form data objects, URL and others. Okay, now you might be wondering what does this have to do with remix? It does because when you learn remix, you accidentally learn the web. Now I know, I know, I know, I know you might be a bit tired of seemingly a new JavaScript framework showing up every day or so. But the thing is, and like I said right on the previous slide, when you learn remix, you accidentally learn the web. This is because remix leverages the stuff that you've been doing in the web for the round the past 20 years or so. And it makes sure that whenever you learn it, you get knowledge that you can bring back and forth between the web and remix, and this is super, super great.

Now, I know you might be wondering, what is remix? And let's get right into it. Remix is a full stack web framework that will let you focus on the user interface and work back to web standards to deliver a fast, slick and resilient user experience. Remix can also be considered four things. In this case, a compiler, a server-side HTTP, a server framework, and a browser framework. Let's get a bit into each one of them so we can learn a bit more. So, on the compiler part, by using ES build, remix will generate three things. Server HTTP, browser build, and an asset manifest. The browser build is used to...and includes automatically code splitting by route, fingerprinted asset imports like CSS and images, pretty much anything that you will need to run your application in a browser. The asset manifest, in this scenario, both the client and the server are using this asset manifest to pretty much know the entire dependency graph of your application. This is useful when you want to preload resources in the initial render of your application as well as prefetching them for client centralization. This is how Remix is able to delete the render and fetch waterfalls that are very, very common in web applications today. By using this build artifact, an application can be deployed to any hosting service as long as it runs JavaScript. Regarding the server-side HTTP and Android, this is an Android that is given to these JavaScript servers that I mentioned about.

While Remix runs on the server, it is not actually a server per se. Regarding the server-side framework part of Remix, if you're familiar with server-side model-view controllers like, well, Warevel or Rails, Remix is the controller and the view and it lives the model up to the developer. From the browser framework perspective, once a document is served to the browser, Remix will pretty much be responsible for iterating that page with the browser build JavaScript models. So, for instance, if a user clicks a link, instead of making a round trip to the server for the entire document and for all the assets, Remix will simply fetch the data for your next page, update the UI. This has many performance benefits over making a full document request, like these assets don't need to be downloaded or pulled from the cache, they don't need to be parsed by the browser again, and the data that it's fetched is much smaller than the entire document.

So, yeah, this is super, super great, and this is a very small introduction about what Remix is. But yeah, still speaking about it, what is its philosophy? Well, Remix embraces the server-client model fully. You can make your server fast. What you cannot do is control your user network. Sometimes, well, we've all experienced this, it seems to be working very good for us, then we check our code, our application in user network, and just because they don't have the same bandwidth or whatever that we do, then the application is small. Takes more time to load. So Remix helps you by decreasing the amount of stuff that you send over the network, so we don't need to ship all the skeleton UI, because Remix fetches and can even prefetch at times the data before the page is rendered, and this, well, will make it easier for us to send applications to our users.

Like I said previously, Remix works with the foundations of the web. In this scenario, browsers, HTTP and HTML. These are technologies that have been around for a long time, and they're pretty great, and Remix fully embraces them. By combining stuff like HTTP caching, Remix focus on the URL for assets, dynamic server rendering, and HTML features like the link attribute with the prefetch, you have all the tools you need to make your application pretty great, and like I said, browsers and these other types of things that have been around for about 20 years, they are very, very good, and Remix fully leverages it. Remix uses JavaScript to augment the user experience by emulating the browser behavior. While most recent frameworks only have APIs for read and data, Remix has both read and write. Why, you might ask? By leveraging HTML forms. HTML forms have been around for a long time, and they have been the staple for data mutation since the 90s, so Remix will embrace this and fully augment that API. This will enable the data layer of a Remix function to work with or without JavaScript on a page. So this means that JavaScript, when we talk about Remix, is what is called progressive enhancement. If you decide to add JavaScript to your application, it allows Remix to speed up your user experience in two ways. On a page transition, I mean. By not downloading and evaluating JavaScript and CSS assets, and by only fetching data for the parts of the layout that changes. Finally, and the last point of philosophy with Remix is that it doesn't over-abstract the underlying technologies. And this is why it's said, one Remix, accidentally one the web. Because if you get good at Remix, you'll accidentally get good at web development in general. Remix makes it convenient to use, like I said, browser, HTTP, JavaScript. But these things are not hidden and they are not abstracted.

So whatever you're using, it's the same thing you'd be using with the web. And yeah, this is pretty much a six-ish minute introduction to Remix. At least for the theoretical part.

Now, let's get a bit more practical and understand the three top things that you should learn so that you can finish the talk and just dive deep into Remix.

The first one, nested routing. So nested routing is pretty much the general idea that you can couple segments of the URL to your component hierarchy in the UI. Now I know this might not make much sense looking and just reading this description, but let's look at an example. Here we have two routes, a user profile, a user account. Both routes have something in common, which is the user, where we have the username. And they have two tabs here, one for the profile, and one for the account. The concept of nested routing is, whenever we select a profile, our route will change to be user slash profile and we want to render this nested part, which is the nested profile page. But if we click on the account, you want our route to change to account and render nested account page. And this is how nested routing works, because whenever you select a part of the URL, of the UI, instead of re-rendering the rest or changing page, it will render the nested part of the component. And this is super powerful. And Remix leverages this fully.

So for the next part, which is data fetching and mutations. Well, I know with client-side applications and what's all, we are very used to using use effects or React, query, or SWR, but Remix makes this so much easier and so much simpler. So let's see how we can do data loading with Remix. So here we have a component called heroes. In this component, what we want to do is fetch some data, some hero data, and render it. So how would this work in Remix? First thing we have to do is export a loader function. A loader function is a function that will run whenever application loads. And this is how you can do data loading in your application. Whenever you load an application, your app, you can trigger some data fetching. So what we have here is we have, we're returning JSON. This is an HTTP response, and this will return your data. Then so that inside of the component we can have access to the data, we get our user loader data hook, which will give us access to the data. And then yeah, we just render it. And this is how you can do data loading with Remix. It seems very simple to do, and it makes it so much, so much easier to fetch data.

And de-coupling the complexity, I guess, it makes it much simpler to understand. For mutations it's very simple. But instead of using loaders, we create actions. Now, you might be wondering, how do we trigger an action? I spoke about forms around 3-4 minutes ago, didn't I? Because that's how Remix does mutations. Pretty much we create our form and we define what method our form is going to do, get our post, and then we have inside the inputs that we have to do and whenever we submit it, this Remix will be able to look into the application and say, okay, is there any action here that is, that needs to be fetched or needs to be triggered? So whenever we click submit, this action will get triggered and inside of it, we do a couple of things. We can get access to the request, which is where we can get the form data that our form is filled with. So we don't need to keep track of state inside of our component because whenever we press submit, the form data will be sent to our action and we can just structure it here. Okay, so once we have our form data, we can trigger our data mutation and yeah, that's pretty much it.

So now let's look at the code sample that I have here, which is an application built on Remix that shows a bit of this concept so we can hook a bit more into that. Okay. So now enough of shit chat and let's just see some code and I have here a demo, which is pretty much a concept built on the top of Tower of Babel, which is a comic from Justice League from a couple years ago, where well, Batman just had a list of heroes where you could see their real identities and weaknesses, just in case anyone from the Justice League or whatever went rogue.

So here we have an application built on top of Remix and we have a couple of things that we can do here. First things first, this is already leveraging nested routing, but I'll show you how. So here we have a simple component where we can check our heroes. In this scenario we're checking Batman's profile and here we can see the user that's logged in and in this scenario Batman is logged in. Because yeah, we want to keep this set, no one else should use our application. And then we have our hero identity, our secret identity and what the weaknesses are. For some reason if Batman regrets it and he wants to remove that hero, you can do it. You can also add some new heroes, so let's for instance let's add Superman. In here, Clark Kent has his secret identity and the weaknesses is Kryptonite. Ok, so now when we save this our hero is here and yeah this is pretty much what the application is doing. If you want to delete it, you can delete it as well.

So let's open some code. So here we have our heroes route, which is pretty much whenever we go to the heroes route this is what's going to be rendered. So as you saw previously in my explanation, we are using a folder to do some data fetching. In this scenario this folder is responsible for authenticating our user and for getting our heroes data to be shown on our menu that we have down there. And inside of our route we call a userloader data hook to get our data and with that data we're going to render our heroes. Now this is where we get into nested routing. What enables nested routing is this fun thing here called an outlet. An outlet will look into our file folders and see, is there any folder created with the route heroes? In this scenario it will find inside the routes that there's a folder called heroes and say ok, let's render it. The first thing it will look for is for an index and in this scenario our index says access the bad computer and this is why our first page says access the bad computer. So this is the nested part of heroes, all the things here that we have it's inside heroes but whenever we render things to devoutlet, at the nested routes, this is the index of our heroes page. Now if we click on it, we are going into the new route and going back to our code, new route it's here so, heroes slash new. This is how you are able to check the route in Remix. Here we have a couple of things, but pretty much what we have is an action, that's gonna be triggered whenever this form here is submitted. So we have our form, we trigger our action, this action is doing a couple of things, once again it's getting the request, by thanks to the request it's authenticating our user, it's getting the form data that it's filled by the form, and then a couple of validations and it's creating our hero. And yeah, this is pretty much what this is doing. Oh and it's also triggering a redirect.

This redirect is pretty much a 302 response, like I said, it leverages the web. This is an HTTP response. So yeah, that's how it works. And yes, this is pretty much what it's doing.

Now, you might be wondering, how am I going to render all the heroes? Because if you look into here, each hero should have a random ID. Let me just add one more so you can see. Yeah, as you can see, the ID is not the same from Batman. I'm not going to be creating a route for everything because, well, this wouldn't be scalable. So this is where we leverage dynamic routes. By adding a slot here, by adding the dollar sign and putting it in, Remix will say, okay, everything that's inside Heroes and is not specified here, you'll get into this route. This route is doing a couple of things, but it's pretty much the general concept of as a loader. Once the data is fetched, it returns it. This data is picked up by user data, and then we have a form to trigger or delete this form as a corresponding action. And yes, this is pretty much our application work.

So, now to wrap up, let's look at a couple of things that Remix can make easy for us. Remix stacks are a bunch of alternatives that we can use to start building our application with Remix. We have Grunge stack, Indie stack, Wolf stack, and pretty much all of them depend on whatever you want to deploy, what database you want to use, etc., etc. And it's pretty great. Give it a try and check it out. So to wrap up this talk, let's get into the million dollar question, which is Remix versus Next. Well, here we have a QR code that you can scan. This will redirect you to the Remix blog, where they have a study where comparing Remix with Next. And during this study, they came to the conclusion of a couple of things. First things first, Remix is as fast or faster at serving dynamic and static content. And it even enables a faster user experience even on slow networks, because like I said, you can make your server fast, you cannot make your user networks fast, and Remix makes it easier for us to... Well, enable a faster experience even on these slow networks, like it's written here. Also, it automatically handles errors, interruptions and race conditions, and this is super, super cool. It saves so much time not having to implement everything by yourself. And all the real times in Remix are instantly decoupled from data.

And all the real times in Remix are instantly decoupled from data. So yeah, does this mean you have to stop using Next? Well, I guess it's up to you. Frameworks come and go. Remix is super great and it's super exciting to see all the amazing news that have been coming around it, and I definitely see a very, very, very great and shining future for Remix and I want to stick around to watch it for the next couple of years.

So yeah, before anything else, let me start by thanking you all. Thanks RemixConf for having me. This is a super amazing experience to be here speaking to all of you and learning from all the amazing other speakers about our common love right now, which is Remix. I've been Daniel Alfonso, this is a QR code that you can check if you want to find me on Twitter or send me a message. Yeah, thank you so much. I hope you have the rest of a nice day and amazing week. See you around.