There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all. I’m calling it “full stack components” and it allows me to colocate the code for my UI components with the backend code they need to function. In the same file.

Let’s first start with the first time I’ve ever seen such a strong marriage between the UI and backend. Here’s what it’s like to create a web page in Remix:

I’m going to just gloss over how awesome this is from a 

 perspective and instead focus on how nice it is that the backend and frontend code for this user experience is in the 

 Remix enables this thanks to its compiler and router.

 runs on the server (only) and is responsible for getting our data. Remix gets what we return from that into our UI (which runs on both the server and the client). The 

 runs on the server (only) and is responsible for handling the user’s form submission and can either return a response our UI uses (for example, error messages), or a redirect to a new page.

But, not everything we build that requires backend code is a whole page. In fact, a lot of what we build are components that are used within other pages. The Twitter like button is a good example of this:

Twitter Like button getting clicked

That twitter like button appears many times on many pages. Normally the way we’ve built components like that is through a code path that involves click event handlers, fetch requests (hopefully thinking about errors, optimistic UI/pending states, race conditions, etc.), state updates, and then also the backend portion which would be an “API route” to handle actually updating the data in a database.

In my experience, doing all of that involved sometimes a half dozen files or more and often two repos (and sometimes multiple programming languages). It’s a lot of work to get that all working together properly!

With Full Stack Components in Remix, you can do all of that in a single file thanks to Remix’s 

 feature. Let’s build a Full Stack Component together. For this example, I’m going to use a feature I built for 

 of the “Fakebooks” example app demonstrated on 

. We’re going to build this component which is used on the “create invoice” route:

New invoice page showing customer combobox listing options as a query is typed

First, let’s make the resource route. You can put this file anywhere in the 

 directory. For me, I like to put it under 

 directory, but feel free to stick it wherever makes sense under 

. To make a resource route, all you need to do is export a 

s data and doesn’t actually need to submit anything. So, let’s make a super simple loader to start with:

Great, with that, let’s run the dev server and open up the route 

Great! We now have an “endpoint” we can call to make requests. Let’s fill that out to actually search customers:

This is a publicly accessible URL but our customer data should be private, so we need to secure it via 

 which will check that the user making the request is authenticated.

 request, the user input will be provided via the URL search params on the request, so we grab that (and also validate that the query is a string as expected).

We retrieve matching customers from the database with 

 and send that back in our JSON response.

Now if we hit that URL again with a query param 

Santa Monica

Stankonia

Wide Open Spaces

Sweet! Now all we need is a component that we can use to hit this endpoint.

 hook that our component can use to communicate with resource route and we can define that component anywhere we like. I had a real “aha 💡” moment when I realized that there’s nothing stopping you from defining and even exporting extra stuff from Remix routes. I don’t recommend making a big habit out of importing/exporting things between routes, but this is one very powerful exception!

I’m going to just give you all the React/JSX stuff because it’s really not that important for what we’re discussing in this post. So here’s the start to the UI component:

We’ve got 🐨 Kody the Koala in there showing the specific touch-points that are of particular interest to what we’re building. A few things to note:

 to build our combobox (a great set of hooks and components for building accessible UIs like this that I built when I was at PayPal).

 to style stuff in here because it’s amazing and it also helps give us that “Full” part of “Full Stack Component” by including the styling within this component as well.

Let’s follow Kody’s instructions and add 

 in here to make a GET request to our resource route. First, let’s create the 

Great, so now, all we have to do is call the 

. As I said, normally this involves a lot of work, but with Remix’s 

 handling race conditions and resubmissions for us automatically, it’s actually pretty simple. Whenever the user types, our 

 callback will get called and we can trigger 

 is set to reference the file that we’re currently in and the 

 so Remix on the server will route this request to the 

As far as “functional” goes, we’re finished! But we do still have a bit of work to do to make the experience great.

For some of our users, this will be enough, but depending on network conditions over which we have no control, it’s possible this request could take some time. So let’s add pending UI.

, we’ve got 🐨 telling us we should render a spinner. Here’s a spinner component you can use

So let’s render that next to the input:

And now, how are we going to determine the 

 value? 🐨 is sitter there next to the 

 declaration inviting us to determine that value there. With 

