Forem: Royce Threadgill

React Server Components Example with Next.js

Royce Threadgill — Tue, 16 Apr 2024 19:17:12 +0000

React Server Components (oftentimes shortened to RSC) provide us with a fascinating new approach to building React applications.

That said, my experience while researching this article was far less rosy and far more expletive laden than I expected.

But now that I have been one acquainted with the RSC, I’d like to share my findings with you so that hopefully your learning journey won’t be quite as painful or confusing.

In this article, we’ll discuss a range of topics, including:

What are React Server Components?
Can you use React Server Components without Next.js?
How do React Server Components work in Next.js?
What are the advantages and disadvantages of React Server Components?
Are React Server Components production ready?

We’ll also go through a React Server Components example using the Next.js app router. That example will discuss RSC streaming behavior and client and server component nesting. If you’re only interested in the code example, just scroll to the bottom of the article.

Let’s begin!

What are React Server Components?

My favorite definition of RSC comes from Mark Dalgleish in his 2023 React Advanced conference talk, “Simplifying Server Components”. The way he puts it is that “server components are just virtual DOM over the network”.

What does this mean?

Let’s say we have a React component called Basic:

const Basic = () => {
  return (
    <main>
      <p>Hello, World</p>
    </main>
  );
};

On the server, that component would be serialized into what’s known as an RSC payload. That would look something like this in the Next.js server component implementation.

// ...complicated Next.js stuff up here
{
  children: [
    "__PAGE__",
    {},
    [
      "$L1",
      [
        "$",
        "main",
        null,
        {
          children: ["$", "p", null, { children: "Hello, World" }],
        },
      ],
      null,
    ],
  ];
}
// ...more complicated Next.js stuff down here

That RSC payload would then be streamed down to the client and rendered exactly like any other JSX.

ℹ️ Sidenote: This explanation gets at the core of React Server Components, but is a little simplified. If you want to learn more about what’s happening under the hood, I highly recommend watching to Daishi Kato’s “Exploring React Server Component Fundamentals” talk at React Day Berlin 2023.

Seems pretty simple, right? So why bother with this RSC payload nonsense? Why not just render the component to HTML and stream that down to the client?

Well, we can! Typically, we would call this server side rendering (SSR).

React Server Components vs SSR

We’ve actually been able to serialize React components to HTML for several years now.

You can find a solid definition of SSR in the Vite documentation:

SSR specifically refers to front-end frameworks (for example React, Preact, Vue, and Svelte) that support running the same application in Node.js, pre-rendering it to HTML, and finally hydrating it on the client.

Put simply, SSR pre-renders a React component to HTML, while RSC serializes a React component into an RSC payload.

Server components have a couple advantages over traditional SSR. For one, SSR requires a hydration step once the HTML has been sent to the client; the initially loaded page isn’t interactive until the entire JS bundle is downloaded and the entire page is hydrated.

By comparison, server components require no hydration step, allowing pages to load faster and become interactive more quickly.

The page loading issues raised by SSR can be mitigated by chunking your JavaScript bundle and streaming it to the client, but eventually the entire bundle needs to be downloaded. And that bundle tends to get larger as your application grows.

Server components, meanwhile, add no additional JavaScript to your bundle. As your application grows, your JavaScript bundle size does not grow with it (assuming you only use server components).

ℹ️ Sidenote: It’s important to note that RSC and SSR aren’t mutually exclusive. You can learn a bit more about this by reading “Making Sense of React Server Components” by Josh Comeau.

Server Components vs. Client Components

The Basic component above was a simple example. What happens when we add interactivity to our component?

Let’s say we add a Counter to our Basic component:

const Basic = () => {
  return (
    <main>
      <Counter />
      <p>Hello, World</p>
    </main>
  );
};

When we interact with the Counter, we would expect the value to increment. In other words, that component has state and must be declared as a client component in our React code.

How do we represent such a component in a format that can be generated on the server and sent to the client? The answer, as you may have guessed, lies in the RSC payload.

When a bundler supporting React Server Components detects a client component, it adds a reference to that component in the RSC payload – react.client.reference.

The bundler also generates a manifest that maps the reference ID to the actual client component, which determines what JavaScript must be sent to the client (meaning that, unlike server components, client components will contribute to your bundle size).

In Episode #311 of the Changelog podcast, Dan Abramov said (and I’m paraphrasing a bit here) the RSC payload resulting from such scenarios can be thought of as having a script tag in place of the client component.

ℹ️ Sidenote: If you’re interested in learning a bit more about how client components are serialized, take a look at “React Server Components, without a framework?” by Tim Pillard.

As the late Billy Mays would say, “But wait, there’s more!”

What happens when you nest a server component inside that client component? As wacky as it sounds, your bundler recognizes that as a server component and serializes it as such in the RSC payload.

Don’t worry, we’ll get more into server components vs client components in our code example. But first, let’s address the elephant in the room….

React Server Components Without Next.js…?

Daishi Kato, creator of Zustand and Jotai, says there are a few things we need to support RSC serialization:

Bundler capable of recognizing client components, generating a manifest, and resolving client references on the client
Server capable of accepting HTTP requests and responding with (dynamic) RSC payloads
Router capable of intelligently serving resources (e.g., don’t render client components that are not useful for a given route)
SSR that works in tandem with React Server Components, largely for initial page load performance

So while the RSC concept is fairly straightforward in theory, there are a number of moving parts necessary for implementing RSCs in practice.

Currently, Next.js is the only production framework that fully supports RSCs.

This isn’t an accident; when Meta introduced React Server Components, Dan Abramov explicitly stated that they collaborated with the Next.js team to develop the RSC webpack plugin.

That means you’re mostly limited to Next.js if you’d like to build an app with RSCs.

📣 Important: This article was originally written in March 2024. At the very end of that month, RedwoodJS announced full support for server components! While there still appear to be some implementation issues, RedwoodJS does now offer a viable alternative for implementing React Server Components in production.

But What If I Really Don’t Like Next.js?

If you’re really against using Next.js, your options are limited and largely experimental.

The moderators at Reactiflux pointed me toward Waku (also developed by Daishi Kato) as a potential alternative. However, Daishi explicitly recommends using the framework on non-production projects.

At Node Conference 2023, Jarred Sumner (creator of Bun) showed a demo of server components in Bun, so there is at least partial support in that ecosystem. The Bun repo provides bun-plugin-server-components as the official plugin for server components. And while I haven’t looked at it in-depth, Marz claims to be a “React Server Components Framework for Bun”.

In the Changelog Podcast episode referenced above, Dan Abramov alluded to Parcel working on RSC support as well. I couldn’t find much to back up that claim aside from a GitHub issue discussing directives and a social media post by Devon Govett (creator of Parcel), so I can’t say for sure if Parcel is currently a viable option for developing with RSCs.

And you can’t use React Server Components with Vite right now, but support is being worked on.

React Server Components Example with Next.js

Alright, with that out of the way, let’s get to the code example. Note that we’re using Tailwind for styling just to make the example a bit less ugly; Tailwind has no other bearing on the example.

For reference, here are our dependencies:

"dependencies": {
    "react": "^18",
    "react-dom": "^18",
    "next": "14.1.3"
  },
  "devDependencies": {
    "typescript": "^5",
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "autoprefixer": "^10.0.1",
    "postcss": "^8",
    "tailwindcss": "^3.3.0",
    "eslint": "^8",
    "eslint-config-next": "14.1.3"
  }

We’re going to cover a few concepts here, but we’ll start with a React Server Components Suspense example to demonstrate how payload streaming is handled.

React Server Components and `Suspense`

React Suspense can intelligently display parts of the RSC payload as they are streamed down to the client. If the component is not yet available, Suspense will fall back to a loading state.

Let’s say we have a component Multiple, which has multiple server components that take varying amounts of time to load:

// src/app/multiple/page.tsx

const Multiple = () => {
  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <div className="flex w-1/2">
        <div className="flex flex-col gap-8">
          <h1 className="text-4xl">Multiple long loading things</h1>

          <Suspense fallback={<p>Loading...</p>}>
            <LongLoadingComponent />
          </Suspense>

          <Suspense fallback={<p>Loading...</p>}>
            <LongerLoadingComponent />
          </Suspense>

          <Suspense fallback={<p>Loading...</p>}>
            <LongestLoadingComponent />
          </Suspense>
        </div>
      </div>
    </main>
  );
};

export default Multiple;

Each server component is wrapped within a Suspense component, which falls back to “Loading…” text until the server component is available.

For the purposes of this example, we’ll mock each long running query with a Promise that resolves after a defined timeout. So each of the server components will look something like this:

const longLoadingFetch = async () => {
  const promise = new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve("Vegeta, what does the scouter say about his power level?");
    }, 2000);
  });

  return promise;
};

