Huh... Remix seems to be kinda nice

Let's start off with what I was trying to do this week

As I mentioned in the end of my last blog, I want to start getting more familiar with remix.js. I started doing some research by reading the remix.js documentation, but I found that there was a lot of features I felt I was being bombarded with, as I hadn't really looked into how the React ecosystem had changed in the past 3 years.

Well it turns out that the ecosystem has evolved a lot, and I'm not sure if I'm going to be able to keep up with it. One of the biggest examples of this is with the introduction of frameworks like Next.js, and Remix which allow for Server Side Rendering. Until these solutions turned up, it was pretty hard for these purely javascript based web apps to generate a static version of their content quickly enough for a search engine robot to crawl, which meant they always performed poorly in terms of SEO. Remix apparently is incredible at making this process really simple, but as someone who's main experience of SSR comes from traditional frameworks like Ruby on Rails and Django, I dunno if I'm totally convinced by this statement. But that's a tangent that I don't particularly want to get into yet, so for now, here's the thing I've noticed so far that seems really cool to me:

File Based Routing:

Remix does file based routing, which means that the folder structure of my /routes/* folder is used to determine the route that the user is on. For example, for my blogs so far, I've created the routes for my app in the following way (not in alphabetical order):

app
├── root.tsx
└── routes
    ├── index.tsx
    ├── blog
    │   ├── firstpost.mdx
    │   ├── secondpost.mdx
    │   ├── index.jsx
    └── blog.tsx

• root.tsx is the "root route" that serves as the layout for the entire application. Each route is rendered inside of its <Outlet /> component. In my case, this means that everything apart from the navbar is rendered inside of the outlet, which means everything other than the navbar takes the layout and styling I've specified here.
• Note that there are files that match the same name as a folder, this indicates a component layout hierarchy. For example, blog.tsx is the parent route for all of the child routes inside of app/routes/blog/*. When a route inside of the blog directory matches, it will render inside of the blog.tsx route's <Outlet />. This is exactly why each of my blog URLs are prefixed with /blog.

Remix contains a very useful loaderFunction that can be defined in every route, and it essentially allows the server to fetch all the data before rendering it to a route. This means that rather than pulling in different css classes for each route with imports, Remix allows us to import a different style as a route needs it. It's also useful for more complex data fetching, such as API calls. The biggest example of this is on my home page for my portfolio actually, where I call the GitHub REST API to fetch my repositories.

export const loader: LoaderFunction = async () => {
    const res = await fetch("https://api.github.com/user/repos", {
        headers: {
            Authorization: `token myAPIKey`,
        }
    });
    return json(await res.json());
}

As we can see, this is a bog standard fetch request, but by wrapping it in a loaderFunction, I can call it in my route with the useLoaderData(). I love this feature, as it allows me to fetch data before rendering the route, which means that I don't have to use some kind of content filler like a loading spinner, which is a common pattern in the React web apps I was developing a few years ago.

What have I learnt?

Well I've learnt that React has got a lot of new framworks to support it, and they are certainly aiming to make it easier to develop server-sided apps. But I also haven't got a chance to look into Remix as deeply as I want, so for now, all I can really say is I'm amazed at how easy it was to initially fetch data, and then pass it down to my routes just as a prop. I think the documentation has been made easy to read so somebody can follow along and write the code easily, but I think its simplicity also means I haven't understood everything as thoroughly as I would like (although in fairness this is probably just as much my fault as it is anyone else's).

What's next?

I'm not sure what I'm going to do next yet. I know I want to get to grips with this framework in more detail, so maybe I'll try to build a more full-stack application that can test the functionality of the framework better than a portfolio and blogging website. I guess my first step will be trying to add some complexity like data storage and authentication, and seeing how well it copes with things like that in terms of fetching data and managing state. I also want to start working on this Coursera course I found on Deep Learning and AI by Andrew Ng. So I guess I'll decide all this tomorrow, and you'll find out about it next Sunday.

ANNOUNCEMENT

I've also just wrapped up my portfolio website, which I (hope) you can see properly on the home page of this website. You can just click the logo to get to this page.