DEV Community: JM

🚀 Transform Your UI: Creating Layouts Using Compound Components in React – A Step-by-Step Guide

JM — Mon, 14 Aug 2023 14:16:25 +0000

Introduction

Building robust and maintainable layouts can be a challenge in React applications. Compound components offer a way to achieve this by allowing for reusable and modular code. In this tutorial, you'll learn how to create a layout using compound components step by step by leveraging the concept of slots.

The Goal

const App = () => {
  return (
    <MainLayout.Root>
      <MainLayout.Sidebar className="shadow-xl z-10 relative">
        <p>Sidebar</p>
      </MainLayout.Sidebar>
      <MainLayout.Header>
        <h1 className="text-xl font-bold">My App</h1>
      </MainLayout.Header>
      <MainLayout.Body>
        <p>Body</p>
      </MainLayout.Body>
      <MainLayout.Footer>
        <p>Footer</p>
      </MainLayout.Footer>
    </MainLayout.Root>
  );
};

Why Slots?

Before diving into the code, it's crucial to understand what slots are and why we're using them. A slot is just a placeholder where other components can be inserted.

For our layouts we'll be defining two types of slots: a fragment slot and a container slot. The fragment slot prevents the caller from setting any properties, such as className, whereas the container slot allows it. This flexibility lets us control how our layout behaves and is customized.

Create a Fragment Slot

The fragment slot is a simple wrapper that renders its children without adding any additional HTML tags or properties. This kind of slot is beneficial when you want to maintain a clean and controlled structure.

export const Slot = () => (props: { children: React.ReactNode }) => {
  return <>{props.children}</>;
};

Create a Container Slot

The container slot is more versatile and can behave like any HTML tag, such as a div, section, header, etc. This allows for more customization and control. We define a className argument so that we can provide some default classes.

export const ContainerSlot =
  (ar?: {
    as?: "div" | "section" | "header" | "footer" | "main";
    className?: string;
  }) =>
  (props: { children: React.ReactNode } & HTMLProps<HTMLDivElement>) => {
    const El = ar?.as ?? "div";
    return (
      <El {...props} className={cn(ar?.className, props.className)}>
        {props.children}
      </El>
    );
  };

These two slots are the only ones we need for our example but we've also found it useful to create other slots like a "Text" slot that required props.children to be a string.

Getting our slot content

In order to get our slot content when we're defining our layout we need to loop through our props.children using something like React.Children.map but for convenience we'll just use a library react-nanny. You can leave this out if you don't want another dependency.

import { getChildrenByType } from "react-nanny";

export const getSlotByType = (
  children: React.ReactNode | undefined | null,
  type: React.ElementType | React.ElementType[]
) => {
  if (!children) return null;
  const content = getChildrenByType(children, type);
  return content;
};

Define our layout

Let's define our layout sections and layout. We'll create slots for a sidebar, header, footer, and main content area.

const Sidebar = ContainerSlot({
  className: "bg-gray-100 w-64 flex flex-col overflow-hidden",
});

const Header = ContainerSlot({
  className: "bg-gray-100 flex items-center justify-between px-4 py-2",
  as: "header",
});

const Footer = ContainerSlot({
  className: "bg-gray-100 flex items-center justify-between px-4 py-2",
  as: "footer",
});

const Body = ContainerSlot({
  className: "flex-1 overflow-auto",
  as: "main",
});

const Root = (props: { children: React.ReactNode }) => {
  // Here we're using our util to get the appropriate slot content
  const sidebar = getSlotByType(props.children, Sidebar);
  const header = getSlotByType(props.children, Header);
  const footer = getSlotByType(props.children, Footer);
  const body = getSlotByType(props.children, Body);

  return (
    <div className="flex flex-col h-screen w-screen">
      {header}
      <div className="flex flex-1">
        {sidebar}
        {body}
      </div>
      {footer}
    </div>
  );
};

export const MainLayout = {
  Root,
  Sidebar,
  Header,
  Footer,
  Body,
};

Use the layout

We can now use the layout in our application

const App = () => {
  return (
    <MainLayout.Root>
      <MainLayout.Sidebar>
        <p>Sidebar</p>
      </MainLayout.Sidebar>
      <MainLayout.Header>
        <h1 className="text-xl font-bold">My App</h1>
      </MainLayout.Header>
      <MainLayout.Body>
        <p>Body</p>
      </MainLayout.Body>
      <MainLayout.Footer>
        <p>Footer</p>
      </MainLayout.Footer>
    </MainLayout.Root>
  );
};

Conclusion

That's it! We've created a reusable layout using compound components. Feel free to explore these concepts further and adapt them to your specific needs.

Dissecting React: Routing, State, HTML, and Styling

JM — Fri, 14 Jul 2023 15:53:10 +0000

Every single framework you encounter will need to answer a few different questions:

Routing
State Management
- How to manage local app state
- How to fetch and persist state from the server
HTML Generation
Styling

React

Routing
- Not a React Concern, use a library or a framework that builds on React
  - react-router
  - NextJS pages / app folder
  - etc..
State Management
- Components are laid out in a tree
- State flows down from a parent node to the child components.
  - I say parent node and not component because parent nodes can be state stores or a server or anything that passes info down in to a child component
- Server State
  - Can be stored in the same state management library or approach you've chosen
  - Projects have moved on to react-query, useSWR, or a mixture of the two plus server side rendering.
    - In either case the thinking nowadays is to keep your query data separate from your local app data