const LongLoadingComponent = async () => {
  const res = await longLoadingFetch();

  return (
    <div className="text-white border border-white p-4">{res as string}</div>
  );
};

export default LongLoadingComponent;

Each component will have a different timeout value and string to simulate different server components with different query durations.

Initially, each server component is unavailable and all display the “Loading…” text. Then the quickest component renders, then the second quickest, then the third quickest.

In Episode #718 of the Syntax podcast, Wes Bos pointed out a handy RSC Devtools Chrome extension that we can use to better understand what’s going on here.

We can see that we have three lazily loaded components, which lines up with what we would expect. If we click on the first node, we see the RSC payload and the rendered content.

Also note that the page header has already been rendered! The remainder of the RSC payload is streamed down to the client as it becomes available. Importantly, this means the long-running queries are not blocking page rendering.

ℹ️ Sidenote: If you’d like to learn more about how the RSC payload is streamed to the client, check out “Why React Server Components Are Breaking Builds to Win Tomorrow”.

But you may have noticed that this example only deals with server components. Let’s examine a more complex example that involves both client and server components.

Interleaving Client and Server Components

This is where the fun begins. In this example, we’ll be looking at how to implement some basic search functionality. Let’s take a look at the Search component:

// src/app/search/page.tsx

const Search = ({
  searchParams,
}: {
  searchParams?: { [key: string]: string | string[] | undefined };
}) => {
  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <div className="flex w-1/2">
        <div className="flex flex-col gap-8">
          <h1 className="text-4xl">Search example</h1>

          {/* client component */}
          <CounterProvider>

            {/* client component */}
            <SearcheableToDoList>

              {/* client component */}
              <SearchField />

              <Suspense fallback={<p>Loading...</p>}>

                {/* server component */}
                <ToDoList searchParams={searchParams}>

                  {/* client component */}
                  <CounterDisplay />
                </ToDoList>
              </Suspense>
            </SearcheableToDoList>
          </CounterProvider>
        </div>
      </div>
    </main>
  );
};

export default Search;

I’ve added comments to indicate where there are server and client components. Note that the searchParams value passed into the Search component is a Next-specific property containing the query parameters for the page.

Let’s briefly discuss what the individual components are doing:

CounterProvider is a client component providing a context to its children components; the context value is just counterVal and setCounterVal.
SearcheableToDoList is a client component wrapper that uses the above context to increment the counter value on clicking a button; it displays the counterVal, a button to increment the counter, and its children.
SearchField is a client component input that updates the URL query parameters
ToDoList is a server component that reads data from a data.json file, then filters that data based on the searchParams retrieved in the Search parent; it displays the resulting data and its children.
CounterDisplay is a client component that displays the counter value from the CounterProviderContext.

The Next.js documentation refers to this nested pattern as “interleaving” server and client components.

But how is it that we can nest a server component within our client components?

Recall that React Server Components are just serialized vDOM sent over the network. So as long as the content in the React tree is serializable, it can be handled without issue by your bundler.

In this case, the ToDoList server component is serializable specifically because it is a child of its client component wrapper. Children of a React component are really just props – and props are serializable!

Here’s what the rendered components look like.

There are a couple other little tidbits we can glean from the interleaved components.

You Can Still Use Contexts (Carefully)

In Next.js v13+, all components are server components by default and cannot use state hooks like useState, useEffect, or useContext.

Client components operate exactly the same as before and can use state hooks. For example:

"use client";

type CounterProviderValue = {
  counterVal: number;
  setCounterVal: Dispatch<SetStateAction<number>>;
};

export const CounterProviderContext: React.Context<CounterProviderValue> =
  createContext<CounterProviderValue>({
    counterVal: 0,
    setCounterVal: () => {},
  });

export const CounterProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [counterVal, setCounterVal] = useState(0);

  return (
    <CounterProviderContext.Provider value={{ counterVal, setCounterVal }}>
      {children}
    </CounterProviderContext.Provider>
  );
};

We declare CounterProvider as a client component with the use client directive at the top of the file. This directive is how the bundler identifies CounterProvider as a client component and treats it accordingly in the RSC payload.

We can use useState in CounterProvider only because we’ve declared it as a client component.

Similarly, we can access the counterVal and setCounterVal in child components, but only if those children are client components.

"use client";

const SearcheableToDoList: React.FC<PropsWithChildren> = ({ children }) => {
  const { counterVal, setCounterVal } = useContext(CounterProviderContext);

  return (
    <div className="flex flex-col gap-2">
      <div className="flex gap-2">
        <button
          className="bg-white text-black"
          onClick={() => setCounterVal(counterVal + 1)}
        >
          Counter
        </button>
        <CounterDisplay />
      </div>
      <div className="flex flex-col gap-2">{children}</div>
    </div>
  );
};

export default SearcheableToDoList;

Because SearcheableToDoList is a client component, we can access counterVal and setCounterVal via useContext.

The same can be said of CounterDisplay. As long as it is declared as a client component, we can use counterVal and setCounterVal. That’s true even when CounterDisplay is a child of the ToDoList server component.

"use client";

const CounterDisplay = () => {
  const { counterVal } = useContext(CounterProviderContext);

  return <span>Count is {counterVal}</span>;
};

export default CounterDisplay;

You Can Use Server Code in Server Components

Server components are rendered on the server, so we can use any server side code we'd like! For instance, we can read from the file system in ToDoList to return the list of filtered to-dos.

import { promises as fs } from "fs"; // import included for clarity

type ToDoListProps = PropsWithChildren & {
  searchParams?: { [key: string]: string | string[] | undefined };
};

type ToDo = {
  id: number;
  heading: string;
  body: string;
  isFavorite: boolean;
};

const fetchData = async (searchParams: {
  [key: string]: string | string[] | undefined;
}) => {
  const file = await fs.readFile(`${process.cwd()}/src/app/data.json`, "utf8");
  const parsedJson = JSON.parse(file);
  const { data } = parsedJson;

  const headingSearch = searchParams["heading"] as string;

  const res = (data as ToDo[]).filter((item) =>
    item.heading.includes(headingSearch)
  );

  return res;
};

const ToDoList: React.FC<ToDoListProps> = async ({
  searchParams,
  children,
}) => {
  const data = await fetchData(
    searchParams as { [key: string]: string | string[] }
  );

  return (
    <div className="flex gap-4">
      <div className="flex flex-col gap-4">
        {data.map((item: ToDo) => (
          <div key={item.id} className="border border-white p-4">
            <h2 className="text-2xl">{item.heading}</h2>
            <p>{item.body}</p>
          </div>
        ))}
      </div>
      <div>{children}</div>
    </div>
  );
};

export default ToDoList;

When SearchField updates the query parameters, the searchParams passed to Search are updated and passed to ToDoList. We then search the file system using fs.readFile and filter out the results based on the provided query parameters.

ℹ️ Sidenote: This works for our example, but there’s a bit of nuance here with Next.js caching behavior that may cause issues if you try something similar in production. Check out this GitHub discussion and the Next.js docs for more information.

After we’ve fetched our data and populated the component, the resulting RSC payload is streamed down to the client. Notably, this means that JavaScript used within your server component (including imports) does not get added to the bundle on your front-end!

For completeness, here’s the SearchField component code:

const SearchField = () => {
  const router = useRouter();
  const pathname = usePathname();

  const [searchText, setSearchText] = useState("");

  const searchTextTimeout: ReturnType<typeof setTimeout> = setTimeout(() => null, 500);
  const searchTextTimeoutRef = useRef<ReturnType<typeof setTimeout>>(searchTextTimeout);

  useEffect(() => {
    clearTimeout(searchTextTimeoutRef.current);

    // this is just a debounce so we don't update query params on every keystroke
    searchTextTimeoutRef.current = setTimeout(() => {
      router.push(
        !!searchText?.length ? `${pathname}/?heading=${searchText}` : pathname
      );
    }, 500);
  }, [searchText, searchTextTimeoutRef, router, pathname]);

  return (
    <div>
      <input
        className="text-black"
        onChange={(e) => setSearchText(e.target.value)}
      />
    </div>
  );
};

What Are the Advantages of React Server Components?

Using server components means your JavaScript bundle size will not scale with the size of your codebase. Couple this with the fact that server components don’t require hydration and you get a shortened time-to-interactive and a reduction in page load times.

That reduced bundle size means client machines don’t need to download as much JavaScript. Additionally, executing JavaScript on the server is often more efficient for the end-user than executing it on the client (especially for mobile devices). Both of these points lead to improved user experiences for Next.js v13 and up.

Another interesting point is that executing fetches on the server can allow developers to more easily leverage caching. Next.js already handles caching out-of-the-box and I’m curious to see if the wider adoption of RSC reduces the need to combine React with solutions like Apollo Server and Apollo Client. While there are other benefits to these tools, RSC could provide similar caching behavior without the need to invest in a GraphQL solution.