, we’re given everything we need to know the current state of the network requests going on for our Full Stack Component. 

. In our case, we’re safe to say that if that state is not 

That’s great, but it can lead to a flash of loading state. We’ll leave it like that for now though so you can play around with it.

This part is nothing special. We simply import the component and render it. If you open up 

 component, you’ll find 🐨 waiting there with 

 ready for you. You’ll also need to add an import at the top: 

import { CustomerCombobox } from '~/routes/resources/customers'

 prop and things are outside the scope of this post, but feel free to poke around if you’d like.

With the UI rendered, the whole thing is now functional! But we do have one small issue I want to address first. In the 

, I want you to add a bit of code to slowdown the request to simulate a slower network:

 as our timeout time, that slows it down just enough to be a pretty fast network, but not instant. Probably pretty close to the fastest experience most people would have in a real world situation. Here’s what our loading experience looks like with that:

Shows the customer combobox with a spinner that flashes for a few milliseconds

Notice that our loading spinner flashes with every character I type. That’s not great. I actually was bothered about this with my global loading indicator for 

 to solve this very issue! So, let’s add that to our 

What this is doing is it says: “Here’s a boolean, whenever it changes to 

, I want you to continue to give me back 

 unless it’s been true for 150ms. If you ever do return 

 for at least 500ms, even if what I gave you changes to 

.” I know it sounds a bit confusing at first, but read that through a few more times and you’ll get it I promise. Feel free to play around with those numbers a bit if you like.

In any case, doing this solves our issue!

Customer combobox showing a list of customers and no spinner shown

On top of this, if we increase that timeout delay in our 

Customer combobox with customers showing as a query is typed and a spinner being displayed

Here’s the finished version of our Full Stack Component:

I love how the integration points are pretty minimal here, so I’ve highlighted those lines above.

Remix allows me to colocate my UI and backend code for more than just full page routes, but also individual components. I’ve been loving working with components this way because it means that I can keep all the complexity in one place and drastically reduce the amount of indirection involved in creating complex components like this.

You may have noticed the lack of "debounce" on this. Most of the time I've built components like this, I've had to add a debounce so I don't send a request as soon as the user types. Sometimes this is useful to reduce load on the server, but if I'm being honest, the primary reason I did it was because I wasn't handling race conditions properly and sometimes responses would return out of order and my results were busted. With Remix's 

, I don't have to worry about that anymore and it's just so nice!

We didn’t get a chance to see this in action in our tutorial today, but if the component were to perform a mutation (like marking a chat message as read) then Remix would automatically revalidate the data on the page so the bell icon showing a number of notifications would update without us having to think about it (shout-out to folks who remember 

P.S. In the tweet situation we started with, we could take the pending state even further to optimistic UI which is also awesome. If you want to learn more about how to do 

There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all.

Full Stack Components

TypeScript is an enormous part of the web industry. And there’s a good reason for this. It’s amazing. And I’m not just talking about this:

I mean, that’s cool and all, but what I’m talking about is code that’s more like this:

A type that flows throughout the entire program (including between the frontend and backend). In the real world this is how it works and it can be a terrifying prospect to decide one day that you want to turn that “Seats Left” field into a combination of “Total Seats” and “Sold Seats” fields. Without types guiding you through that refactor you’re gonna have a hard time. I sure hope you have some solid unit tests.

But I don’t want to spend this article convincing you how great types in JavaScript are. Instead, I want to share my excitement about how great end-to-end type safety has been and show you how you can accomplish it for yourself in your own applications.

First, what I mean by end-to-end type safety, I’m talking about having type safety from the database, through the backend code, all the way to the UI and back again. Now, I realize that everyone’s in different circumstances. You may not have control over your database. When I was at PayPal, I consumed a dozen services built by different teams. I never touched a database directly. So I understand if getting true end-to-end type safety may require collaboration. But hopefully I can help get you on the right track to get as far as possible in your own situation.

The main thing that makes end-to-end type safety difficult is simple: 

The secret to fully typed web apps is typing the boundaries.

In the web, we have a lot of boundaries. Some of these you may have in mind, and others you may not consider. Here are a few examples of boundaries you’ll encounter on the web:

There are plenty more examples, but these are some common boundaries you’ll run into. Some boundaries we have here are (there are more):

 to be 100% certain that what you’re getting back from a boundary is what you expect. This bears repeating: It is 

 You can certainly “make TypeScript happy” by throwing around a 

 type cast and whatever, but you’re just hiding the problem there. The file could have changed out from under you by another process, the API could have changed, the user could have modified the DOM manually for goodness sake. There’s just no way to know for certain that the result that came to you across that boundary is what you expected it to be.

Write type guards/type assertion functions

Use a tool that generates the types (gives you 99% confidence)

Help inform TypeScript of your convention/configuration

So, let’s take a look using these strategies to get end to end type safety by addressing the boundaries of web apps.

 way to make sure what you got across the boundary is what you expected. You literally write code to check it! Here’s a simple example of a type guard:

At this point, some of you who are annoyed by having to “appease” the TypeScript compiler. If you’re so positive that 

 will be what you expect, then just throw an error (it’ll be more helpful than the error you’d get if you ignored this potential problem anyway).

There’s a handy utility I use in almost all my projects to make this slightly nicer on the eyes:

 function takes a value, and if the value is falsy then the invariant function will throw. If the value is truthy, then the function will not throw.

Having to add the extra code is annoying. This is just a tricky problem because TypeScript doesn’t know your conventions or config. That said, maybe we could let TypeScript know about our conventions and config to help it out a bit. Here are a few projects working on this problem:

 both generate types based on your Remix config/conventional routes (we’ll talk about this more later)

) have access to the routes you’ve defined (effectively informing TypeScript of your config which is another workaround we’ll get to).