- General guidelines
  - Keep state as close as possible to the components using it.
    - This prevent unnecessary renders of the subscribing component's subtree.
  - Decouple your business logic from the presentation state
  - Know the size of your application
    - Atoms work for smaller applications but without a proper organization structure can become unwieldy
    - Redux style structures are probably more overhead than necessary in small to medium applications but really start to shine as your application becomes larger or if you have state that can be updated from many different places. Having explicit actions helps traceability
    - MobX or Proxy based stores can be more performant out of the box because they keep track of the actual state you're reading and will only re-render the leaf nodes when the state changes.
HTML Generation
- Component Based
  - JSX -> HTML
  - Props + State => view
- Components are composed to create larger pages / features
Styling
- Not opinionated
- Throughout the history of react there have been several approaches each lauded as the right solution at the time.
  - Use a global stylesheet like pre-react days.
  - Use CSS Modules
    - This adds a namespace to your css or generates unique keys to encourage encapsulation
    - This is where we start to go against the CSS cascade somewhat, we're limiting the "reach" of the cascade to avoid the case where we update the CSS in one place and inadvertently affect other components.
  - Styled Components and Other CSS-in-JS solutions
    - These libraries offer a way to write CSS directly in your JavaScript, allowing you to take advantage of JavaScript's full power to dynamically create and apply styles.
    - They aim to enhance CSS for styling React component systems. Styled-components, for instance, leverages tagged template literals to style your components.
    - It comes with benefits like automatic critical CSS, no class name bugs, easier deletion of CSS, and dynamic styling adapting to your props.
  - Utility based CSS
    - These are CSS libraries like Tailwind CSS that provide low-level utility classes that let you build completely custom designs without ever leaving your HTML.
    - The idea behind utility-first CSS is to compose your design directly in your markup. It leads to less context switching than having separate CSS files or even CSS-in-JS.
    - Tailwind, for example, also allows you to customize your design system (colors, spacing, etc.) directly in a configuration file.

In future write ups we will explore other frameworks and how they answer these concerns.

Living Document: State Management Notes

JM — Fri, 14 Jul 2023 02:33:28 +0000

This is a living document that will be used to store my understanding of managing state on the Frontend.

React is a component based frontend framework.

The core piece of React is (state, props) => view.

Most state management solutions in React follow the flux architecture where a centralized store is updated through actions.

This also resembles what is known as the Elm Architecture.

This can be summarized as:


type Model = {};
type Action = { type: string, payload: { ... } };

type Reducer = <T extends unknown>(state: Model, action: Action) => {
    switch action.type {
        case 'update': {
            Model.property = action.payload;
            break;
        }
        ...
    }
}

// When state changes, render the UI again.
subscribe(state, () => <UI />);

This fundamental structure is the same in every single state management solution used in React today, some just make it more explicit than others.

import { proxy } from 'valtio';

const state = proxy({
    message: 'hello';
})

function updateMessage(message: string) {
    state.message = message;
}

function clearMessage() {
    state.message = "";
}

// or

type MessageActions = {
    type: 'update-message';
    payload: string;
} | {
    type: 'clear-message';
}

function reducer(action: MessageActions) {
    switch (action) {
        case 'update-message': {
            state.message = action.payload;
            break;
        }
        case 'clear-message': {
            state.message = '';
            break;
        }
    }
}

// or

const QueryCache = new QueryCache({});


let message = '';
let queryKey = ['message-query'];
const useMessageQuery = () => {
    return useQuery(queryKey, () => {
        return message;
    });
}

const useUpdateQuery = () => {
    return useMutation(async (message: string) => {
        // Set the query cache directly
        QueryCache.setQueryData(message);
        // or set the state and invalidate the cache to cause a refetch
        message = message;
        QueryCache.invalidateQueries(queryKey);
    });
};

// or in RxJS
const state = new BehaviorSubject();
const updateMessage = (msg: string) => state.next(msg);

At the end of the day all state management boils down to the same thing. Redux and other action based approaches resemble message passing in small-talk style object oriented programming, or rxjs pubsub, or just a traditional event-bus.

Traditional Redux encourages a single state store and reducer, you then define "slices" to figure out which path from the state you want to get, and those slices need to be memoized so that your components don't render when unrelated pieces of state change.

Atom based stores like Jotai, Zustand, etc.. encourage you to have multiple state stores, each one holding a smaller unit of state, the idea being that you can subscribe to smaller pieces of state and prevent unnecessary re-renders.

Stores like MobX and later Valtio keep track of the actual properties you are using from state to only render when something you are subscribed to changes. This can give you better performance and might make state easier to reason about for certain teams of developers.

Some people think that React Context is a valid mechanism for storing state, and while you can do this, it is really better suited as a dependency injection mechanism since React causes any component subscribed to the context to render both itself and the subtree.

Svelte's Reactivity

From the concept of looking at state management, svelte is the exact same model. It just has much nicer ergonomics for declaring and subscribing to state. Reactivity is a first class citizen in Svelte.

You have stores

const store = writable(... syntax I don't remember right now);


export function updateMessage(msg: string) {
    message = msg;
}

// in your component
import { updateMessage } from './state';

// Will react to the message change
$: message = $store;

updateMessage('hello');

And so any guidance on managing atoms applies to svelte stores.

Nothing stops you from using Redux or another state management library with Svelte but the primitives it has are good enough to build a lot with them.

Vue

To be continued but it's essentially the same thing.
Talk about vuex and other state managers.