Combining React Server Components and Suspense (along with traditional SSR) should also go a long way toward improving interaction to next paint (INP) for Next.js applications.

📣 Important: As state above, RedwoodJS very recently added RSC support. That team also emphasized the overlap in functionality between RSC and GraphQL.

What are the Disadvantages of React Server Components?

The main disadvantage of React Server Components, in my mind, is the significant increase in complexity.

A portion of this complexity should fade as React developers get accustomed to the new patterns necessitated by RSC. But as currently implemented, I do think RSC reduces the overall ergonomics of React – especially on any page with multiple nested client/server components and contexts.

Another disadvantage lies with RSC support. Since Next.js is the only framework supporting React Server Components, you’re stuck with it for now. And since Next.js works best when deployed to Vercel, some might also argue that narrows your choice of hosting providers.

Outside of JavaScript frameworks, there is a known issue with CSS-in-JS libraries including emotion and styled-components. That problem isn’t insurmountable, but will complicate incremental adoption for large, established code bases. Poor server component support by other libraries will also have a similar effect.

Are React Server Components Production Ready?

My answer here would be a solid “yes, but…”.

If you’re using Next.js or plan to use Next.js, then React Server Components are production ready. There are definitely rough edges in the Next.js implementation, but I don’t think that’s a show stopper.

That being said, I suspect that greenfield projects will have an easier time adopting RSC since they can pick and choose compatible libraries. Established codebases may find it very time consuming to update their existing code to cooperate with RSCs, especially given the dearth of libraries supporting it.

ℹ️ Sidenote: If you want more insight on this, check out Are we RSC yet?.

If you are not using Next.js and do not plan to, I would personally advise against implementing RSC into production code until support has improved.

Open Questions About React Server Components

In writing this article, I began forming some questions that I don’t yet have the answer to. These include:

How much will the combination of React Forget and React Server Components improve React performance overall? Will they impact or compliment one another at all?
How will React Server Components work with Expo and React Native?
How does Turbopack fit into this? Will it bring RSC functionality to other frameworks?

If you know anything about these topics, please feel free to let me know! I’d love to learn from you.

Further Resources and Special Thanks

Thanks for sticking with me until the end of a long article! Here are a few additional resources I came across if you’d like to learn more about React Server Components:

I’d also like to extend my thanks to multiple people who provided feedback and pointed me toward resources while writing this article. Thank you for the help and I hope this was an enjoyable read!

Learn more about how The Gnar builds React applications

Creating Passkey Authentication in a Rails 7 Application

Royce Threadgill — Wed, 27 Mar 2024 17:39:10 +0000

If you're looking to allow your users to log into your Rails 7 app with passkeys, well searched.

This article is specifically about passkeys, which are a form of passwordless login that replaces passwords with secure, per-device keys (the eponymous passkeys) which are handled by the device's operating system.

As of this writing, up-to-date Windows, macOS, iOS, and Android all support passkeys. Linux users with the correct browser or browser extension can also use passkeys.

This widespread support is due to the standard called FIDO2, which covers two components: WebAuthn and CTAP2. WebAuthn handles communication between a relying party (your app) and a credential provider (we'll use Bitwarden's Passwordless.dev), while CTAP2 handles key management and communication between the browser and the operating system.

We won't need to worry about either of these standards, since using Bitwarden as a passkey provider means we can use their open-source library to handle the details.

Rails 7 Passkey Authentication Example

Now that we have a concept for what passkey auth is and how it works, let's implement it in a Rails app. You can find the repo for our example at https://github.com/JackVCurtis/devise-passkeys-example.

We are going to implement a passwordless strategy using Devise. For the uninitiated: Devise is an authentication gem commonly used in Rails applications. It provides several off-the-shelf strategies which abstract the core concepts typically encountered in conventional web authentication.

The core functionality of Devise focuses on the username/password authentication paradigm. Here we will add a custom strategy to Devise using passkeys rather than username/password.

As we mentioned earlier, Bitwarden (specifically Passwordless.dev) is a passkey provider which manages both sides of the passkey management flow (WebAuthn and CTAP2). The first step of our process is to create an account and an application with Passwordless.dev.

You will be given three values: An API URL, an API private key, and an API public key. Create a .env file and provide these values:



BITWARDEN_PASSWORDLESS_API_URL=
BITWARDEN_PASSWORDLESS_API_PRIVATE_KEY=
BITWARDEN_PASSWORDLESS_API_PUBLIC_KEY=

Set up your database and run the app locally:



rails db:create
rails db:migrate
rails s

Install Devise and associate it with a User model. I recommend removing the password field before running the migration; otherwise Devise will create an automatic presence validation on the password, which we will not be using.

The migration file that Devise generates, after we have removed the password field, should look something like this:



# frozen_string_literal: true

class DeviseCreateUsers < ActiveRecord::Migration[7.1]
  def change
    create_table :users, id: :uuid do |t|
   ## Passkey authenticatable
      t.string :email,              null: false, default: ""

   ## Rememberable
      t.datetime :remember_created_at

      ## Trackable
      t.integer  :sign_in_count, default: 0, null: false
      t.datetime :current_sign_in_at
      t.datetime :last_sign_in_at
      t.string   :current_sign_in_ip
      t.string   :last_sign_in_ip

      ## Confirmable
      t.string :unconfirmed_email
      t.string   :confirmation_token
      t.datetime :confirmed_at
      t.datetime :confirmation_sent_at

      t.timestamps null: false
    end

    add_index :users, :email,                unique: true
    add_index :users, :confirmation_token,   unique: true
  end
end

Install the Bitwarden Passwordless.dev JS client using your choice of package manager. The example uses import-maps.

Add our custom passkey Devise module and strategy under the lib/devise directory.

lib/devise/models/passkey_authenticatable.rb:



require Rails.root.join('lib/devise/strategies/passkey_authenticatable')

module Devise  
    module Models  
        module PasskeyAuthenticatable  
            extend ActiveSupport::Concern  
        end  
    end
end

lib/devise/strategies/passkey_authenticatable.rb:



module Devise
  module Strategies
    class PasskeyAuthenticatable &lt; Authenticatable
      def valid?
        params[:token]
      end

      def authenticate!
        token = params[:token]
        res = Excon.post(ENV['BITWARDEN_PASSWORDLESS_API_URL'] + '/signin/verify', 
          body: JSON.generate({
            token: token
          }),
          headers: {
            "ApiSecret" =&gt; ENV["BITWARDEN_PASSWORDLESS_API_PRIVATE_KEY"],
            "Content-Type" =&gt; "application/json"
          }
        )

      json = JSON.parse(res.body)
      if json["success"]
        success!(User.find(json["userId"]))
      else
        fail!(:invalid_login)
      end
    end
  end
end

Warden::Strategies.add(:passkey_authenticatable, Devise::Strategies::PasskeyAuthenticatable)

Generate the Devise controller for sessions and configure your routes.

config/routes.rb:



devise_for :users, controllers: {
  sessions: "users/sessions"
}

Replace app/controllers/users/sessions.rb with the following:



# frozen_string_literal: true

class Users::SessionsController < Devise::SessionsController
  before_action :configure_sign_in_params, only: [:create]

  protected

  def configure_sign_in_params
    devise_parameter_sanitizer.permit(:sign_in, keys: [:token])
  end
end

Create a Stimulus controller at app/javascript/controllers/passwordless_controller.js:



import { Controller } from "@hotwired/stimulus"
import { Client } from '@passwordlessdev/passwordless-client';


export default class extends Controller {
  static targets = [ "email" ]

  connect() {
    this.client = new Client({ apiKey: window.VAULT_ENV.BITWARDEN_PASSWORDLESS_API_PUBLIC_KEY });
    this.csrf_token = document.querySelector('meta[name="csrf-token"]').content
  }

  async register() {
    const email = this.emailTarget.value
    const { token: registerToken } = await fetch('/api/registrations', {
      method: 'post',
      headers: {
        'content-type': 'application/json'
      },
      body: JSON.stringify({
        email: email,
      })
    }).then(r => r.json())

    const { token, error } = await this.client.register(registerToken)

    if (token) {
      await this.verifyUser(token)
    }

    if (error) {
      console.log(error)
    }
  }

  async login() {
    // Generate a verification token for the user.
    const { token, error } = await this.client.signinWithAlias(this.emailTarget.value);

    if (token) {
      await this.verifyUser(token)
    }
  }

  async verifyUser(token) {
    const verifiedUser = await fetch('/users/sign_in', {
      method: 'post',
      headers: {
        'content-type': 'application/json'
      },
      body: JSON.stringify({
        token,
        authenticity_token: this.csrf_token
      })
    }).then((r) => r.json());

    if (verifiedUser.id) {
      window.location.reload()
    }
  }
}

