Next.js 16 + Material UI Setup Guide for App Router + RSC: Dev Diary #2

Christopher Olsen — Mon, 01 Jun 2026 11:00:00 +0000

In Part 1 of this two-part series, we walked through scaffolding a brand-new React application with Next.js. The result was a bare bones application with no styling to speak of. Early in any web application project, you have an important decision to make: are you going to build the look and feel of your app from scratch with custom CSS and JavaScript, or are you going to leverage a third-party solution to achieve a more professional-looking UI than you would with a custom solution and with less development effort? Most people choose the latter, and we will too.

At DMC, our preferred UI library is Material UI, a component library maintained by Google. I first used Material UI nearly a decade ago, before it even reached version 1.0. Since then, the library has evolved significantly and now includes first-class support for Next.js and React Server Components. In this post, we’ll walk through how to add Material UI to a new Next.js 16 application. At the time of writing, Material UI v9.0.0 is the version in use.

Installing the NPM Packages for Material UI

First, run the following command to install the core Material UI packages using Yarn:

yarn add @mui/material @emotion/react @emotion/styled

yarn add @mui/material @emotion/react @emotion/styled

The Material UI documentation recommends installing @fontsource/roboto to use the Roboto font in your application. However, at the time of writing this post, that package causes the TypeScript server in my project to crash, resulting in the loss of IntelliSense support in Visual Studio Code. Because of this, I recommend skipping that package. Later in this post, we’ll import the Roboto font using a different approach.

Next, run the following command to install the packages required to integrate Material UI with Next.js App Router:

yarn add @mui/material-nextjs @emotion/cache

yarn add @mui/material-nextjs @emotion/cache

Setting Up a Material UI Theme

One of Material UI’s most useful features is its customizable themes. Material UI includes a default theme that can be extensively customized—everything from spacing, color palettes, and even border radius can be modified based on your design sensibilities.

For this application, we’ll primarily use the default Material UI theme while enabling built-in light/dark mode functionality. We can initialize the theme using the createTheme() function:

// src/theme.tsx
"use client";
import { createTheme } from "@mui/material/styles";

const theme = createTheme({
  typography: {
    fontFamily: "var(--font-roboto)",
  },
  cssVariables: {
    colorSchemeSelector: "class",
  },
  colorSchemes: {
    dark: true,
  },
});

export default theme;

// src/theme.tsx
"use client";
import { createTheme } from "@mui/material/styles";

const theme = createTheme({
  typography: {
    fontFamily: "var(--font-roboto)",
  },
  cssVariables: {
    colorSchemeSelector: "class",
  },
  colorSchemes: {
    dark: true,
  },
});

export default theme;

This theme configuration does three things:

Sets Roboto as the default font family for all Typography components.
Enables dark mode support. Light mode is enabled by default.
Enables CSS variables and configures the colorSchemeSelector to use CSS classes.

The final configuration helps prevent SSR flickering, which can occur because the server cannot detect a user’s preferred color mode during the initial render. With this setup, Material UI applies either a light or dark class to the element on the client side and uses CSS variables to apply the appropriate theme colors. This approach provides a smoother transition between server-side rendering and client-side hydration while maintaining support for light and dark themes.

Color Mode Picker

Speaking of color mode (light/dark), it can be nice to offer users a way to switch between light mode and dark mode. With the way we’ve configured our theme, Material UI will automatically set the color mode based on the user’s system preference, set in their web browser. So if a user has configured “dark” mode in Chrome, for example, when they visit our application, they’ll automatically get the dark-mode version of our UI.

Some users may want dark mode specifically for our application and light mode elsewhere, so to provide that flexibility, we’ll build a simple color mode selector. For this, we’ll use the tools Material UI provides, including input and label components, along with tools for customizing them.

// colorThemePicker.tsx
"use client";
import FormControl from "@mui/material/FormControl";
import Select, { SelectChangeEvent } from "@mui/material/Select";
import MenuItem from "@mui/material/MenuItem";
import { useColorScheme } from "@mui/material/styles";
import { FormLabel } from "@mui/material";

export default function ColorThemePicker() {
  const { mode, setMode } = useColorScheme();
  if (!mode) {
    return null;
  }
  const handleChange = (event: SelectChangeEvent) => {
    setMode(event.target.value as "system" | "light" | "dark");
  };

  return (
    <FormControl
      sx={{
        display: "flex",
        flexDirection: "row",
        alignItems: "center",
        gap: 1,
      }}
    >
      <FormLabel id="theme-select-label">Theme</FormLabel>
      <Select
        labelId="theme-select-label"
        aria-labelledby="theme-select-label"
        id="theme-select"
        value={mode}
        label="Theme"
        onChange={handleChange}
        sx={{ minWidth: "10rem" }}
      >
        <MenuItem value="system">System</MenuItem>
        <MenuItem value="light">Light</MenuItem>
        <MenuItem value="dark">Dark</MenuItem>
      </Select>
    </FormControl>
  );
}