This is just an example from a router perspective, which is addressing the URL boundary to your application, but the idea of teaching TypeScript your conventions can apply to other areas as well.

Let’s check out another more complex example of a type guard:

Seems like a lot of work, even for a relatively simple type. Imagine a more real-world complex type! If you’re doing this a lot, you may find a tool like 

My biggest concern with zod (why I don’t use it all the time) is the bundle size is quite large (

 at the time of this writing). But if you’re using it only on the server or you’re going to benefit a lot from it then it could be worth that cost.

One tool taking advantage of zod to help a great deal with fully typed web apps is 

 which shares types defined with zod on the server to client-side code to give you type safety across the network boundary. As I use Remix I don't personally use tRPC (though you definitely can if you'd like), but if I weren't using Remix, I would 100% be looking into using tRPC for this capability.

Type guards/assertion functions is also the approach you’d want to use to handle 

 for your forms. Personally, I’m really enjoying using 

, but the idea is the same: Code that actually checks the types at runtime and gives you type safety around the boundaries of your app.

I talked about two tools that generate types for your Remix conventional routes, those are a form of type generation to help solve the problem of end-to-end type safety. Another popular example of this workaround is 

 (my favorite ORM). Many GraphQL tools do this as well. The idea is to allow you to define a schema and Prisma ensures that your database tables match that schema. Then it also generates TypeScript type definitions that match the schema as well. Effectively keeping the types and database in sync. For example:

Any time you make a change to your schema and create a migration script, prisma will update the types that it has in your 

 directory so when you interact with the prisma ORM, the types match the current schema. Here’s a real-world example from the 

And this is what’s generated from that:

This gives a fantastic developer experience and serves as the starting point to my types that flow through my application on the backend.

The primary danger here is if the database schema and the data in the database somehow get out of sync. But I’ve yet to experience that with Prisma and I expect that to be quite rare, so I feel pretty confident in not adding assertion functions around my database interactions. However, if you’re not able to use a tool like Prisma or if you’re not the team responsible for the database schema, I suggest that you find a way to generate types for your database based on the schema because it’s just fantastic. Otherwise you may want to add assertion functions to your database query results.

Keep in mind we’re not just doing this to make TypeScript happy. Even if we didn’t have TypeScript, it would be a good idea to have some level of confidence that data going between a boundary in your application is what you expect it is. Remember:

Helping TypeScript with Conventions/Config

One of the more challenging boundaries is the network boundary. Verifying what the server is sending your UI is tricky. 

 doesn’t have generic support, and even if it did you would be lying to yourself:

Allow me to let you in on a dirty little secret about generics… Almost any function that effectively does this is probably a bad idea:

 (a type cast), you should think: “That’s lying to the TypeScript compiler” which sometimes is what’s required to get the job done, but I don’t recommend doing this like the 

 function above. You’ve got two choices:

In both cases you’re lying to TypeScript (and yourself), but in the first case you don’t know it! If you’re going to lie to yourself, you should at least know that you’re doing it.

So what do we do if we don’t want to lie to ourselves? Well, you could establish a strong convention for your fetching and then inform TypeScript of that convention. That’s what’s done with Remix. Here’s a quick example of that:

 function is a generic which accepts a Remix 

 function type and is able to determine all possible JSON responses (huge thank you to the creator of zod, 

 function runs on both the server and client, but getting those types across that network boundary just kind of happens thanks to the generic understanding Remix’s loader convention. Remix will ensure that the data returned from the loader will end up being returned by 

. All in one file. No API routes necessary 

If you’ve not experienced, you just gotta believe me that this is an 

 experience. Just imagine we decide we want to display the 

 field in our UI. That’s as simple as updating our 

 for the database query, and then we suddenly have that available in our UI code without changing anything else. Completely type safe! And if we decide we no longer need the 

 and we’ll get red squiggles (and type checking errors) everywhere we were using the 

 in the backend. This is because the data has to go through the network boundary and in the process everything gets serialized to a string (JSON doesn’t support Dates). The type utilities enforce this behavior which is stellar.

If you plan to display that Date, you probably should format it in the 

 before sending it over to avoid timezone weirdness when the app is hydrated on the user’s machine. That said, if you don’t like this, you can use a tool like 

 to get those data types restored in the UI.

s as well. Here’s an example of that as well:

 returns ends up being the type (serialized) that our 

 which will have type safe properties as well. Also the submitted data is safely parsed by 

 following the schema I provided, so the 

 type has all my data parsed and ready to go. There are other libraries for this, but the point is, with a few simple utilities we can get some fantastic type safety across boundaries and increase our confidence in shipping. Well, the API for the utilities is simple. Sometimes the utilities themselves are pretty darn complex 

It should be mentioned that this works throughout other Remix utilities as well. The 

 thing is just the bee’s knees. I mean, heck, watch this!

Across the network typesafety

The point I’m trying to make here is that type safety is something that’s not only valuable, but achievable across boundaries end to end. That last loader example goes all the way from the database to the UI. That data is type safe from 

 and it makes me incredibly productive as an engineer. Whatever project you’re working on, think about how you can drop a few 

 type cast lies and change it to more true type safety using some of the suggestions I’ve provided here. I think you’ll thank yourself later. It’s definitely worth the effort!

If you want to try out an example of this, checkout 

And before anyone asks, I will 100% be teaching all of these methods in EpicWeb.dev. 

The main thing that makes end-to-end type safety difficult is simple: boundaries. The secret to fully typed web apps is typing the boundaries.

Fully Typed Web Apps

The web is made up of technologies that got their start over 25 years ago. HTTP, HTML, CSS, and JS were all first standardized in the mid-nineties (when I was 8 years old). Since then, the web evolved into a ubiquitous application platform. As the web has evolved, so too has the architecture for the development of these applications. There are many core architectures for building applications for the web these days. The most popular architecture employed by web developers today is the Single Page App (SPA), but 

 to a new and improved architecture for building web applications.

 elements have been around from the very beginning. Links for a browser to get things from a server, and forms for a browser to send things to a server (and get things in return). With this two-way communication established as a part of the specification from the start, it has been possible to create powerful applications on the web forever.

Here are the major architectures (in chronological order of popular use):

Progressively Enhanced Multi-Page Apps (PEMPAs, aka “JavaScript Sprinkles”)

Each architecture of web development has benefits and pain points. Eventually, the pain points became enough of a problem to motivate the move to the next architecture which came with its own trade-offs.

No matter how we build our applications, we’re almost always going to need code running on a server (notable exceptions includes games like Wordle which [

] store game state in local storage). One of the things that distinguishes these architectures is 

 Let’s explore each of these in turn and watch how the location of code changed over time. As we cover each architecture, we’ll consider specifically the following use cases of code:

Persistence - saving and reading data from a database

Routing - directing traffic based on the URL

Data fetching - retrieving data from persistence

Data mutation - changing data in persistence

Rendering logic - displaying data to the user

UI Feedback - responding to user interaction

There are, naturally, more parts of a web application than these bits, but these are the bits that move around the most and where we spend the bulk of our time as web devs. Depending on project scale and team structure we may work in all of these categories of code or we may work on only a part of one.

In the early days, this is the only architecture that worked at all on the web based on the capabilities of web browsers at the time.

 write lives on the server. The UI Feedback code on the client is handled by the user’s browser.

 When the user enters a URL in the address bar, the browser sends a request to our server. Our routing logic will call a function to fetch data which communicates with the persistence code to retrieve the data. This data then gets used by the rendering logic to determine the HTML which will be sent as a response to the client. All the while, the browser is giving the user feedback with some kind of pending state (normally in the favicon position).

 When the user submits a form, the browser serializes the form into a request sent to our server. Our routing logic will call a function to mutate the data which communicates with the persistence code to make database updates. Then it will respond with a redirect so the browser triggers a GET request to get fresh UI (which will trigger the same thing that happened when the user entered the URL to begin with). Again, the browser will give the user feedback with pending UI.

Note: It’s important that successful mutations send a redirect response rather than just the new HTML. Otherwise you’ll have the POST request in your history stack and hitting the back button will trigger the POST request again (ever wonder why apps sometimes say “DON’T HIT THE BACK BUTTON!!” Yeah, that’s why. They should’ve responded with a redirect).

The mental model of MPAs is simple. We didn’t appreciate it back then. While there was 

 state and complicated flows handled primarily by cookies in the requests, for the most part everything happened within the time of a request/response cycle.

Full-page refreshes - Makes some things hard (focus management), other things impractical (imagine a full-page refresh every time we liked a tweet…), and some things just impossible (animated page transitions).

UI Feedback control - It’s nice that the favicon turns into a spinner, but often a better UX is feedback that is visually closer to the UI the user interacted with. And it’s certainly something designers like to customize for branding purposes. And what about optimistic UI?

It’s notable that the web platform is constantly improving with 

 which makes MPAs a more viable option for more use cases. But for the majority of web applications, that’s still not enough. In any case, at the time this problem was far from the minds of standards committees and our users wanted more now!

Progressively Enhanced Multi-Page Apps (PEMPAs)

Progressive Enhancement is the idea that our web applications should be functional and accessible to all web browsers and then leverage whatever extra capabilities the browser has to enhance the experience. The 

 by Nick Finck and Steve Champeon. Speaking of the capabilities of the browser…

XMLHttpRequest was initially developed by Microsoft’s Outlook Web Access team in 1998 but it wasn’t 

 until 2016 (can you believe that!?). Of course that never stopped browser vendors and web devs before. AJAX was popularized as a term in 2005 and a lot of people started making HTTP requests in the browser. Businesses were built on the idea that we don’t have to go back to the server for any more than little bits of data to update the UI in place. With that, we could build Progressively Enhanced Multi-Page Apps:

“Whoa!” you might be thinking, “wait a minute… where’d all this code come from?” So now we’ve not only taken responsibility of UI feedback from the browser, we also have Routing, Data fetching, Data mutation, and Rendering logic to the client 

 to what we already had on the server. “What gives?”

Well, here’s the deal. The idea behind progressive enhancement is that our baseline should be a functional app. Especially in the early 2000s, we couldn’t guarantee that our user would be using a browser capable of running our fancy new AJAX stuff, or that they would be on a fast enough network to download our JavaScript before interacting with our app. So we needed to keep the existing MPA architecture in place and only use JavaScript to 

That said, depending on the level of enhancement we’re talking about, we may indeed have to write code in almost all of our categories, persistence being the exception (unless we want offline mode support which is really neat, but not an industry standard practice, so it’s not included in the chart).

 more code to the backend to support AJAX requests our client would make. So more on both sides of the network.

Web is made up of technologies that got started over 25 years ago. Now, we are transitioning to a new and improved architecture for building web applications.

Epic Web Dev Articles

Full Stack Components

Fully Typed Web Apps

The Web’s Next Transition