And insert the controller in the HTML at app/views/users/new.html.erb:



<h1>Sign Up</h1>

<% if current_user %>
  <h2>You're logged in!</h2>

  <%= button_to(
          "Log Out",
          destroy_user_session_path,
          method: :delete
        ) %>
<% else %>
  <div data-controller="passwordless">
    <input data-passwordless-target="email" type="email">

    <button data-action="click->passwordless#register">
      Create Account
    </button>

    <button data-action="click->passwordless#login">
      Log In
    </button>
  </div>
<% end %>

Navigate to your new combined signup/login page and test it out!

Contributors:

Learn more about how The Gnar builds Ruby on Rails applications.

DevSecOps 101: What is DevSecOps?

Royce Threadgill — Sat, 27 Jan 2024 05:49:10 +0000

DevSecOps vs. DevOps

Though there is overlap between Development Security Operations (DevSecOps) and Development Operations (DevOps), they are two distinct topics.

So, what is the difference between DevOps and DevSecOps?

Let's first start by defining DevOps. Roughly speaking, I see DevOps as the practice of using automation to turn code (“development”) into deployments on real infrastructure (“operations”) automatically.

On the other hand, we can define Dev_Sec_Ops as the integration of security tooling into the CI/CD pipeline to enforce security at each stage of the development and release process.

If you have a CI/CD pipeline, you’re implementing DevOps. If you run Brakeman during CI/CD, you’re implementing DevSecOps.

DevSecOps as Company Culture

For a deeper dive, I really like this description of DevSecOps by Snyk. It's worth noting that Snyk’s DevSecOps definition along with the one from RedHat both use the word "culture" in characterizing the practice.

It's not a mistake or a hyperbole; embracing DevSecOps demands moving beyond the old "set it and forget it" mentality. You are probably already adopting DevSecOps at some level; you just may not be doing a satisfactory job yet.

Adopting DevSecOps means embracing the additional responsibility that software security requires. It means using - and understanding - the relevant DevSecOps tools for each stage of the security lifecycle.

It's a bit of a paradigm shift; many software devs still consider security outside of their job description, and fairly so. But as security moves more and more into the software development lifecycle (which is now fairly married to the deployment lifecycle), it is necessary that all parties involved in that lifecycle be conversant with the security implications of their work. Christophe Limpalair at Spacelift puts it nicely:

"...most people view security as an annoyance and as something that adds extra friction to the development and deployment process. Instead of accepting that and putting security on the back burner, DevSecOps brings security back to the forefront by saying “you know what, security is critical and must be part of our process, so let’s make it fit in as painlessly as possible."

It's an elephant, but once we break it down we should see that each bite is manageable.

The US Department of Defense (DoD) does a very nice job of visualizing the DevSecOps lifecycle:

Read more in the DoD Enterprise DevSecOps Strategy Guide.

There are many similar diagrams online, but I find the DoD's to be the most clear and consumable.

So what do each of these steps mean? Let's break them down a bit.

Plan: Threat Analysis

List all assets that need to be protected (user devices, servers, developer devices), the actors they need to be protected from (ransomware gangs, “hacktivists”, advanced persistent threats like North Korea’s Lazarus Group), and the vulnerabilities those actors could exploit (unauthorized data access, server access, cross-site scripting, compromised SSL certificates).

A threat analysis plan is often articulated in a threat analysis chart like this one from Network Analysis, Architecture, and Design.

Develop: Secure Coding; Security as Code

Ensure that developers know the best practices around their language and framework (Ruby on Rails, React Native, etc.). Automate your security tooling using infrastructure as code.

Learn more by reading Snyk’s article on secure coding practices and GitLab’s security-as-code guide.

Build: Static Application Security Testing (SAST)

Analyze your source code for any recognizable weaknesses with SAST tools. This is language- and framework-specific. SAST runs as part of your build pipeline. Examples:

Bundler Audit (ruby)
Brakeman (Ruby on Rails)
NPM Audit (JavaScript)
Sobelow (Phoenix Framework)

Test: Dynamic Application Security Testing (DAST)

Actively scan for exploitable weaknesses. DAST software runs against a test environment. This is language-agnostic testing, usually for web applications. ZAP is a good example of DAST software.

Test: Penetration ("Pen") Testing

Bring on dedicated specialists to attempt to hack a test environment with a variety of tools, and provide a report of vulnerabilities after doing so. There are many consulting firms which provide pen test services.

Snyk’s penetration testing guide is a good introduction to penetration testing concepts.

Release: Digitally Sign

Use cryptographic signatures to verify that source code is unmodified from the version published by the source domain/package maintainer. If someone were to manipulate the file containing your program to include malicious code, this would be detected by a signature verification tool.

Deliver: Secure Transfer

Ensure that your code is deployed via an encrypted and secure connection. Most cloud platforms will do this automatically.

If using containers, ensure that the container registry and container image is secure using tools like Clair.

Deploy: Security Config, Security Scan

Define and configure your infrastructure using infrastructure as code tools like AWS CDK.

Scan that infrastructure with a tool like Cloudsploit (Multicloud), KubiScan (Kubernetes), or Amazon Inspector (AWS). Like SAST tools, the tools you choose will be specific to your platform.

Operate: Security Patch

Continually patch your code to the latest version. Use tools like dependabot and bundler-audit.

Monitor: Security Audit, Security Monitor

Continuously assess the security of your application's data. This step is best considered after you understand what it is you are monitoring (see everything above). This sounds obvious, but plenty of devs hook up a monitoring system without really knowing what is being monitored.

In addition to monitoring the software processes, a security audit should also review the user processes, i.e. how users access and share data within and outside of the application.

Shout out to Wazuh as a comprehensive monitoring/dashboard tool, while AWS has Amazon Security Hub. For auditing there’s a wide range of options, but TechTarget’s security audit guide is a good place to start.

Conclusion

Investing in a legitimate DevSecOps strategy at your organization is certainly no small investment, in time or resources. But it is a very surmountable challenge.

If we break the process down as above and become comfortable with each step of the process, we can weave these security practices into the existing fabric of our software lifecycle.

And if there is any question about whether this venture is worth the time or resources it demands, I would point you to research into the savings a company will realize by investing in a DevSecOps strategy.

If you're interested in jumping into DevOps or DevSecOps, or if you are already on your way and would like some feedback, shoot us a line. We'd love to hear from you.

Contributors:

Learn more about how The Gnar builds software.

Gnarly Learnings from December 2023

Royce Threadgill — Thu, 11 Jan 2024 06:01:14 +0000

At The Gnar, we’re always reading, watching, and listening in order to keep our skills sharp and our perspectives fresh. Every month, we round up our learnings and publish them in a Gnarly Learnings blog post.

In December 2023, we learned about AI applications in finance roles, strategies for top converting landing pages, and Static Hermes. We also pondered how the combination of Rails and Hotwire can be used to replace some of the functionality previously provided only by React.

Business Applications of AI

McKinsey recently published a brief generative AI guide for CFOs on how and where to integrate gen AI solutions into finance roles.

The writers posit that generative AI can help automate tedious tasks, augment productivity, and accelerate data extraction, potentially increasing the velocity of innovation.

Gen AI can be an important tool for value creation. CFOs should strive to be gen AI enablers, not gatekeepers, and make sure that strategically critical initiatives rapidly and continually receive necessary resources.

Meg McFarlane recently published a Think With Google article discussing the benefits of AI-based advertising strategies.

In a single case study, they found a 36% increase in unique reach, 45% drop in cost, and 30% higher average impression frequency per user by switching YouTube ad strategy to lean more heavily on Google’s AI ad optimization.

Where in the past we’d have to do a lot of guesswork to determine the ideal rotation between in-stream and bumper ads, we now let the Google AI decide how often each ad was shown and to whom.

Ecommerce Web Design

In a February 2023 podcast, Logan Grasby discusses the design of top converting landing pages. He goes into detail about the anatomy of a landing page, discussing the purpose of each section and tips for improving marketing performance.

You can find a summarization of his key points starting around 25:30 in the podcast.

Russ Maschmeyer, product lead for spatial commerce at Shopify, discusses a suite of AI tools called Shopify Magic in a recent episode of Practical AI. The tools can help you with a variety of tasks, from generating product descriptions to generating product imagery.

Design

In December of 2023, we came across two sites – Addifico and ai-chat – that present their business and value proposition with eye-catching, interactive websites.

Mobile App Development

Hermes, the JavaScript engine built and maintained by Meta, is already fine-tuned for running fast React Native applications. But in the presentation “Static Hermes: The Next Generation of Hermes”, Tzvetan Mikov explains how JavaScript can be compiled to achieve huge leaps in performance.

[15:00] When we started compiling it to native initially, it was the same performance as Hermes…but now as you can see, it is 10x faster when compiled natively…plus we’re certain that there is more headroom. We can probably get to 20x times faster than Hermes.