// colorThemePicker.tsx
"use client";
import FormControl from "@mui/material/FormControl";
import Select, { SelectChangeEvent } from "@mui/material/Select";
import MenuItem from "@mui/material/MenuItem";
import { useColorScheme } from "@mui/material/styles";
import { FormLabel } from "@mui/material";

export default function ColorThemePicker() {
  const { mode, setMode } = useColorScheme();
  if (!mode) {
    return null;
  }
  const handleChange = (event: SelectChangeEvent) => {
    setMode(event.target.value as "system" | "light" | "dark");
  };

  return (
    
      sx={{
        display: "flex",
        flexDirection: "row",
        alignItems: "center",
        gap: 1,
      }}
    >
      "theme-select-label">Theme
      
        labelId="theme-select-label"
        aria-labelledby="theme-select-label"
        id="theme-select"
        value={mode}
        label="Theme"
        onChange={handleChange}
        sx={{ minWidth: "10rem" }}
      >
        "system">System
        "light">Light
        "dark">Dark
      
    
  );
}

I’ll explain this from the top down.

We need a piece of state to track the user’s color mode selection: light, dark, or system (whatever they’ve selected in their browser settings). We also need a setter for that state so that we can update it based on the user’s actions. For that, we use a hook provided by Material UI: useColorScheme(). The mode returned by this hook is always undefined on the first render, so we handle that with a simple falsiness check:

if(!mode) {
  return null;
}

if(!mode) {
  return null;
}

Next, we have our return statement where we declare the UI that this component should render. We’re making use of a few components from Material UI:

The latter two are kind of self-explanatory if you have a basic background in HTML. FormControl is a nice-to-have component that manages some state related to the input element that it wraps, such as focused state, filled state, error state, required state, etc.

Something I want to point out is the use of the sx prop on the FormControl component. This is a CSS-in-JS styling solution from Material UI, intended for one-off customization. Our application has precisely one color theme picker, so it easily fits the definition of a one-off customization. You can read more about this system in the Material UI documentation.

The purpose served by our use of the sx prop here is to apply some flexbox CSS properties to our FormControl to make its child elements (the FormLabel and Select components) appear side by side instead of displaying the form label above the select component.

<FormControl
  sx={{
    display: "flex",
    flexDirection: "row",
    alignItems: "center",
    gap: 1,
  }}
>/


  sx={{
    display: "flex",
    flexDirection: "row",
    alignItems: "center",
    gap: 1,
  }}
>/

Under the hood, a CSS selector is generated and applied to the rendered DOM element, and a

<controltheme targettype="{x:Type TextBlock}" x:key="DefaultTextBlockStyle">
    <setter property="FontFamily" value="Sans Serif">
    <setter property="FontSize" value="12">
    <setter property="Foreground" value="Black">
setter>setter>setter>controltheme><style selector="TextBlock.h1" type="text/css"><Setter Property="FontSize" Value="24" />
    <Setter Property="FontWeight" Value="Bold" />style><style selector="TextBlock.h2" type="text/css"><Setter Property="FontSize" Value="20" />
    <Setter Property="FontWeight" Value="Bold" />style>

Having a more layered styling approach in Avalonia is beneficial since it allows you to use Styles to substitute a control’s property values without needing to override the entire theme. Conversely, in WPF, you can get stuck needing to override an entire theme if there is a theme applied to a control without an x:Key defined. If there is an x:Key defined in WPF, you can take advantage of the BasedOn property to build upon a pre-defined theme.

Avalonia Styles are placed in the Styles collection of a control and Control Themes are placed in the Resources collection of a control. Comparatively, in WPF, the Styles are all placed in the Resources collection.

Styles: Conditional Classes

A feature that stood out to me significantly is conditional classes for Avalonia Styles. This allows you to alter Style of a control based on a bound condition. In WPF, doing something similar is overly verbose and complicated and requires the use of a DataTrigger. In Avalonia, there is a lot less markup code that is needed.

The examples below demonstrate conditionally changing the TextBlock foreground based on a bound property.

In Avalonia, the following code will use the Error Style based on the bound property. Since you can conditionally pass in the property, both the DeviceState text and the SystemState text can share the Style with little code.

XAML

<grid.styles><style selector="TextBlock.Error" type="text/css"><Setter Property="Foreground" Value="{StaticResource ErrorForeground}" /></style>
</grid.styles>
<textblock classes.error="{Binding IsDeviceInError}" text="{Binding DeviceState}">
<textblock classes.error="{Binding IsSystemInError}" text="{Binding SystemState}">
</textblock></textblock>

<grid.styles><style selector="TextBlock.Error" type="text/css"><Setter Property="Foreground" Value="{StaticResource ErrorForeground}" />style>
grid.styles>
<textblock classes.error="{Binding IsDeviceInError}" text="{Binding DeviceState}">
<textblock classes.error="{Binding IsSystemInError}" text="{Binding SystemState}">
textblock>textblock>