Tzvetan reports 10x faster performance over traditional Hermes in one benchmark.

He also emphasizes that native compilation unlocks “the possibility of very efficient native platform integration”, estimating that call overhead could be between 15x and 18x lower than JSI when calling a native function. This “zero-cost FFI” ultimately opens up the possibility to implement platform integrations “entirely in JavaScript” with “practically no cost, just as if we were a C program”.

If you’re interested in learning more about Static Hermes, Tzvetan created a blog post discussing how to speed up a micro-benchmark by 300x using Static Hermes.

Gaurav Gautam also wrote a blog post about compiling TypeScript to native code, which Tzvetan discussed in a GitHub thread. That same GitHub thread yielded this remarkable result from the bunnymark benchmark:

Runtime	FPS	CPU	GPU	Memory
C	90	68%	84%	48 MB
Static Hermes	90	70%	84%	53 MB

Tech Insights

The tech world evolves incredibly fast, so it’s important to stay on top of new strategies for building applications.

It’s our belief that the Hotwire family of products, including the well-known Turbo and Stimulus, provide a compelling alternative to React for many types of applications.

Learn more by reading our blog post, “Ruby on Rails vs. React: Hotwire + Turbo Change the Equation”.

Gnarly Bytes

GraphQL: This OWASP Cheat Sheet for GraphQL is a great summary of best practices
Elixir: Notesclub is a collection of Elixir Livebooks
Artificial intelligence: Ollama provides a bunch of AI models you can run locally; Fly.io also created a blog post discussing how to run Ollama models on Fly
Ruby: Ruby on Jets is an interesting Ruby serverless framework for building and deploying APIs to AWS lambda
Libraries: We discovered Spotlight, a library pitched as “Sentry for Development” (the library is created by Sentry), aims to provide a rich debugging experience during development

Contributors:

Learn more about how The Gnar builds software.

Bun JavaScript Runtime First Look

Royce Threadgill — Tue, 17 Oct 2023 12:00:00 +0000

When I first heard about the Bun project, I honestly thought it was overambitious to the point of obvious failure. You know the projects I’m talking about – the ones that promise the world but never reach fruition, leaving their early adopters to twist in the wind.

But here we are: Bun 1.0. And by all accounts, the Bun JavaScript runtime has achieved its original goals.

In this article, we’re going to discuss Bun’s features, as well as its history and future. Since the Bun team claims that their product is a drop-in replacement for Node.js, we’ll also examine a non-trivial example of replacing Node.js with Bun in a pre-existing project.

What Is Bun?

Bun is a new JavaScript runtime developed by a company called Oven (yes, really). The mastermind behind the project is Jarred Sumner, although at this point the company appears to have attracted a small team of developers.

On an episode of the PodRocket podcast, Jarred summarized Bun as:

[2:10] …an all-in-one JavaScript Runtime. It combines a bundler, a transpiler, a package manager, a script runner, all-in-one in addition to being a runtime. And so it comes with a TypeScript transpiler, JSX transpiler. And all of this is quite a bit faster than anything that exists today.

How Fast Is Bun?

To be clear, when Jarred says “quite a bit faster”, he means many times faster than other prominent JavaScript runtimes such as Node.js and Deno.

One benchmark on the Bun website compares the HTTP requests per second processed by Bun, deno.serve(), and Node.js. When comparing Bun vs. Node, Bun processed 5x as many requests per second; when comparing Bun vs. Deno, Bun processed 2x as many requests per second.

Another benchmark asserts that yarn install runs 33x slower than bun install.

Yet another benchmark asserts that tests in a Jest/Babel configuration would run 20x slower than Bun’s test runner.

Of course, we all know that benchmarks can be misleading. I haven’t personally run the benchmarks provided by Bun, nor have I looked at the code to see if they make sense.

That being said, these claims have been backed up by some third-party testing. On our end, one of our talented software engineers has already looked into Bun and was very impressed with its speed compared to Node.js (more on his experience later).

How Is Bun So Fast?

According to Jarred Sumner, there are really two major contributors to Bun’s comparative speed: (1) use of the JavaScriptCore engine over V8 and (2) use of the Zig language for building the transpiler and runtime.

JavaScriptCore is the JavaScript engine built by Apple for Safari, while V8 is the engine built by Google for Chromium-based web browsers. I can’t speak much to their relative speed, nor have I heard Jarred or the Bun team discuss the benefits of JavaScriptCore in great detail.

The choice to use Zig, on the other hand, seems like a slam dunk for performance. Bun documentation claims the use of Zig results in a 4x faster startup time for Bun vs. Node when running scripts.

Frankly, I hadn’t heard of Zig prior to learning about Bun several months ago. It’s a relatively young language, but seems well-suited to building products like Bun based on Jarred’s statements:

[4:12] Zig is really good for this type of systems programming to do it as quickly as possible while also not going crazy because it's a low level systems' language with manual memory management. By its nature, without garbage collection, things are a little bit harder, but Zig does a really good job of making it easier than it would be otherwise in C.

Is Bun Production Ready?

By releasing version 1.0, the team is declaring that Bun is production ready.

Speaking on the JavaScript Jabber podcast, Jarred stated there are already “companies using it in production” with a “decent amount of traffic in some cases”.

That’s not to say that Bun is flawless. The host of that podcast – which aired May 30, 2023, only three months before 1.0 – mentioned that he had encountered several issues when attempting to use Bun.

Of course, Jarred assured the host that progress was being made on many known issues.

My personal opinion? Bun is ready for production use, so long as you’re willing to tackle the weird compatibility issues and edge cases that inevitably arise when using bleeding edge technology.

So the question really should be: do the pros of adopting Bun outweigh these inconveniences?

Why Should You Switch to Bun?

There are a few benefits to Bun that jump out at me:

Do you have a giant test suite that takes a long time to run? Adopting Bun will reduce the time to run that test suite, which can save CI/CD dollars and developer time.
Do you run serverless JavaScript functions? Switching over to Bun will reduce cold start and execution times.
Do you like TypeScript and want it to work out-of-the-box? Bun can directly execute .ts and .tsx files with no additional configuration.
Do you want to reduce your dependencies and simplify bundling? Bun can probably help. If you like languages such as Go that have rich standard libraries, Bun brings some of that ethos to the JavaScript world by including its own bundler and package manager.

Aside from directly reducing costs via faster execution time, Bun’s performance has the potential to increase developer productivity. By reducing the amount of time that developers spend waiting on test suites to run, for instance, you also reduce the time needed to iterate on those tests.

And lastly, the improved developer experience of having an all-in-one product shouldn’t be underestimated. How much time have you invested messing with webpack configurations or troubleshooting a Jest upgrade? Grouping these disparate elements of JavaScript development within a single, batteries-included framework should help mitigate these sorts of problems.

What Is the Future of Bun?

Jarred envisions a future in which Bun facilitates fast server-side JavaScript rendering. This certainly agrees with the recent shift back to server-side rendering, as embodied by the changes introduced in Next.js 13 and the creation of React Server Components.

Jarred discusses this concept in his PodRocket interview:

[7:00] Bun will eventually have a production transpiler API/bundling API. And I think what people will do with that is they will actually bundle and transpile in network requests. And so for that, you need it to be really fast. But the reason why I think people will do that is because it's going to enable a lot of new kinds of plugin systems where you have this dynamic code generation and you do server-side JavaScript rendering. Similarly you do server-side HTML rendering. But if you can embed the data…it'll let people delete a bunch of code.

This use-case for Bun seems supportive of the so-called islands architecture (a phrase popularized most recently by Astro). If you’re unfamiliar with this concept, the main gist is: since web pages are largely static content, only ship JavaScript when and where you need it.

More specifically, I can imagine a scenario in which a user submits data to a server and the server responds by creating data-specific JavaScript which is bundled and sent back to the client as part of an interactive page element.

That sort of client/server interaction ensures you’re only sending the JavaScript you need to the client – and that the JavaScript you send has the smallest footprint possible.

I don’t think the value proposition for this sort of system is lost on Jarred and Bun, either. In his interview with JavaScript Jabber, Jarred mentions that he aims to eventually offer “really fast edge hosting for Javascript specialized cloud” as a commercial product.

And in his PodRocket interview, he also highlights that Oven wants to create a version of Bun specifically for edge computing:

[16:07] …one of the things we'll focus on is specifically [a] version of Bun for the edge. It will have single file deploys. And it'll do this really efficiently because it'll use a binary bundling format to turn it all into one compact file.

So based on these comments, I anticipate we’ll see Oven create something like Deno Deploy for the Bun ecosystem in the not-too-distant future.

Is Bun a Drop-In Replacement for Node.js?

Whenever a new project bills itself as a “drop-in replacement” for an existing tool, I’m immediately suspicious. In my experience, there’s usually some big issue that pops up soon after adopting these sorts of solutions.

Luckily, one of our Gnarnians has already looked into this! Alex Jarvis recently converted his randsum-ts library from Node.js to Bun and generously agreed to share his takeaways from the experience.

Firstly, let’s establish that his library itself isn’t extremely complicated. Alex states that it “has no databases, no HTTP calls, just logic and exhaustively-thorough TypeScript”.

But if you look at the library, I’m sure you’ll quickly notice that it’s a pretty far cry from a “hello, world” application. This is a production-ready, pre-existing project, making it a fantastic opportunity for putting Bun’s “drop-in replacement” claims to the test.

More importantly, this wasn’t just an experiment for Alex. He saw legitimate benefits in Bun and wanted to leverage those benefits in his project:

I have played with a number of different workflows and build scripts – rollup , parcel, straight-up tsc – and had lost my head a few times working my way around cjs vs. esm. What I wanted was a little existential stability in my workflow – something to put my back against. When I heard of Bun’s built-in (lightning fast) bundler and saw it operated with first-level TypeScript support, I decided to try my hand at converting from a yarn/node backed project to being one run on bun.

If you’ve lived in the JavaScript world for a while, this is probably a familiar sentiment. My hope is Bun helps to smooth out developer experience by avoiding these sorts of headaches.

Replacing Node.js with Bun was fairly straightforward, though Alex mentioned it did involve “a small amount of re-architecturing”. To be fair, I expected that changing the JavaScript runtime for an existing project would be an outright nightmare; his experience seemed positively seamless by comparison.

He did, however, highlight testing as a pain point during adoption:

The biggest headache was the test suite, where a few useful / mission critical things are not yet implemented when compared to the modern jest suite (while I can live without expect.arrayContaining, it is a slightly more annoying existence) With some creative dependency injection and well-architected tests, this was easy to get around.

That said, Alex seemed genuinely impressed with the results once he was done. He stated his test suite and build script ran “instantly” after the switch, which serves as yet more validation of Bun’s impressive performance claims.

Alex additionally pointed out an interesting benefit to Bun’s TypeScript support that hadn’t occurred to me:

There is already a plugin ecosystem developing (making it easy for my build script to also spit out a d.ts file). Being able to REPL one of my TypeScript files natively has really opened up my debugging possibilities.

So is Bun a drop-in replacement for Node.js? I’ll let you come to your own conclusion on that. But from my perspective, Alex’s experience is a solid endorsement of that claim.

Metaprogramming in Ruby: Beginner Level

Royce Threadgill — Fri, 30 Dec 2022 22:22:37 +0000

This post is the first in a series focused on the application of Ruby metaprogramming. If you’re just starting to learn about metaprogramming, this is a great place to get started. For those who already know the basics, stay tuned for future installments that will cover intermediate and advanced topics.

Metaprogramming is a phrase you’ve probably heard once or twice in your career. Some may have uttered it with reverence and others may have flown into an apoplectic fit of rage at the very mention of it. In this article, we’ll discuss the basics of Ruby metaprogramming so that you can decide for yourself how and when to use it.

Ruby Metaprogramming Questions: What is it?