In WPF, you must rely on a DataTrigger to change the Foreground value. Since the SystemState text and the DeviceState text rely on different bound properties as their condition, they cannot share the Style which leads to less code reuse.

XAML

<textblock text="{Binding DeviceState}">
    <textblock.style><style basedon="{StaticResource DefaultTextBlockStyle}" targettype="{x:Type TextBlock}" type="text/css"><Setter Property="Foreground" Value="Black" />
            <Style.Triggers>
                <DataTrigger Binding="{Binding IsDeviceInError}" Value="True">
                    <Setter Property="Foreground" Value="Red" />
                </DataTrigger>
            </Style.Triggers></style>
    </textblock.style>
</textblock>
<textblock text="{Binding SystemState}">
    <textblock.style><style basedon="{StaticResource DefaultTextBlockStyle}" targettype="{x:Type TextBlock}" type="text/css"><Setter Property="Foreground" Value="Black" />
            <Style.Triggers>
                <DataTrigger Binding="{Binding IsSystemInError}" Value="True">
                    <Setter Property="Foreground" Value="Red" />
                </DataTrigger>
            </Style.Triggers></style>
    </textblock.style>
</textblock>

<textblock text="{Binding DeviceState}">
    <textblock.style><style basedon="{StaticResource DefaultTextBlockStyle}" targettype="{x:Type TextBlock}" type="text/css"><Setter Property="Foreground" Value="Black" />
            <Style.Triggers>
                <DataTrigger Binding="{Binding IsDeviceInError}" Value="True">
                    <Setter Property="Foreground" Value="Red" />
                DataTrigger>
            Style.Triggers>style>
    textblock.style>
textblock>
<textblock text="{Binding SystemState}">
    <textblock.style><style basedon="{StaticResource DefaultTextBlockStyle}" targettype="{x:Type TextBlock}" type="text/css"><Setter Property="Foreground" Value="Black" />
            <Style.Triggers>
                <DataTrigger Binding="{Binding IsSystemInError}" Value="True">
                    <Setter Property="Foreground" Value="Red" />
                DataTrigger>
            Style.Triggers>style>
    textblock.style>
textblock>

Controls

Controls in Avalonia are very similar to WPF, but there are a few tweaks that make the framework quicker to work with but potentially less feature-rich.

Visualization and Animations

Avalonia does not support the VisualStateManager, and it instead relies on styles and pseudoclasses such as :hover, :focus, and :checked. Additionally, Avalonia does not use Storyboards, but rather it has simpler animations that use Transitions and Animation.

Grid Row and Column Definitions

A low-hanging fruit that Avalonia improved was how to define rows and columns for the Grid control. Instead of using multiple lines to do it, Avalonia has allowed you to do it within one line. The following examples show how to define the same grid layout in Avalonia and WPF.

In Avalonia,

XAML

<grid columndefinitions="*, *, *, *" rowdefinitions="Auto, Auto, Auto, Auto">
</grid>

<grid columndefinitions="*, *, *, *" rowdefinitions="Auto, Auto, Auto, Auto">
grid>

In WPF,

XAML

<Grid> 
    <Grid.RowDefinitions> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
    </Grid.RowDefinitions> 
    <Grid.ColumnDefinitions> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
    </Grid.ColumnDefinitions> 
</Grid>

<Grid> 
    <Grid.RowDefinitions> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
        <RowDefinition Height="Auto" /> 
    Grid.RowDefinitions> 
    <Grid.ColumnDefinitions> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
        <ColumnDefinition Width="*" /> 
    Grid.ColumnDefinitions> 
Grid>

Compiled Bindings

Another nice feature in Avalonia is the choice to use compiled bindings. This can be very helpful since it allows the developer to catch binding errors faster since they are caught at compile time instead of runtime.

There are some limitations with compiled bindings though. For instance, they require a static DataContext and a defined data context type using x:DataType. However, for most use cases, they will be helpful in debugging and development!

Takeaways

When comparing Avalonia and WPF, the running theme is that Avalonia prioritizes flexibility to support multiple platforms and succinct code. This makes Avalonia lighter weight and a great option for cross-platform development. For complex, feature-rich Windows development, WPF has the edge over Avalonia.

At DMC, we are always looking towards the future and learning new technologies to better support the wide variety of needs our customers have. We are excited to continue exploring Avalonia UI to provide expert solutions for cross-platform, desktop development.

Plan Your Next Move to a Cross-Platform Framework.

Learn more about how DMC’s Application Development experts can help you move to a cross-platform network, and look into our Avalonia capabilities.

The post Avalonia UI: Noteworthy Differences from WPF appeared first on DMC, Inc..

Application Development Archives | DMC, Inc.

Next.js 16 + Material UI Setup Guide for App Router + RSC: Dev Diary #2

Installing the NPM Packages for Material UI

Setting Up a Material UI Theme

Color Mode Picker

Styles: Conditional Classes

Controls

Visualization and Animations

Grid Row and Column Definitions

Compiled Bindings

Takeaways

Plan Your Next Move to a Cross-Platform Framework.