Generally speaking, metaprogramming is the art and science of creating a piece of code that generates more code for you. This can be useful if you have recurring logic that you want to DRY (i.e., Don't Repeat Yourself) out. Let’s look at an example:

class Truck
 attr_accessor :is_used

 def initialize(is_used:)
   @is_used = is_used
 end

 def Truck_condition?
   @is_used ? 'used' : 'new'
 end
end

class Sedan
 attr_accessor :is_used

 def initialize(is_used:)
   @is_used = is_used
 end

 def Sedan_condition?
   @is_used ? 'used' : 'new'
 end
end

In the above code, we have two classes, Truck and Sedan, with very similar logic but slightly different method names: Truck_condition and Sedan_condition (we’re breaking a couple of Ruby naming conventions here for the sake of illustration). Instead of repeating ourselves, we could programmatically generate these methods using Ruby metaprogramming.

But why wouldn’t we simply refactor these classes and get the same result by inheriting from a parent class? Well, that leads to our next question….

Ruby Metaprogramming Questions: When is it Useful?

When you introduce metaprogramming into your code, you start to create complexity that may confuse other developers later on – especially if they didn’t work directly on that code. In most examples like the one given above, you can and should favor simple inheritance.

That being said, here are a handful of cases in which metaprogramming might come in handy:

If you’re working with data that doesn’t easily map to a database (e.g., calling a method whose response varies with time)
If you’re working on a well-aged Rails monolith and you’re worried that refactoring could break something critical in the application
If you’re purposefully trying to obfuscate the underlying Ruby code for a specific use-case (more on that later)

Metaprogramming is very powerful, but the truth is that it’s often overkill for the task at hand. It’s like when the Ikea manual firmly instructs you to hand-tighten, but you decide to grab your drill driver: We all want to take the opportunity to play with our power tools, but we’ll probably just end up breaking the furniture.

Ruby `define_method`

One of the most important methods in Ruby metaprogramming is define_method. Here’s a basic example:

class VehicleClass
 def initialize(is_used:)
   @is_used = is_used
 end

 define_method('Truck_condition') do
   @is_used ? 'used' : 'new'
 end

 def is_used
   @is_used
 end
end

This would create a method Truck_condition on VehicleClass that would return “used” if is_used == true and “new” otherwise.

Ruby `define_method` With Arguments

You can pass arguments to methods created via define_method. We’ll go over this in more detail in the upcoming example, but here’s an isolated code snippet:

define_method('Truck_report') do |name|
  "Car is used. Report made for #{name}"
end

In this example, we create a method Truck_report. When we call that method, we can pass in a string name that is added to the response. So calling Truck_report('Alex') would generate the string, “Car is used. Report made for Alex”.

Implementing `attr_reader` with `define_method`

You may have also noticed that we defined a getter method for the is_used value. It’s not common to see this kind of syntax because we could use attr_reader instead. As a practical example, let’s use define_method to create our own custom attr_reader so that we no longer need a getter method in this class.

class Class
 def custom_attr_reader(*attrs)
   attrs.each do |attr|
     define_method(attr) do
       instance_variable_get("@#{attr}")
     end
   end
 end
end

class VehicleClass
 custom_attr_reader(:is_used)

 def initialize(is_used:)
   @is_used = is_used
 end

 define_method('Truck_condition') do
   @is_used ? 'used' : 'new'
 end
end

We define custom_attr_reader on Class, which all Ruby classes inherit from. Calling custom_attr_reader(:is_used) within VehicleClass creates an @is_used method. This means that VehicleClass.is_used is now available for all instances of VehicleClass without the need for a getter method, serving a similar function to attr_reader.

Ruby Metaprogramming Example

With that out of the way, let’s go over a basic metaprogramming example using Ruby 3.1.0 and ActiveSupport::Concern.

In this example, we’re creating a VehicleClass that should have a variety of car-specific methods. These methods will be built programmatically with Ruby define_method and included in VehicleClass. To begin, let’s define a “builder” method that will build the “vehicle condition” methods we worked with above.

module VehicleBuilder
 extend ActiveSupport::Concern

 included do
   def self.build_vehicle_methods(vehicle_type:, is_used:)
     condition_method_name = "#{vehicle_type}_condition"

     define_method(condition_method_name) do
       is_used ? 'used' : 'new'
     end
   end
 end
end

module VehicleHelper
 extend ActiveSupport::Concern

 include VehicleBuilder

 included do
   build_vehicle_methods(
     vehicle_type: 'Truck',
     is_used: true,
   )
   build_vehicle_methods(
     vehicle_type: 'Sedan',
     is_used: false,
   )
 end
end

class VehicleClass
 include VehicleHelper
end

The build_vehicle_methods class will accept vehicle_type and is_used arguments. The vehicle_type argument is used to define the name of the “vehicle condition” method, while is_used determines the response from that method.

We then call build_vehicle_methods within VehicleHelper, including our vehicle types and used/new status as arguments. By including VehicleHelper within our VehicleClass, we end up with the same methods defined earlier in the article: Truck_condition and Sedan_condition.

You can easily verify this with an Interactive Ruby session. Simply open your terminal and enter irb. On your first line, enter require "active_support/concern", then copy/paste the above code into your window. Once you’ve done that, create a new instance of VehicleClass and verify that you can call Truck_condition and Sedan_condition on that instance.

This approach is obviously a more roundabout way of defining those methods. But one advantage here is that you can build out new methods with consistent naming conventions by simply adding a new build_vehicle_methods call to VehicleHelper. That would be helpful if you have or plan to have a large number of “vehicle” classes; rather than copy/pasting a bunch of classes like Truck and Sedan, you can create them all within VehicleHelper and have guaranteed consistency.

And that advantage is compounded as the number of methods and complexity of logic increases. We can demonstrate by adding a few new methods to our VehicleBuilder:

module VehicleBuilder
 extend ActiveSupport::Concern

 included do
   def self.build_vehicle_methods(vehicle_type:, serial_number:, is_used:, damages:)
     report_method_name = "#{vehicle_type}_report"
     condition_method_name = "#{vehicle_type}_condition"

     define_method(condition_method_name) do
       is_used ? 'used' : 'new'
     end

     define_method(report_method_name) do |name|
       # The "condition" method for this vehicle isn't yet defined
       condition_attr = send(condition_method_name)

       "#{vehicle_type} (SN #{serial_number}) is #{condition_attr}. Report made for #{name}."
     end

     damages.each do |damage|
       damage_method_name = 
         "#{vehicle_type}_has_#{damage}_damage?"

       define_method(damage_method_name) do
         true
       end
     end
   end
 end
end

module VehicleHelper
 extend ActiveSupport::Concern

 include VehicleBuilder

 included do
   build_vehicle_methods(
     vehicle_type: 'Truck',
     serial_number: '123',
     is_used: true,
     damages: %w[windshield front_passenger_door]
   )
   build_vehicle_methods(
     vehicle_type: 'Sedan',
     serial_number: '456',
     is_used: false,
     damages: []
   )
 end
end

class VehicleClass
 include VehicleHelper
end

In the example above, we’re still generating the “condition” methods from above, but we’ve expanded the use of Ruby define_method to include (1) a “report” method and (2) multiple “damages” methods.

The “report” methods, Truck_report and Sedan_report, will generate report strings similar to those demonstrated earlier in the article. But that string includes the condition of the car – how do we get that condition if the condition method isn’t yet defined?

Ruby provides a send method that can address this problem. We can call Truck_condition and Sedan_condition from within the report-related define_method blocks using send(condition_method_name). While this particular example is a bit contrived, the ability to call as-of-yet-undefined methods is quite useful for Ruby metaprogramming.

Finally, the “damages” methods are created by looping over the damages array. In this example, that creates Truck_has_front_passenger_door_damage? and Truck_has_windshield_damage? methods that simply return true.

Ruby Metaprogramming Questions: Who Actually Uses This?

Earlier, we briefly touched on the “what” and the “when” of Ruby metaprogramming, but we didn’t discuss the “who”. If this is such a niche strategy, who actually uses it?

For guidance, we can turn to an oft-cited quote from Tim Peters, a major Python-language contributor, regarding Python metaprogramming: “[Metaclasses] are deeper magic than 99% of users should ever worry about”.

Regardless of the language(s) you work in on a day-to-day basis, metaprogramming is probably not a tool you’ll need to reach for often. There is a notable exception though: metaprogramming is perfect for designing a domain-specific language.

A domain-specific language (DSL) has its own classes and methods that obfuscate the underlying language they’re built with, reducing complexity and focusing on providing tools to accomplish specific tasks. Gradle is a good example of such a use-case; it takes advantage of Groovy metaprogramming to deliver a product focused solely on build automation.

Expanding upon this idea, anyone building a framework will likely find metaprogramming helpful (or even essential). Rails is one such framework built using the metaprogramming capabilities provided by Ruby. This can be illustrated by the Rails enum implementation; when you define an enum, the framework provides a variety of helpers out-of-the-box:

class Vehicle < ApplicationRecord
 enum :body, [ :truck, :sedan, :minivan, :suv, :delorean ], suffix: true
end

By defining body as an enum, we automatically gain access to boolean checks like Vehicle.truck? and status setters like Vehicle.sedan!. Providing the suffix: true config option can make these helpers more readable by appending the column name, yielding Vehicle.truck_body? instead of Vehicle.truck?. Database scopes are also generated for our enum, allowing us to retrieve all truck-body Vehicles with Vehicle.truck (and if you’re using Rails 6+, Vehicle.not_truck will return all Vehicles that do not have truck bodies).

This is Ruby metaprogramming at its best: taking Ruby code and augmenting it with human-readable, intuitive helpers for interacting with your database.

If this article piqued your interest, keep an eye out for the next installment in this series. In our intermediate level post, we’ll dive into some practical examples of Ruby metaprogramming for those of us not building the newest “blazingly fast” framework.

Learn more about how The Gnar builds Ruby on Rails applications.

Infinite Scroll React Example with TypeScript and NextJS

Royce Threadgill — Wed, 24 Aug 2022 14:10:00 +0000

For the uninitiated, infinite scroll (otherwise known as endless scroll) refers to a method of automatically loading data when a user scrolls to the bottom of their screen, allowing them to continue browsing content with minimal effort. If you’ve been in the front-end game since the good bad old days when jQuery was bleeding edge, that probably sounds like an irritating feature to build. However, with modern browser APIs and JavaScript libraries like React, it is orders of magnitude less painful to create this effect.

In this article, we’ll look at a few libraries that can facilitate infinite scroll in React. In case that’s not your style, we’ll also dive into an infinite scroll example that leverages the Intersection Observer API and NextJS, touching on infinite scroll SSR (server-side rendering) tactics that can help with search engine optimization.

Why Implement Infinite Scroll?

When loading a page, it’s generally preferable to load as little data as possible. This helps the page load faster, which improves user experience and search rankings.

If you have a large amount of data, you’ll need to split that data up to keep your page loading quickly. That’s where pagination strategies like infinite scroll come in. Pagination refers to the practice of fetching your data in small chunks (or pages), rather than retrieving all of your data at once.

Many websites implement pagination via page buttons, but infinite scroll is thought to reduce friction since it requires less user interaction. This makes infinite scroll a popular request from clients aiming to improve conversion on their websites. Infinite scroll is especially sought after in e-commerce applications, where getting eyeballs on products is of paramount importance for conversion rates.

Libraries to Facilitate React Infinite Scroll

If you prefer not to roll your own custom infinite scroll solution, there are many libraries that can simplify building the feature. Here is a non-exhaustive list of options:

react-waypoint: As far as ready-made solutions go, this is a personal favorite of mine. The library is simple to use and you can implement infinite scroll with little more than a Waypoint component and an onEnter handler. With 4,000 stars on GitHub as of August 2022, react-waypoint is far and away the most popular of the libraries listed here, though it’s also a more general-use library than its counterparts.
react-infinite-scroll-hook: This is another library that stood out from the crowd. I haven’t personally used it, but it seems to be more actively maintained than react-infinite-scroll-component. On top of that, it happens to weigh in at a paltry 1.8 kB minified bundle size, according to bundlephobia, which appeals to the minimalist in me.
react-infinite-scroll-component: I found this seemingly popular component in the course of my research for this article. I haven’t used it myself and can’t vouch for it, but it kept popping up so I felt I should add it to this list. It’s worth noting that as of August 2022, this library has 114 open GitHub issues; compared against react-infinite-scroll-hook (2 open issues) and react-waypoint (54 open issues), that’s a relatively high number of problems and could be cause for concern.

Custom Infinite Scroll with TypeScript and NextJS

For those that require (or desire) a custom solution, have no fear: it is surprisingly straightforward to DIY your own infinite scroll feature.

To help you get started, we’ll be guiding you through an example app that uses React, TypeScript, and NextJS. If you’re unfamiliar with NextJS, you can think of it as a specialized framework built on top of React itself. Don’t worry – a custom infinite scroll React solution is almost identical to a custom infinite scroll NextJS solution. The main reason I chose NextJS for this example was simply to highlight the interaction between server side rendering, infinite scroll, and search engine optimization.

Setting the Stage for our Infinite Scroll Example

Our sample app is a blog. When a user navigates to the home page of our app, they’re shown a set of blog posts; you can think of this as “page 1” of the blog. When a user reaches the bottom of the home page, more blog posts are loaded via an API call. It looks something like this:

Load the Initial Data

In this example, we’re going to use the getServerSideProps method from NextJS to get our initial data, then add that initial posts data to our Home component. After page 1 is loaded, we’ll make additional API calls and add the retrieved data to a dynamicPosts array.

// index.tsx (your home page)
export interface BlogPost {
 id: string;
 title: string;
 description: string;
}

export interface HomeProps {
 posts: BlogPost[];
}


export async function getServerSideProps() {
 const posts = [
   {
     id: uuidv4(), // creates a unique ID for the post
     title: "Blog post 1",
     description:
       "Lorem ipsum dolor sit amet consectetur adipisicing elit. Possimus quae numquam repudiandae ab asperiores exercitationem nulla, enim debitis necessitatibus quaerat incidunt nesciunt. Soluta sapiente quisquam magni, quas odit tempora ullam!",
   },
   // more data here
 ];

 return {
   props: {
      posts,
      total: 20
   },
 };
}

const Home: NextPage<HomeProps> = ({ posts }) => {
 const {
   isLoading,
   loadMoreCallback,
   hasDynamicPosts,
   dynamicPosts,
   isLastPage,
 } = useInfiniteScroll(posts);

 return (
   <HomePage
     posts={hasDynamicPosts ? dynamicPosts : posts}
     isLoading={isLoading}
     loadMoreCallback={loadMoreCallback}
     isLastPage={isLastPage}
   />
 );
};

export default Home;

This essentially means that page 1 of our blog is server-side rendered and should be accessible to search engine crawlers, while all additional data is retrieved client-side. You can use this hybrid infinite scroll SSR strategy if you want search engines to read the first set of data loaded on your infinite scroll website.

If none of that matters to you, you can think of this as a simple API call. Just remember that the data retrieved via that first client-side API call likely won’t be accessible to search engines.

Create Your Custom Hook

You probably noticed in the above example that there’s a custom hook called useInfiniteScroll. The vast majority of the logic governing infinite scroll behavior in this example can be found within that hook.

// useInfiniteScroll.ts
export interface UseInfiniteScroll {
 isLoading: boolean;
 loadMoreCallback: (el: HTMLDivElement) => void;
 hasDynamicPosts: boolean;
 dynamicPosts: BlogPost[];
 isLastPage: boolean;
}

export const useInfiniteScroll = (posts: BlogPost[]): UseInfiniteScroll => {
 const [isLoading, setIsLoading] = useState(false);
 const [page, setPage] = useState(1);
 const [hasDynamicPosts, setHasDynamicPosts] = useState(false);
 const [dynamicPosts, setDynamicPosts] = useState<BlogPost[]>(posts);
 const [isLastPage, setIsLastPage] = useState(false);
 const observerRef = useRef<IntersectionObserver>();
 const loadMoreTimeout: NodeJS.Timeout = setTimeout(() => null, 500);
 const loadMoreTimeoutRef = useRef<NodeJS.Timeout>(loadMoreTimeout);

 const handleObserver = useCallback(
   (entries: any[]) => {
     const target = entries[0];
     if (target.isIntersecting) {
       setIsLoading(true);
       clearTimeout(loadMoreTimeoutRef.current);

       // this timeout debounces the intersection events
       loadMoreTimeoutRef.current = setTimeout(() => {
         axios.get(`/api/posts/${page}`).then((resp) => {
           setPage(page + 1);
           const newPosts = resp?.data["posts"];

           if (newPosts?.length) {
             const newDynamicPosts = [...dynamicPosts, ...newPosts];
             setDynamicPosts(newDynamicPosts);
             setIsLastPage(newDynamicPosts?.length === resp?.data["total"]);
             setHasDynamicPosts(true);
             setIsLoading(false);
           }
         });
       }, 500);
     }
   },
   [loadMoreTimeoutRef, setIsLoading, page, dynamicPosts]
 );

 const loadMoreCallback = useCallback(
   (el: HTMLDivElement) => {
     if (isLoading) return;
     if (observerRef.current) observerRef.current.disconnect();

     const option: IntersectionObserverInit = {
       root: null,
       rootMargin: "0px",
       threshold: 1.0,
     };
     observerRef.current = new IntersectionObserver(handleObserver, option);

     if (el) observerRef.current.observe(el);
   },
   [handleObserver, isLoading]
 );

 return {
   isLoading,
   loadMoreCallback,
   hasDynamicPosts,
   dynamicPosts,
   isLastPage,
 };
};

The loadMoreCallback method is what we’ll use to determine if a user has “intersected” a given element. As you may have guessed, the magic browser API helping us do that is called “Intersection Observer”. We pass a handler method handleObserver and initialization options to IntersectionObserver, which will handle emitted events. If the user is intersecting our target element, then target.isIntersecting is true and an API call is made to retrieve more data.

Please note that the aforementioned API call is wrapped in a timeout. Intersection Observer may fire multiple intersecting events when the user reaches the target, so we want to debounce those events to avoid making unnecessary calls to our API. We do that by only executing the API call if no other intersecting events have occurred within the last 500 milliseconds.

Add Your Intersecting Component

Now you’re probably wondering how we define where the intersection target is. We do that by adding the loadMoreCallback method as a ref to our desired component. Importantly, we’ll also re-render the intersecting component after new data is loaded to ensure that our intersection target moves along with the bottom of the page.

// Loader.tsx
type LoaderProps = Pick<
 UseInfiniteScroll,
 "isLoading" | "loadMoreCallback" | "isLastPage"
>;

export const Loader = ({
 isLoading,
 isLastPage,
 loadMoreCallback,
}: LoaderProps) => {
 if (isLoading) return <p>Loading...</p>;

 if (isLastPage) return <p>End of content</p>;

 return <div ref={loadMoreCallback}>load more callback</div>;
};

We then add that component below our already-loaded content, so that the Intersection Observer will fire an intersection event at the bottom of the page.

// HomePage.tsx
type HomePageProps = Pick<
 UseInfiniteScroll,
 "isLoading" | "loadMoreCallback" | "isLastPage"
> & {
 posts: BlogPost[];
};

export const HomePage = ({
 posts,
 isLoading,
 loadMoreCallback,
 isLastPage,
}: HomePageProps) => {
 return (
   <main className={styles.container}>
     <h1 className={styles.heading}>Infinite Scroll Demo</h1>
     <p>It is a very nice app</p>
     {posts.map((post) => (
       <div className={styles.blogPost} key={post.id}>
         <img src="https://picsum.photos/500" alt="random image" />
         <div>
           <h2>{post.title}</h2>
           <p>{post.description}</p>
         </div>
       </div>
     ))}

     <Loader
       isLoading={isLoading}
       isLastPage={isLastPage}
       loadMoreCallback={loadMoreCallback}
     />
   </main>
 );
};

Wrapping Up Our React Infinite Scroll Example

That’s it! With a couple of components and a custom hook, you can create your own infinite scrolling effect with React, TypeScript, and NextJS.

Given its ubiquity in consumer software (e.g., social media sites), infinite scrolling has become the go-to pagination strategy for many companies. So if you’ve been lucky enough to dodge infinite scroll so far, I wouldn’t bet on that trend continuing. When you’re inevitably asked to add this feature to an app, I hope this guide can be of help.

Learn more about how The Gnar builds React applications.

Forem: Royce Threadgill

React Server Components Example with Next.js

What are React Server Components?

React Server Components vs SSR

Server Components vs. Client Components

React Server Components Without Next.js…?

But What If I Really Don’t Like Next.js?

React Server Components Example with Next.js

React Server Components and Suspense

Interleaving Client and Server Components

You Can Still Use Contexts (Carefully)

You Can Use Server Code in Server Components

What Are the Advantages of React Server Components?

What are the Disadvantages of React Server Components?

Are React Server Components Production Ready?

Open Questions About React Server Components

Further Resources and Special Thanks

Creating Passkey Authentication in a Rails 7 Application

Rails 7 Passkey Authentication Example

Contributors:

DevSecOps 101: What is DevSecOps?

DevSecOps vs. DevOps

DevSecOps as Company Culture

Plan: Threat Analysis

Develop: Secure Coding; Security as Code

Build: Static Application Security Testing (SAST)

Test: Dynamic Application Security Testing (DAST)

Test: Penetration ("Pen") Testing

Release: Digitally Sign

Deliver: Secure Transfer

Deploy: Security Config, Security Scan

Operate: Security Patch

Monitor: Security Audit, Security Monitor

Conclusion

Gnarly Learnings from December 2023

Business Applications of AI

Ecommerce Web Design

Design

Mobile App Development

Tech Insights

Gnarly Bytes

Contributors:

Bun JavaScript Runtime First Look

What Is Bun?

How Fast Is Bun?

How Is Bun So Fast?

Is Bun Production Ready?

Why Should You Switch to Bun?

What Is the Future of Bun?

Is Bun a Drop-In Replacement for Node.js?

Metaprogramming in Ruby: Beginner Level

Ruby Metaprogramming Questions: What is it?

Ruby Metaprogramming Questions: When is it Useful?

Ruby define_method

Ruby define_method With Arguments

Implementing attr_reader with define_method

Ruby Metaprogramming Example

Ruby Metaprogramming Questions: Who Actually Uses This?

Infinite Scroll React Example with TypeScript and NextJS

Why Implement Infinite Scroll?

Libraries to Facilitate React Infinite Scroll

Custom Infinite Scroll with TypeScript and NextJS

Setting the Stage for our Infinite Scroll Example

Load the Initial Data

Create Your Custom Hook

Add Your Intersecting Component

Wrapping Up Our React Infinite Scroll Example

React Server Components and `Suspense`

Ruby `define_method`

Ruby `define_method` With Arguments

Implementing `attr_reader` with `define_method`