User Interface - freeCodeCamp.org

How to Build Responsive UIs in Flutter

Atuoha Anthony — Tue, 28 Oct 2025 18:17:34 +0000

Building responsive UIs in Flutter can be challenging, especially when you want your app to look great on phones, tablets, and desktops without maintaining multiple layouts. Fortunately, Flutter provides powerful tools like MediaQuery, LayoutBuilder, and the flutter_screenutil package to make this process seamless.

In this article, we’ll walk through a complete sample responsive screen, explaining each part of the code step by step. You’ll learn not only how to make your layout adapt to different screen sizes and orientations but also how to use scaling utilities to keep your text and spacing consistent across all devices.

By the end, you’ll understand how to structure a Flutter app that automatically adjusts its layout and typography based on the available screen real estate, a must-know skill for any developer targeting multiple platforms.

Prerequisites
Understanding Responsive vs Adaptive Design
Core Flutter Layout Widgets for Responsive UI
MediaQuery and Screen Information
Best Practices and Performance Considerations
Testing and Debugging Responsive Layouts
Building Reusable Responsive Widgets/Custom Widgets
Example of A Complete Sample Responsive Screen
Full Walkthrough: Code Explained in Depth
Key Takeaways
Conclusion
References

Prerequisites

Before diving in, ensure you have:

A working Flutter environment (SDK, IDE, emulator or device).
Basic proficiency in Flutter: Knowledge of widgets, stateless/stateful, Row/Column, Scaffold, and so on.
Familiarity with Dart basics and how layout works in Flutter (constraints, sizing).
(Optional but helpful) A design/mockup (for example from Figma) with defined design size or target screen.
Understanding that creating truly adaptive/responsive UIs means accommodating different screen sizes, orientations, aspect-ratios, and platforms (mobile/tablet/web/desktop).

Understanding Responsive vs Adaptive Design

It’s helpful to clarify terminology:

Responsive design is about fitting the UI into the available space: The layout scales, reflows, rearranges as the screen size or orientation changes.
Adaptive design is about selecting different UI patterns depending on the device/screen. For example, using a side-panel on desktop, bottom navigation on mobile. The UI adapts to the context of use.
In practice with Flutter, you often do both: Responsive (scaling/reflow) and adaptive (choosing variant layouts).
According to the official documentation:

“Responsive design is about fitting the UI into the space. Adaptive design is about the UI being usable in the space.” (Flutter Docs)
Also, some best practices to follow: don’t assume device type (phone/tablet) based on screen size, don’t lock orientation, and don’t rely solely on MediaQuery.orientation. (Flutter Docs)

Core Flutter Layout Widgets for Responsive UI

Flutter provides many fundamental widgets for layout – when used well, they form the backbone of responsive UIs.

Container/SizedBox

Container, SizedBox let you size widgets explicitly or via constraints.

Use cautiously: Overly fixed sizes can hamper responsiveness (for example, a Container(width: 300) may overflow on small screens).

Better to use relative sizing or allow flexibility.

Here are clear, practical Flutter code examples that illustrate how to use Container and SizedBox, including both bad (fixed) and good (responsive/flexible) sizing approaches:

Overly Fixed Sizing (Not Responsive)

class FixedContainerExample extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        // This might overflow on small screens!
        child: Container(
          width: 300,
          height: 200,
          color: Colors.blue,
          child: const Center(
            child: Text(
              'Fixed Size Container',
              style: TextStyle(color: Colors.white),
            ),
          ),
        ),
      ),
    );
  }
}

Problem:
If the screen width is less than 300px (like on small mobile devices), this widget may overflow or get cut off.

Responsive / Flexible Sizing

class ResponsiveContainerExample extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final screenWidth = MediaQuery.of(context).size.width;

    return Scaffold(
      body: Center(
        // Use relative width and height
        child: Container(
          width: screenWidth * 0.8, // 80% of screen width
          height: 200,
          decoration: BoxDecoration(
            color: Colors.blue,
            borderRadius: BorderRadius.circular(12),
          ),
          child: const Center(
            child: Text(
              'Responsive Container (80% width)',
              style: TextStyle(color: Colors.white),
            ),
          ),
        ),
      ),
    );
  }
}

Why better:
It adjusts automatically to different screen sizes.

SizedBox for Spacing or Constraints

class SizedBoxExample extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            const Text('Above Spacer'),
            const SizedBox(height: 16), // Adds spacing
            Container(
              width: 200,
              height: 100,
              color: Colors.green,
              child: const Center(child: Text('Sized Container')),
            ),
          ],
        ),
      ),
    );
  }
}

SizedBox is lightweight and great for adding fixed spacing or defining simple dimensions without needing a full Container.

Row, Column

Row and Column arrange children horizontally or vertically.

Note: Row gives infinite horizontal space (subject to parent constraints), so children must handle sizing or else overflow.

When you use a Row or Column, Flutter tries to give them as much space as possible along their main axis (horizontal for Row, vertical for Column).
If the children inside don’t know how much space to take, they can overflow or not display as intended.

That’s why we use Expanded, Flexible, or SizedBox to tell Flutter how each child should use the available space.

Example:

Row(
  children: [
    Expanded(
      child: Container(
        // Your widget content here
      ),
    ),
    // Other widgets...
  ],
)

Here Expanded says: “take up remaining space proportionally”.

Expanded and Flexible

Expanded forces its child to fill remaining space in a Row or Column.

Flexible gives its child flexibility: it may shrink or grow but not forcibly fill.

Example:

Row(
  children: [
    Flexible(
      child: Container(
        // Widget content
      ),
    ),
    // Other widgets...
  ],
)

Using Flexible/Expanded helps distribute space dynamically and naturally adapt to varying screen sizes.

LayoutBuilder

LayoutBuilder gives you the parent widget’s constraints (maxWidth, maxHeight) and allows you to re-build UI accordingly.

LayoutBuilder(
  builder: (BuildContext context, BoxConstraints constraints) {
    if (constraints.maxWidth > 600) {
      // Large screen layout
      return LargeScreenWidget();
    } else {
      // Small screen layout
      return SmallScreenWidget();
    }
  },
)

This is often more reliable than just checking MediaQuery.orientation or MediaQuery.size, especially in multi-window/foldable devices. (Flutter Docs)

FractionallySizedBox and AspectRatio

FractionallySizedBox: Sizes its child as a fraction of the parent’s size (for example, widthFactor: 0.5).

AspectRatio: Maintains a fixed aspect ratio (width/height), useful for images or containers.

AspectRatio(
  aspectRatio: 16 / 9,
  child: YourWidget(),
)

These help maintain proportionally consistent layouts across screen sizes.

MediaQuery and Screen Information

Understanding screen size, orientation, padding, device pixel ratio and so on, is essential.

Using MediaQuery

double screenWidth  = MediaQuery.of(context).size.width;
double screenHeight = MediaQuery.of(context).size.height;
Orientation orientation = MediaQuery.of(context).orientation;
double devicePixelRatio = MediaQuery.of(context).devicePixelRatio;
EdgeInsets padding = MediaQuery.of(context).padding;

size gives the logical pixel width/height, orientation informs if the device is in portrait or landscape, devicePixelRatio shows how many physical pixels per logical pixel, helpful for image scaling, and padding gives system UI insets (notches, status bar, navigation bar).

Use these values to tailor your UI: for example, adjust font sizes, container widths, or layout decisions.

Example: Responsive Typography

Text(
  'Your text here',
  style: TextStyle(
    fontSize: screenWidth * 0.04, // 4% of screen width
  ),
)

Approach: Compute font size relative to screen width or height. But be cautious, text readability and accessibility (for example, system font size changes) should be considered, see best practices below.

Breakpoints, Orientation and Large-Screen Adaptation

To create UIs that look great on tablets/desktops as well as phones:

Orientation

if (MediaQuery.of(context).orientation == Orientation.portrait) {
  // Portrait layout
} else {
  // Landscape layout
}

Works for basic cases, but beware: orientation alone doesn’t capture window size (especially in desktop/multi-window environments), prefer checking constraints or size. (Flutter Docs)

Breakpoints and Adaptive Layouts

Define custom breakpoints based on width (or other metrics) to trigger different layouts.

Example:

if (screenWidth > 600) {
  // Tablet/large-screen UI
} else {
  // Phone UI
}

Some sources propose standard breakpoints, for example, compact (<600), medium (600-840), large (>840). With LayoutBuilder you can detect parent constraint width instead of global screen width, which is more robust.

Large Screens and Safe Use of Space

On very wide screens, filling full width may hurt readability. The official Flutter docs recommend limiting content width (for example, using ConstrainedBox + Center) for large screens so that lines of text aren't excessively long. (Flutter Docs)

Example:

Center(
  child: ConstrainedBox(
    constraints: BoxConstraints(maxWidth: 800),
    child: YourContent(),
  ),
)

Responsive Typography, Images and Assets

Typography

Use scalable units whenever possible (see packages later). Wrap text in Flexible/Expanded if inside Row/Column to avoid overflow, and consider system font scale factor: You can use MediaQuery.of(context).textScaleFactor to adapt fonts for accessibility.

Images and BoxFit

Image.asset(
  'assets/your_image.png',
  fit: BoxFit.cover,  // or BoxFit.contain, BoxFit.fitWidth etc.
  width: someWidth,   // responsive width
  height: someHeight, // responsive height
)

BoxFit.cover allows image to fill container while maintaining aspect ratio.

Use AspectRatio or FractionallySizedBox to keep images proportional.

Asset Density and Pixel Ratio

For high resolution devices (high devicePixelRatio), provide higher resolution assets (2x/3x) so they appear crisp.

Flutter handles asset variants (asset@2x.png and so on) automatically, but in very large screen layouts you may want extra details.

Flexible Layouts: Expanded, Flexible, FractionallySizedBox

We discussed these partially above, but here are deeper guidelines.

Expanded and Flexible

Use inside Row or Column to distribute space.

Example:

Row(
  children: [
    Expanded(flex: 2, child: Container(color: Colors.red)),
    SizedBox(width: 8),
    Expanded(flex: 1, child: Container(color: Colors.blue)),
  ],
)

The red container takes twice the width of the blue. Using Flexible allows its child to expand or shrink, but doesn’t force full space.

FractionallySizedBox

Example:

FractionallySizedBox(
  widthFactor: 0.8,  // 80% of parent width
  child: SomeWidget(),
)

Useful when you want a widget to occupy a fraction of available space without using exact pixel values.

AspectRatio

AspectRatio(
  aspectRatio: 16/9,
  child: Container(color: Colors.green),
)

Ensures the container maintains 16:9 ratio regardless of parent size.

Advanced Tools and Packages

Using packages can simplify many repetitive tasks. Here are some highly used ones.

flutter_screenutil

Helps scale widths, heights, font sizes based on a design size you specify.

Example initialization:

ScreenUtilInit(
  designSize: Size(360, 690), // your base design size
  builder: () => MaterialApp(
    home: MyHomePage(),
  ),
);

Usage:

width: 200.w,         // scaled width
height: 150.h,        // scaled height
fontSize: 16.sp,      // scaled font size
radius: 12.r,         // scaled radius

Advantages: Easy scaling of many sizes. But you must use .w, .h, .sp, .r consistently.

responsive_builder

Helps produce layouts for different device screen types (mobile/tablet/desktop).

Example:

ResponsiveBuilder(
  builder: (context, sizingInformation) {
    if (sizingInformation.deviceScreenType == DeviceScreenType.mobile) {
      return MobileLayout();
    } else if (sizingInformation.deviceScreenType == DeviceScreenType.tablet) {
      return TabletLayout();
    } else {
      return DesktopLayout();
    }
  },
);

Useful for switching entire widget trees based on device type. (Medium)

Others

responsive_framework, adaptive_breakpoints, and so on.
When choosing a package, check maintenance, popularity, compatibility with your Flutter version.

Handling Safe Areas, Notches and Insets

Modern devices have notches, status bars, navigation bars, foldables and so on. Use widgets and APIs to handle these.

Wrap main content in SafeArea to avoid system UI intrusions.
Use MediaQuery.of(context).padding to detect safe padding (top, bottom, left, right).

Example:

Padding(
  padding: MediaQuery.of(context).padding,
  child: YourContent(),
)

On Android you can also set UI mode:

SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge);

and update styles so status/navigation bar become transparent, helps full-screen UIs.

Adaptive UI for Tablets/Desktop and Multi-Window

As your app runs on larger screens or in multi-window environments (foldables, desktops, web), consider:

Switching from bottom navigation (mobile) to a navigation rail or side‐panel (tablet/desktop).
Using ConstrainedBox to limit content width on wide screens for readability.
Layout changes: Instead of single column scroll, you may display side-by-side panels or grid layouts.
Use LayoutBuilder or packages to detect width/constraints and choose the appropriate layout.

Avoid device type checking (for example, “if tablet”), instead base on window size.

Example:

 LayoutBuilder(
   builder: (context, constraints) {
     if (constraints.maxWidth > 1024) {
       return DesktopScaffold();
     } else if (constraints.maxWidth > 600) {
       return TabletScaffold();
     } else {
       return MobileScaffold();
     }
   },
 );

Best Practices and Performance Considerations

Summarizing key best practices:

Break widgets into smaller reusable widgets improves maintainability and reuse.
Start building from the inside out. Start with smallest components and move outward, rather than imposing outer container constraints first.
Ensure defined constraints to avoid infinite bounds and overflow by using Expanded, Flexible, and so on.
Avoid fixed sizes where unnecessary. Relative sizing or flex layouts adapt better.
Avoid relying solely on screen size or orientation, use constraints instead of device type checks.
Performance matters, avoid over-nesting heavy layouts, avoid rebuilding large subtrees when not needed. Use const widgets and keep build method lean.
Accessibility account for large font scaling (MediaQuery.textScaleFactor), screen readers, keyboard/mouse input on larger screens.
Test on multiple screen sizes/orientations actual devices/emulators/display sizes.
Font/text overflow wrap text in Flexible, set overflow, softWrap, and test for dynamic content.

Testing and Debugging Responsive Layouts

Use device emulators/simulators with different screen sizes (phones, tablets, desktops).
For web/desktop, resize browser window to see how layout adapts.
Use device_preview package or built-in Flutter tools to simulate various devices.
Use Flutter DevTools’ Widget Inspector and Layout Explorer to understand how widgets are sized and laid out.
Test orientation changes, multi-window, split view (for example, Android foldables).
Check for overflow errors (yellow/black stripes) or unexpected scroll behavior.
Check accessibility: Scale fonts up/down, test with screen reader, check keyboard navigation in desktop mode.

Building Reusable Responsive Widgets/Custom Widgets

One of the keys to scalable responsive UI is creating reusable widgets that encapsulate responsive behavior.

import 'package:flutter/material.dart';
import 'package:flutter_screenutil/flutter_screenutil.dart';

class ResponsiveText extends StatelessWidget {
  final String text;
  final FontWeight fontWeight;
  final Color color;

  const ResponsiveText(
    this.text, {
    Key? key,
    this.fontWeight = FontWeight.normal,
    this.color = Colors.black,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Text(
      text,
      style: TextStyle(
        fontSize: 16.sp,         // scaled font size
        fontWeight: fontWeight,
        color: color,
      ),
    );
  }
}

Usage: Instead of manually specifying font size every time, you use ResponsiveText. Similarly, you can build ResponsiveContainer, ResponsivePadding, and so on. Encapsulating responsive logic in widgets improves code reuse and consistency.

import 'package:flutter/material.dart';

class BreakpointAwareLayout extends StatelessWidget {
  final Widget mobile;
  final Widget tablet;
  final Widget desktop;

  const BreakpointAwareLayout({
    Key? key,
    required this.mobile,
    required this.tablet,
    required this.desktop,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(
      builder: (context, constraints) {
        if (constraints.maxWidth >= 1024) {
          return desktop;
        } else if (constraints.maxWidth >= 600) {
          return tablet;
        } else {
          return mobile;
        }
      },
    );
  }
}

Usage: You supply three versions of your UI and widget will choose based on width.

Example of A Complete Sample Responsive Screen

We’ll divide the example into these parts:

Project Setup and Imports
App Entry Point (main() and MyApp)
ScreenUtil Initialization
Main Page Layout (MyHomePage)
Adaptive Layout with LayoutBuilder
Main Content Builder (_buildMainContent)
Responsive Styling with flutter_screenutil

Project Setup and Imports

import 'package:flutter/material.dart';
import 'package:flutter_screenutil/flutter_screenutil.dart';

void main() {
  runApp(MyApp());
}

App Entry Point: The `MyApp` Class

class MyApp extends StatelessWidget {
  // Design size corresponds to the reference design (e.g., iPhone 6/7/8)
  final Size designSize = const Size(360, 690);

  @override
  Widget build(BuildContext context) {
    return ScreenUtilInit(
      designSize: designSize,
      minTextAdapt: true,       // adapts font size
      splitScreenMode: true,    // supports split-screen
      builder: (context, child) {
        return MaterialApp(
          title: 'Responsive Flutter Example',
          home: MyHomePage(),
        );
      },
    );
  }
}

The Responsive Home Screen (`MyHomePage`)

class MyHomePage extends StatelessWidget {
  const MyHomePage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final double screenWidth  = MediaQuery.of(context).size.width;
    final double screenHeight = MediaQuery.of(context).size.height;
    final Orientation orientation = MediaQuery.of(context).orientation;

    return Scaffold(
      appBar: AppBar(
        title: Text(
          'Responsive UI',
          style: TextStyle(fontSize: 20.sp),
        ),
      ),
      body: SafeArea(
        child: LayoutBuilder(
          builder: (context, constraints) {
            if (constraints.maxWidth > 600) {
              // Tablet/Desktop layout
              return Row(
                children: [
                  Expanded(
                    flex: 2,
                    child: Container(
                      color: Colors.blueGrey[50],
                      child: Center(
                        child: Text(
                          'Sidebar Panel',
                          style: TextStyle(fontSize: 18.sp),
                        ),
                      ),
                    ),
                  ),
                  Expanded(
                    flex: 5,
                    child: Container(
                      padding: EdgeInsets.all(16.w),
                      child: _buildMainContent(context),
                    ),
                  ),
                ],
              );
            } else {
              // Mobile layout
              return SingleChildScrollView(
                child: Padding(
                  padding: EdgeInsets.symmetric(horizontal: 16.w, vertical: 24.h),
                  child: _buildMainContent(context),
                ),
              );
            }
          },
        ),
      ),
    );
  }
}

Building the Core Content

Widget _buildMainContent(BuildContext context) {
  return Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: [
      Text(
        'Welcome to the Responsive App',
        style: TextStyle(fontSize: 24.sp, fontWeight: FontWeight.bold),
      ),
      SizedBox(height: 12.h),
      Text(
        'This UI adapts to different screen sizes automatically. Try resizing your window or changing the orientation.',
        style: TextStyle(fontSize: 16.sp),
      ),
      SizedBox(height: 24.h),
      Row(
        children: [
          Expanded(
            child: Image.asset(
              'assets/sample.jpg',
              width: double.infinity,
              height: 200.h,
              fit: BoxFit.cover,
            ),
          ),
        ],
      ),
      SizedBox(height: 24.h),
      Row(
        children: [
          Expanded(
            child: ElevatedButton(
              onPressed: () {},
              style: ElevatedButton.styleFrom(
                padding: EdgeInsets.symmetric(vertical: 14.h),
                textStyle: TextStyle(fontSize: 16.sp),
              ),
              child: Text('Get Started'),
            ),
          ),
        ],
      ),
    ],
  );
}

Full Walkthrough: Code Explained in Depth

Let’s now go through a deep explanation of the full sample responsive Flutter screen, line by line and block by block.

Imports and App Entry Point

import 'package:flutter/material.dart';
import 'package:flutter_screenutil/flutter_screenutil.dart';

void main() {
  runApp(MyApp());
}

Explanation:

import 'package:flutter/material.dart'; brings in Flutter’s Material Design library, which contains essential UI widgets such as Scaffold, AppBar, Text, and Column. import 'package:flutter_screenutil/flutter_screenutil.dart'; imports the flutter_screenutil package, providing scaling utilities like .sp, .h, .w, and .r that automatically adjust UI elements based on the device’s screen size. The void main() function serves as the entry point of the Flutter app, calling runApp(MyApp()) to render the MyApp widget as the root of the application.

App Root: The `MyApp` Widget

class MyApp extends StatelessWidget {
  // Design size corresponds to the reference design (e.g., iPhone 6/7/8)
  final Size designSize = const Size(360, 690);

  @override
  Widget build(BuildContext context) {
    return ScreenUtilInit(
      designSize: designSize,
      minTextAdapt: true,       // adapts font size
      splitScreenMode: true,    // supports split-screen
      builder: (context, child) {
        return MaterialApp(
          title: 'Responsive Flutter Example',
          home: MyHomePage(),
        );
      },
    );
  }
}

Explanation:

MyApp extends StatelessWidget, meaning it doesn’t maintain any internal state and simply builds the widget tree. The designSize defines the base design resolution used in your design mockups (in this case, 360x690, typical of an iPhone 8). ScreenUtilInit initializes the flutter_screenutil package, and its parameters configure how responsiveness works: designSize: Size(360, 690) sets the reference design size for all scaling calculations, minTextAdapt: true ensures text automatically scales on smaller screens without clipping, and splitScreenMode: true maintains proper layout behavior in split-screen mode on devices like Android tablets. Inside its builder, it returns a MaterialApp, which defines the app’s title and sets home: MyHomePage(), the main screen displayed when the app launches.

So far, this part sets up the environment for responsive scaling.

The Home Screen Layout `MyHomePage`

class MyHomePage extends StatelessWidget {
  const MyHomePage({Key? key}) : super(key: key);

The widget is stateless, meaning its layout does not depend on mutable state.

Inside build(BuildContext context):

final double screenWidth  = MediaQuery.of(context).size.width;
final double screenHeight = MediaQuery.of(context).size.height;
final Orientation orientation = MediaQuery.of(context).orientation;

These three lines access MediaQuery, a Flutter API that provides information about the screen’s size, orientation, and other layout properties, where screenWidth represents the device’s current screen width, screenHeight represents its height, and orientation indicates whether the device is in portrait or landscape mode.

You’ll use these values to dynamically adjust your layout.

The Scaffold and AppBar

return Scaffold(
  appBar: AppBar(
    title: Text(
      'Responsive UI',
      style: TextStyle(fontSize: 20.sp),
    ),
  ),

Explanation:

Scaffold provides the basic structure of the page, including the app bar, body, and optional elements like a floating action button or drawer. Inside the AppBar, the title text uses 20.sp instead of a fixed pixel value, .sp (scaled pixels) from flutter_screenutil ensures that the font size automatically adjusts to the screen’s pixel density and resolution, meaning a 20.sp text appears smaller on compact screens and scales up proportionally on larger devices like tablets.

SafeArea + LayoutBuilder

body: SafeArea(
  child: LayoutBuilder(
    builder: (context, constraints) {

Explanation:

SafeArea ensures that content does not overlap with system UI areas such as the notch, status bar, or navigation gestures, while LayoutBuilder provides the constraints (maximum width and height) of the available space inside its parent, enabling the creation of responsive layouts that adapt dynamically to the screen’s actual size at runtime.

Handling Large and Small Screens

if (constraints.maxWidth > 600) {
  // Tablet/Desktop layout
  return Row(
    children: [
      Expanded(
        flex: 2,
        child: Container(
          color: Colors.blueGrey[50],
          child: Center(
            child: Text(
              'Sidebar Panel',
              style: TextStyle(fontSize: 18.sp),
            ),
          ),
        ),
      ),
      Expanded(
        flex: 5,
        child: Container(
          padding: EdgeInsets.all(16.w),
          child: _buildMainContent(context),
        ),
      ),
    ],
  );
} else {
  // Mobile layout
  return SingleChildScrollView(
    child: Padding(
      padding: EdgeInsets.symmetric(horizontal: 16.w, vertical: 24.h),
      child: _buildMainContent(context),
    ),
  );
}

Explanation:

This block handles responsive breakpoints by determining how the UI adapts to different screen widths. If constraints.maxWidth > 600, the layout is treated as a tablet or desktop view. In this case, the UI uses a Row to divide the screen horizontally, with Expanded(flex: 2) creating a sidebar that takes two parts of the available width, and Expanded(flex: 5) creating the main content area that takes five parts, maintaining a 2:5 ratio. The sidebar displays “Sidebar Panel,” representing where side navigation or additional panels can appear on larger screens. For smaller screens (phones), the layout switches to a vertical arrangement using SingleChildScrollView to enable scrolling, with padding applied through scaled spacing (16.w horizontally and 24.h vertically). The _buildMainContent() function is reused to keep content logic consistent across all layouts.

Building the Core Content

Widget _buildMainContent(BuildContext context) {
  return Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: [
      Text(
        'Welcome to the Responsive App',
        style: TextStyle(fontSize: 24.sp, fontWeight: FontWeight.bold),
      ),
      SizedBox(height: 12.h),
      Text(
        'This UI adapts to different screen sizes automatically. Try resizing your window or changing the orientation.',
        style: TextStyle(fontSize: 16.sp),
      ),
      SizedBox(height: 24.h),
      Row(
        children: [
          Expanded(
            child: Image.asset(
              'assets/sample.jpg',
              width: double.infinity,
              height: 200.h,
              fit: BoxFit.cover,
            ),
          ),
        ],
      ),
      SizedBox(height: 24.h),
      Row(
        children: [
          Expanded(
            child: ElevatedButton(
              onPressed: () {},
              style: ElevatedButton.styleFrom(
                padding: EdgeInsets.symmetric(vertical: 14.h),
                textStyle: TextStyle(fontSize: 16.sp),
              ),
              child: Text('Get Started'),
            ),
          ),
        ],
      ),
    ],
  );
}

Explanation:

This method builds the actual visible content of the app. It uses a Column to stack widgets vertically, with crossAxisAlignment: CrossAxisAlignment.start aligning all child widgets to the start of the horizontal axis (left side in LTR layouts). Text widgets use .sp for responsive scaling, applying a larger font size (24.sp) for the title and a smaller, comfortable one (16.sp) for the body. SizedBox provides vertical spacing (12.h or 24.h), where .h scales proportionally to the screen height. A Row containing Image.asset uses Expanded to make the image fill the available width, with fit: BoxFit.cover ensuring the image fills its container correctly and height: 200.h allowing dynamic height scaling. Another Row contains an ElevatedButton that spans the available width through Expanded, with padding and font size scaling via EdgeInsets.symmetric(vertical: 14.h) and TextStyle(fontSize: 16.sp). Overall, the _buildMainContent() method produces a clean, scalable, and responsive layout that maintains visual consistency across all devices.

Why This Works

LayoutBuilder gives the parent constraints, letting you conditionally render different layouts for mobile and large screens. ScreenUtil ensures that all elements (text, padding, sizes) adapt proportionally. MediaQuery can be used if you need real-time adaptation based on device rotation, size, or padding. SafeArea prevents clipping under system UI areas.

Together, these techniques combine Flutter’s native flexibility with ScreenUtil’s scaling power, making the UI dynamic, elegant, and consistent across all platforms.

Key Takeaways

Always design with a reference size and scale up/down with flutter_screenutil.
Use LayoutBuilder or MediaQuery for breakpoints.
Test layouts in portrait/landscape and across small/large screens.
Avoid hardcoded pixel values, use .sp, .w, .h instead.
Keep your content modular with helper functions like _buildMainContent().

Conclusion

Creating responsive and adaptive UIs in Flutter is not just about making things “look okay” on different devices, it’s about crafting fluid, consistent, and usable experiences regardless of screen size, orientation or platform. By leveraging Flutter’s built-in layout widgets (Row, Column, Flexible, Expanded, LayoutBuilder), and coupling them with screen-aware APIs (MediaQuery, SafeArea, etc) and specialized packages (like flutter_screenutil), you can build apps that scale beautifully.

Key takeaways:

Think flexibility first: avoid rigid sizing.
Use screen size/constraints to decide layout variations (instead of device type).
Scale typography, images, paddings to maintain usability and aesthetics.
Always test on multiple devices/sizes/orientations.
Encapsulate responsive logic in reusable widgets to keep your code clean and maintainable.

With these practices in hand, you’ll be well-equipped to deliver visually stunning, well-performing, and truly responsive Flutter applications for 2024 and beyond.

References

“Adaptive and responsive design in Flutter”, Flutter Docs. (Flutter Docs)
“Building Responsive UIs in Flutter: Tips and Best Practices”. TheOneTechnologies blog. (TheOneTechnologies)
“Best strategy to implement responsive design : r/FlutterDev”, Reddit discussion. (Reddit)
“How to Make a Flutter App Responsive for Different Mobile Screen Sizes”, StackOverflow Q&A. (Stack Overflow)
“5 Best Practices to Build Robust and Responsive UIs in Flutter”, Somnio Software blog. (somniosoftware.com)

How to Create Tables Using the React-Data-Table-Component Library in React & TypeScript

Losalini Rokocakau — Wed, 27 Mar 2024 15:40:38 +0000

In this tutorial, I'll teach you how to use the react-data-table-component library in your React projects. You'll learn how to render a table that has features such as pagination, searching/filtering, and sorting.

I'll walk you through each step, from setting up a React and TypeScript project with Vite to using the react-data-table-component library to render a table.

To follow along with this tutorial, there are a few prerequisites:

A basic understanding of React and TypeScript
Basic knowledge of Bootstrap, which we'll use for styling
For Windows OS users, know how to use the PowerShell terminal (as you'll need an interactive terminal to create the project with Vite)
Node v20.11.1 installed
npm v10.2.4 installed
A code editor such as Visual Studio Code (VS Code) or Atom

Let's start creating the project!

What will we build

By the end of this tutorial, you will have built a table that displays a person's ID, name, height, and eye color.

The table will also have a search bar where users can search for a person based on the value of any of the four properties mentioned above.

Each row in the table will be selectable and each column will be sortable when the column header is clicked by a user.

1. Create a React and TypeScript Project

In the command line, create the project with the command below:

npm create vite@latest

Name the project react-data-table-tutorial .

Figure 1.0 Creating the React & TypeScript project with Vite on PowerShell command line. Naming the project react-data-table-tutorial.

Navigate to React with the up and down keys to select React. Choose React as the library you're going to use.

Figure 1.1 Selecting React as our framework by navigating to it on the list with up & down arrow keys on the keyboard.

Similar to the step above, navigate to TypeScript and choose it as the language to use.

The next step is to change directories into the project's folder. Once you've done that, open the project in your code editor as seen in Figure 1.2 below. I'll be using the VS Code editor in this tutorial.

Figure 1.2 Changing the folder into the react-data-table-tutorial directory and opening the contents of the folder into a code editor.

2. Remove the Default Code Set by React

This step is just to remove any default code and stylings in the files found in the src folder.

First, remove all default styling in the App.css file and replace it with the stylings below.

body {
    background-color: white;
    padding: 160px 500px;
}

Then remove the following from the App.tsx file:

the imported statements of the useState hook, reactLogo, and the viteLogo.
The destructured array and useState hook for the count variable and setCount function.
The returned JSX wrapped within the fragment of the App component.

The App component should look like the code-block below after all of those changes:

import './App.css';

function App(){
    return <>;
}

export default App;

3. Install the Libraries We'll Need

In the project, you will need to install a few libraries:

styled-components v3.23+
react-data-table-component v16.8.0+
Bootstrap v5.3.3

You will need to install the styled-components library to use with the react-data-table-component library.

In the command line, install all of these by using the commands below:

npm install styled-components

npm install react-data-table-components

npm install bootstrap@5.3.3

Figure 3.0 Installing the libraries on Visual Studio Code's built-in terminal.

The installed libraries are listed under dependencies in the package.json file.

{
   // rest of the code in the file
    "dependencies": {
        "boostrap": "^5.3.3",
        "react": "^18.2.0",
        "react-data-table-component": "^7.6.2",
        "react-dom": "^18.2.0",
        "styled-components": "^6.1.8",
    }
    // rest of the code in the file
}

4. Import Bootstrap in the App Component

In the App.tsx file, import the Bootstrap library at the top of the file.

This will allow us to use Bootstrap stylings throughout the project.

import "./App.css";
import "bootstrap/dist/js/bootstrap.bundle.min.js";

function App(){
   return <>;
}

export default App;

5. Create a Table Component

In the src folder, create a sub-directory and name it components. By convention, this is to hold all of the components of the project.

In the components folder, create a file called Table.tsx. This is for our Table component.

Create a function component called Table.

Figure 5.0 Create the Table component in the components sub-directory within the src folder.

6. Import the react-data-table-component Library to Start Using it

Import the react-data-table-component library into the Table component.

import DataTable from "react-data-table-component";

function Table(){
    return <>;
}

export default Table;

7. Create the Table in the Table Component

Create a

container within the fragment and add Bootstrap styling of container and my-5 to place the table in the center of the page.

Add the DataTable component as the child of the

container.

import DataTable from 'react-data-table-component';

function Table(){
    return (
        <>
            <div className="container my-5">
                <DataTable />
            div>
        
    );
}

Pass the columns and rows of the table as props to the DataTable component.

The column headers of the table are objects that will be stored in an array. The rows of the table will also be stored in a similar way. The array of objects for both will have these structures:

const columns = [
    {
        name: "ID",
        selector: row => row.id
    },
    {
        name: "Full Name",
        selector: row => row.fullName
    },
    {
        name: "Height",
        selector: row => row.height
    },
    {
        name: "Weight",
        selector: row => row.weight
    },
];

const rows = [
    {
        id: 1,
        fullName: "John Doe",
        height: "1.75m",
        weight: "89kg",
    },
    {
        id: 2,
        fullName: "Jane Doe",
        height: "1.64m",
        weight: "55kg",
    },
    {
        id: 3,
        fullName: "Sheera Maine",
        height: "1.69m",
        weight: "74kg",
    },
];

These constants are then passed into the DataTable component as such:

Create a columns constant that is an array of objects that has four columns headers for personID, fullName, height, and eyeColor.

Create a rows constant that is an array of objects that has 15 objects which is equivalent to data for 15 people.

Pass the two constants into their respective props in the DataTable component as seen in the next code-block.

function Table(){
    const columns = [
        {
            name: "ID",
            selector: (row) => row.personID,
        },
        {
            name: "Full Name",
            selector: (row) => row.fullName,
        },
        {
            name: "Height",
            selector: (row) => row.height,
        },
        {
            name: "eyeColor",
            selector: (row) => row.eyeColor,
        },
    ];

    const rows = [
        {
           personID: 1,
           fullName: "Kate Shein",
           height: "1.79m",
           eyeColor: "blue",
        },
        //....remaining objects for the 2nd to 14th person
        {
           personID: 15,
           fullName: "Isabella Thompson",
           height: "1.79m",
           eyeColor: "blue",
        },
    ];
}

You will also add the fixedHeader prop to the DataTable component to keep the column header fixed when a user scrolls down the table that has more than 10 records.

Give the table a title by passing the title prop to the component and its value is whatever you would like to call your table.

class="container">
    <DataTable 
        columns={columns} 
        data={rows} 
        fixedHeader
        title="React-Data-Table-Component Tutorial."
     />

Back in the App component, import the Table component and place it within the fragment.

import "./App.css";
import "bootstrap/dist/js/bootstrap.bundle.min.js";
import Table from "./components/Table";

function App(){
    return (
        <>
           <Table />
        
    );
}

export default App;

8. Add Pagination and Sorting, and Make Each Row Selectable

Pagination and `selectableRows`

Add the pagination and selectableRows props to the DataTable component.

By default, the first page has the first 10 records. If there needs to be API calls from the server side for custom pagination, then you can use the paginationServer property along with the paginationTotalRows, onChangeRowsPerPage and onChangePage properties which work in conjunction with a few other things.

But for now, let's stick with the pagination property.

//...rest of the code in the function component
"container d-flex justify-content-center my-5">
   <DataTable
        columns={columns}
        data={rows}
        fixedHeader
        title="React-Data-Table-Component Tutorial"
        pagination
        selectableRows
    />

//...rest of the code in the function component

Sorting

In the DataTable component, add the sortable property to each object in the columns constant. Give it a boolean value of true so that sorting is applied to each column when a user clicks on the column headers.

//...rest of the code in the function component
const columns = [
    {
        name: 'ID',
        selector: (row) => row.personID,
        sortable: true,
    },
    {
        name: 'Full Name',
        selector: (row) => row.fullName,
        sortable: true,
    },
    {
        name: 'Height',
        selector: (row) => row.height,
        sortable: true,
    },
    {
        name: 'Eye Color',
        selector: (row) => row.eyeColor,
        sortable: true,
    },
];
//...rest of the code in the function component

9. Add Searching and Filtering

Add a

container above the DataTable component in the returned JSX. Also add the bootstrap input-group class to the

The child element of this new container will be the of type search and we'll use Bootstraps' stylings for it. Use the code below:

"search"
    className="form-control-sm border ps-3"
    placeholder="Search"
/>

An optional step is to add a search icon or use Bootstraps' default styling for a search bar. However, we'll leave it out for now so we can focus solely on the searching functionality.

Now, let's import the useState hook into the Table.tsx file.

Use the hook and pass in the rows constant as the default value of our state variable. Within the destructured array will be our state variable called data and the setter function called setData.

const [data, setData] = useState(rows);

Create a function called handleSearch that will be called when the onChange event listener is used on the search bar.

Pass in the event object, e, as its argument. Using type annotation, set the type of the event object to React.ChangeEvent.

const handleSearch = (e: React.ChangeEvent) => {
   // the rest of the code will be defined in here
};

Declare 5 variables of Boolean type as seen below:

const handleSearch = (e: React.ChangeEvent) => {
   let searchValue: Boolean;
   let personIDValue: Boolean;
   let fullNameValue: Boolean;
   let heightValue: Boolean;
   let eyeColorValue: Boolean;
};

Declare a new local constant called newRows. In this constant, filter out and return the rows/data in the rows constant where the search input's value is the same as the value of the rows' fullName or height or eyeColor property.

const newRows = rows.filter((row) => {
      personIDValue = row.personID
        .toString()
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      fullNameValue = row.fullName
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      heightValue = row.height
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      eyeColorValue = row.eyeColor
        .toLowerCase()
        .includes(e.target.value.toLowerCase());

      if (personIDValue) {
        searchValue = personIDValue;
      } else if (fullNameValue) {
        searchValue = fullNameValue;
      } else if (heightValue) {
        searchValue = heightValue;
      } else {
        searchValue = eyeColorValue;
      }

      return searchValue;
});

Pass newRows into the setter function, setData.

setData(newRows);

// definition of the columns constant

// definition of the rows constant

const [data, setData] = useState(rows);

// Handle Search
const handleSearch = (e: React.ChangeEvent) => {
    let searchValue: Boolean;
    let personIDValue: Boolean;
    let fullNameValue: Boolean;
    let heightValue: Boolean;
    let eyeColorValue: Boolean;

    const newRows = rows.filter((row) => {
      personIDValue = row.personID
        .toString()
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      fullNameValue = row.fullName
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      heightValue = row.height
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      eyeColorValue = row.eyeColor
        .toLowerCase()
        .includes(e.target.value.toLowerCase());

      if (personIDValue) {
        searchValue = personIDValue;
      } else if (fullNameValue) {
        searchValue = fullNameValue;
      } else if (heightValue) {
        searchValue = heightValue;
      } else {
        searchValue = eyeColorValue;
      }

      return searchValue;
    });

    setData(newRows);
};

Next step is to pass (not call the function) the handleSearch function into the onChange event listener.

"search"
   className="form-control-sm border ps-3"
   placeholder="Search"
   onChange={handleSearch}
/>

The value of the data property in the DataTable component will now be the state variable, data instead of rows that was initially passed in.

"React-Data-Table-Component Tutorial."
    pagination
    selectableRows
/>

10. View the Table

Run the project in the command line and view the table in a browser:

command line npm run dev

The table should look something like this:

Figure 11.0 Preview of the resulting table created.

You can read through the documentation for react-data-table-component as it has more in-depth coverage of the library's usage that goes beyond the scope of this article.

Don't fret if there's a difference in your table from the expected result. The source code in this repository will guide you.

Happy coding and may your code run smoothly!

How to Use Shadcn with Next.js 14

Sahil — Thu, 01 Feb 2024 15:21:36 +0000

Shadcn is a collection of beautifully designed, accessible, and customizable React components that you can use to build modern web applications with Next.js. With Shadcn, you can quickly and easily create user interfaces that are both stylish and functional.

If you are looking for a way to build modern, stylish, and accessible web applications with Next.js, then Shadcn is a great option.

In this guide, you'll learn how to install and use Shadcn in your Next.js projects, how to style elements, and how to customize Shadcn components.

What is Shadcn?
How to Install Next.js and Shadcn
How to Install Next.js
How to Install Shadcn
How to Use Shadcn in Next.js
How to Style a Button The Hard Way and The Shadcn Way
How to Add a Component from Shadcn
Styling a Button The Hard Way
Styling a Button The Shadcn Way
How to Customize Shadcn Components
Conclusion

What is Shadcn?

Shadcn UI is not specifically a component library or UI framework. As stated in the documentation, it is described as "a compilation of reusable components that can be easily copied and pasted into our applications."

Shadcn leverages Tailwind CSS and Radix UI as its foundation. It presently offers compatibility with Next.js, Gatsby, Remix, Astro, Laravel, and Vite. There's a manual integration guide that can help you incorporate it with other technologies.

You can get the complete source code for this tutorial here.

How to Install Next.js and Shadcn

I'll follow the instructions in the Shadcn docs, so you can follow along if you like.

First, you have to choose what framework you are currently using. This article and the code in my repo above was written with Next.js in mind, so select the Next.js option.

Choose a framework to set up Shadcn

Now, you need to install and configure a new Next.js project.

How to Install Next.js

I typically use npm, but if you use a different package manager, feel free to copy a command for your respective package manager below.

To install Next.js with npm:

npx create-next-app@latest my-app --typescript --tailwind --eslint

To install Next.js with yarn:

yarn create next-app@latest my-app --typescript --tailwind --eslint

To install Next.js with pnpm:

pnpm create next-app@latest my-app --typescript --tailwind --eslint

To install Next.js with bun:

bunx --bun create-next-app@latest my-app --typescript --tailwind --eslint

After running one of those commands, you'll see the following configuration questions:

Need to install the following packages:
create-next-app@14.1.0
Ok to proceed? (y) y
✔ Would you like to use `src/` directory? … No / Yes
✔ Would you like to use App Router? (recommended) … No / Yes
✔ Would you like to customize the default import alias (@/*)? … No / Yes

I selected "No" for the first question as I don't want to have a src directory inside my app directory.

I selected "Yes" for the second question because I want to use app router, which is the recommended way to go for Next.js 14.

Finally, I selected "No" for the third question because I like the way import works with @ in Next.js 14.

How to Install Shadcn

Before continuing, remember to go into the my-app directory in your terminal:

cd my-app

To initialize Shadcn with npm:

npx shadcn-ui@latest init

To initialize Shadcn with yarn:

npx shadcn-ui@latest init

To initialize Shadcn with pnpm:

pnpm dlx shadcn-ui@latest init

To initialize Shadcn with bun:

bunx --bun shadcn-ui@latest init

After running one of those commands you'll see some configuration questions again, but this time they're for Shadcn:

✔ Which style would you like to use? › New York
✔ Which color would you like to use as base color? › Slate
✔ Would you like to use CSS variables for colors? › yes

You can see the questions and my responses in the code above.

For the first question, there are two options, default and New York. I chose the "New York" style.

For the second question, there are five options Slate, Gray, Zinc, Neutral, Stone. I chose Slate because I like a minimalist black and white styling.

For the third question, I there are two options Yes and No. I chose yes, as I prefer to have CSS variables enabled for styling (although we won't be using this in this article).

You can read more about the style options, base options, and this configuration setup here.

And with that, you've set up a new Next.js 14 project with Shadcn.

Now you can see two new directories that have been added to your project directory, components and lib.

Notice that the components directory is currently empty, which means that Shadcn doesn't load up your project with any components you might not use. This gives you a lot of flexibility and keeps your project lightweight (so you can just add the components you need).

How to Use Shadcn in Next.js

First, let's remove all the boilerplate code from the my-app project's page.tsx file. (You only need to remove the boilerplate code from my-app/page.tsx.)

After removing all the boilerplate code from the page.tsx file inside the app directory, I'll add a simple hello world text.

Here's the updated page.tsx code:

export default function Home() {
  return (
    <>
      Hello World
    
  );
}

And here's what your project should look like in the browser:

Hello World setup for the Next.js project

How to Style a Button the Hard Way and the Shadcn Way

Now, lets add two buttons to the page. One button will be simple with no styling, and the other will be a component from Shadcn.

How To Add a Component from Shadcn

Before we add our buttons, though, we have to learn how to add a component from Shadcn into our project. Here's how to do that:

Go to the Shadcn docs.
Click on whatever component you want to use.
Then you'll see the command you should run to add that component to your project.
Finally, import that component into your project and start using it.

To add the Button component from Shadcn, follow these steps:

Go to the Button component page.
Then run this command in your terminal: npx shadcn-ui@latest add button. Note: This command is for npm – if you use a different package manager, you'll need to modify the command slightly.
Finally, import the button component in the file where you want to use it.

Now we'll see examples of adding a button in two different ways: using Tailwind CSS, and using Shadcn.

Styling a Button the Hard Way (Using Tailwind)

export default function Home() {
  return (
    <>
      
    
  );
}

Custom button with orange background

I have created a button with an orange background having a padding of 2 units. You can see that it looks ugly and also doesn't have any hover effects by default.

Styling a Button the Shadcn Way

import { Button } from "@/components/ui/button";

export default function Home() {
  return (
    <>
      
    
  );
}

Shadcn default button

To use the Shadcn button, first import the Button component to the file where you want to use it – you don't need to add any styling to it (You can customize it, which you'll learn how to do in the next section). By default it looks good and it has hover effects. So just import the component and then you can use it.

You can also play around with the different options that Shadcn components give you. Either go to the docs page of that component and take a look at the options or open up the component's source code that is inside the components/ui directory.

Let's take a look at button.tsx source code to check how many variants of buttons you can create.

import * as React from "react";
import { Slot } from "@radix-ui/react-slot";
import { cva, type VariantProps } from "class-variance-authority";

import { cn } from "@/lib/utils";

const buttonVariants = cva(
  "inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:pointer-events-none disabled:opacity-50",
  {
    variants: {
      variant: {
        default:
          "bg-primary text-primary-foreground shadow hover:bg-primary/90",
        destructive:
          "bg-destructive text-destructive-foreground shadow-sm hover:bg-destructive/90",
        outline:
          "border border-input bg-background shadow-sm hover:bg-accent hover:text-accent-foreground",
        secondary:
          "bg-secondary text-secondary-foreground shadow-sm hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "h-9 px-4 py-2",
        sm: "h-8 rounded-md px-3 text-xs",
        lg: "h-10 rounded-md px-8",
        icon: "h-9 w-9",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

export interface ButtonProps
  extends React.ButtonHTMLAttributes,
    VariantProps {
  asChild?: boolean;
}

const Button = React.forwardRef(
  ({ className, variant, size, asChild = false, ...props }, ref) => {
    const Comp = asChild ? Slot : "button";
    return (
      
    );
  }
);
Button.displayName = "Button";

export { Button, buttonVariants };

You can see that there's a variants object, and inside that there are multiple variants to choose from. Notice that there's a size object that allows you to choose different sizes for the button as well.

You can also see that there's a defaultVariants object that stores the default variant and the default size of the button.

How to Customize Shadcn Components

Remember that after installing Shadcn, the components directory was empty. But after adding the Button component, you can see that there's a ui directory inside components directory. And inside the ui directory you'll have the Button.tsx file, which is the code for the Button component.

If you open the Button.tsx file, you'll see that there are multiple variants of the Button component like default, destructive, outline, secondary, ghost, and link. There's also a default size, and other sizes to choose from:

import * as React from "react"
import { Slot } from "@radix-ui/react-slot"
import { cva, type VariantProps } from "class-variance-authority"

import { cn } from "@/lib/utils"

const buttonVariants = cva(
  "inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:pointer-events-none disabled:opacity-50",
  {
    variants: {
      variant: {
        default:
          "bg-primary text-primary-foreground shadow hover:bg-primary/90",
        destructive:
          "bg-destructive text-destructive-foreground shadow-sm hover:bg-destructive/90",
        outline:
          "border border-input bg-background shadow-sm hover:bg-accent hover:text-accent-foreground",
        secondary:
          "bg-secondary text-secondary-foreground shadow-sm hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "h-9 px-4 py-2",
        sm: "h-8 rounded-md px-3 text-xs",
        lg: "h-10 rounded-md px-8",
        icon: "h-9 w-9",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
)

export interface ButtonProps
  extends React.ButtonHTMLAttributes,
    VariantProps {
  asChild?: boolean
}

const Button = React.forwardRef(
  ({ className, variant, size, asChild = false, ...props }, ref) => {
    const Comp = asChild ? Slot : "button"
    return (
      
    )
  }
)
Button.displayName = "Button"

export { Button, buttonVariants }

One of the best parts about Shadcn components is that you can customize them and remove variants that you won't use. You can also add your own variants to the component.

For example, say that you want to add the custom button we coded first as a Shadcn Button component variant. You can do that like this:

import * as React from "react";
import { Slot } from "@radix-ui/react-slot";
import { cva, type VariantProps } from "class-variance-authority";

import { cn } from "@/lib/utils";

const buttonVariants = cva(
  "inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:pointer-events-none disabled:opacity-50",
  {
    variants: {
      variant: {
        default:
          "bg-primary text-primary-foreground shadow hover:bg-primary/90",
        destructive:
          "bg-destructive text-destructive-foreground shadow-sm hover:bg-destructive/90",
        outline:
          "border border-input bg-background shadow-sm hover:bg-accent hover:text-accent-foreground",
        secondary:
          "bg-secondary text-secondary-foreground shadow-sm hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
        link: "text-primary underline-offset-4 hover:underline",
        myButton: "p-2 bg-orange-400",
      },
      size: {
        default: "h-9 px-4 py-2",
        sm: "h-8 rounded-md px-3 text-xs",
        lg: "h-10 rounded-md px-8",
        icon: "h-9 w-9",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

export interface ButtonProps
  extends React.ButtonHTMLAttributes,
    VariantProps {
  asChild?: boolean;
}

const Button = React.forwardRef(
  ({ className, variant, size, asChild = false, ...props }, ref) => {
    const Comp = asChild ? Slot : "button";
    return (
      
    );
  }
);
Button.displayName = "Button";

export { Button, buttonVariants };

Notice, I have added a new variant myButton and then simply pasted the styling that we used for the custom button. That's it and now you have your own custom button inside the Shadcn Button component.

Notice that the code now includes a new variant named myButton, and I simply pasted in the styling for the custom button from our ealier example. And that's it! Now you have your own custom Shadcn Button component variant.

Here's how you can use the custom myButton variant in your project:

import { Button } from "@/components/ui/button";
export default function Home() {
  return (
    "flex justify-center items-center flex-col gap-10">
      
      
      
      
      
    
  );
}

Shadcn multiple variants buttons

Note that I've added more variants of the Button component, just to show you that you can create multiple types of buttons with different sizes very easily.

The last button in the example above has the variant myButton, which is the custom variant you added to the Button.tsx file. But that just affects the styling, and you can add your own custom size if you'd like.

Conclusion

In this guide you learned how to integrate Shadcn in your Next.js projects. You can dive further into Shadcn's extensive component library and use them as-is, or you can customize them to your heart's content. The power to create your next app awaits – go build it!

If you have any feedback on this article, then please DM me on Twitter.

How to Add Custom Buttons to a Date Picker in Flatpickr

Idris Abdul-Lateef — Wed, 17 Jan 2024 16:34:00 +0000

If you've ever had to use a date picker in a web frontend project, chances are that you've used flatpickr.

For the unacquainted, flatpickr is one of the most popular date picker libraries in the open source-verse. It's framework-agnostic, highly customizable, and lightweight.

I recently had to use it in a Next.js codebase and there was a peculiar use case I had. The built-in behavior is that dates are applied immediately when selected, and thereafter the date picker disappears.

What I really wanted, however, was to be able to pick dates and not have the modal disappear the moment I did so. I wanted to be able to keep picking dates and only have it applied when I clicked on an "Apply" button. I also wanted a "Clear" button to clear applied dates.

Ordinarily, flatpickr's API has methods you can work with to get these functionalities, but you won't get buttons on the date picker itself.

Even while there is a plugin that adds a button to the date picker to manually apply dates, it doesn't work for date ranges (which was what I needed it for) and the button's look didn't really blend with the overall theme of the app I was building.

I had no other option but to come up with my own solution. But how do you get your own buttons to appear on flatpickr's date picker?

How to Set Up flatpickr

First things first, install the package:

npm install flatpickr

Next, you need a DatePicker component that will encapsulate the custom date picker and make it reusable. This component should have an onChange prop which will be passed a callback that will be called whenever a date is applied:

// DatePicker.tsx

const DatePicker: React.FC = ({ onChange }) => {
  return 
}

export default DatePicker

interface DatePickerProps {
  onChange: (date: Date[]) => void
}

Next, you'll need to set up flatpickr itself. You're going to bring in some exports from the flatpickr package. In the markup, you'll add a text input element, which will be the date picker input, and pass it an element ref variable that'll be used to instantiate the flatpickr instance with a couple of configuration options:

// DatePicker.tsx

import { ElementRef, useEffect, useRef, useState } from "react"
import flatpickr from "flatpickr"

import { Instance as Flatpickr } from "flatpickr/dist/types/instance"
import "flatpickr/dist/flatpickr.min.css"

const DatePicker: React.FC = ({ onChange }) => {
  const [flatpickrInstance, setFlatpickrInstance] = useState()
  const datePickerRef = useRef>(null)

  useEffect(() => {
    if (datePickerRef.current) {
      const flatpickrInstance = flatpickr(datePickerRef.current, {
        static: true,
        closeOnSelect: false,
      })

      setFlatpickrInstance(flatpickrInstance)
    }

    return () => flatpickrInstance?.destroy()
  }, [])

  return (
    
      
    
  )
}
...

For the configuration options, static is set to true so the date picker modal is anchored to the date picker input and closeOnSelect is false so the date picker modal doesn't disappear when a date is selected.

This is how the date picker looks so far:

How to Add the Buttons

We've arrive at the main attraction of the day. From the snippet below, you'll notice two new imports: createPortal from react-dom and a pre-styled Button component. createPortal is going to play a very special role as you'll see.

// DatePicker.tsx

import { ElementRef, useEffect, useRef, useState } from "react"
import { createPortal } from "react-dom"
import flatpickr from "flatpickr"
import Button from "./Button"

import { Instance as Flatpickr } from "flatpickr/dist/types/instance"
import "flatpickr/dist/flatpickr.min.css"

...

Moving on to the body of the DatePicker component, you'll notice some changes too.

There's dates which will store selected date(s) (or an empty array if no date is selected) and applyDate which will hold the callback to call when the 'Apply' button is clicked.

In the configuration object, you'll find two flatpickr hooks: onChange that gets triggered whenever a date is picked and receives an array of the currently selected dates, and onClose that gets triggered when the date picker modal is closed.

Within the body of these hooks are implementations that specify the date picker's behavior.

// DatePicker.tsx

...
const DatePicker: React.FC = ({ onChange }) => {
  const [flatpickrInstance, setFlatpickrInstance] = useState()
  const datePickerRef = useRef>(null)
  const dates = useRef([])
  const [applyDate, setApplyDate] = useState(() => () => {})

  useEffect(() => {
    if (datePickerRef.current) {
      const flatpickrInstance = flatpickr(datePickerRef.current, {
        static: true,
        closeOnSelect: false,
        onChange: (selectedDates) => {
          if (selectedDates.length === 0) {
            onChange([])
            dates.current = []
          }

          setApplyDate(() => {
            return () => {
              dates.current = selectedDates
              onChange(selectedDates)
              flatpickrInstance.close()
            }
          })
        },
        onClose: () => {
          flatpickrInstance.setDate(dates.current)
        },
      })

      setFlatpickrInstance(flatpickrInstance)
    }

    return () => flatpickrInstance?.destroy()
  }, [])


  return (
      
...

We've gotten to the part where you finally put the custom buttons inside the date picker. This is where createPortal comes to shine.

The flatpickrInstance has a property, calendarContainer, which holds a reference to the date picker's containing div element. This is where you'll project the custom buttons, just beneath the calendar part of the date picker, using react portal.

// DatePicker.tsx

...
  return (
    
      
      {flatpickrInstance &&
        createPortal(
          
            ,
          flatpickrInstance.calendarContainer
        )}
    
  )
}

export default DatePicker
...

Put together, this is the final code output:

// DatePicker.tsx

import { ElementRef, useEffect, useRef, useState } from "react"
import { createPortal } from "react-dom"
import flatpickr from "flatpickr"
import Button from "./Button"

import { Instance as Flatpickr } from "flatpickr/dist/types/instance"
import "flatpickr/dist/flatpickr.min.css"

const DatePicker: React.FC = ({ onChange }) => {
  const [flatpickrInstance, setFlatpickrInstance] = useState()
  const datePickerRef = useRef>(null)
  const dates = useRef([])
  const [applyDate, setApplyDate] = useState(() => () => {})

  useEffect(() => {
    if (datePickerRef.current) {
      const flatpickrInstance = flatpickr(datePickerRef.current, {
        static: true,
        closeOnSelect: false,
        onChange: (selectedDates) => {
          if (selectedDates.length === 0) {
            onChange([])
            dates.current = []
          }

          setApplyDate(() => {
            return () => {
              dates.current = selectedDates
              onChange(selectedDates)
              flatpickrInstance.close()
            }
          })
        },
        onClose: () => {
          flatpickrInstance.setDate(dates.current)
        },
      })

      setFlatpickrInstance(flatpickrInstance)
    }

    return () => flatpickrInstance?.destroy()
  }, [])

  return (
    
      
      {flatpickrInstance &&
        createPortal(
          
            ,
          flatpickrInstance.calendarContainer
        )}
    
  )
}

export default DatePicker

interface DatePickerProps {
  onChange: (date: Date[]) => void
}

And this is how the date picker now looks with the custom buttons:

Conclusion

The date picker is now fully functional and can work for all mode options. There are tons of potential customizations you could possibly do using this technique. Hopefully, this article has done a good job of showing how flatpickr customization can be achieved.

❤️Enjoyed this article?

See more of my content! You can find more articles on my blog.

Want to connect? Link up with me on Twitter or LinkedIn.

How to Use Un-Styled UI Components – Guide for Front-End Developers

Chinenye Anikwenze — Tue, 29 Aug 2023 15:56:00 +0000

Imagine this situation: you are working on a time-sensitive project, and you need to implement some specific UI components that comply with accessibility best practices.

You may know about some libraries that are full of pre-designed UI elements, each with their own style. But here's the catch – you might only need a handful of these components. So why make your application bulkier? In reality, a significant portion of the bundled styles might go unused.

Well don't worry – that's where un-styled UI components come in.

What are Un-styled UI Components?

Un-styled UI components are accessible UI building blocks without pre-set styles. This grants you unmatched authority over the visual presentation and behavior of these interfaces.

The term "un-styled" doesn't signify a lack of design – rather, it refers to a blank slate that lets you infuse your creativity and branding without the limitations that come with traditional UI elements.

This enables you to tailor the components to your application's distinct needs, while also prioritizing aesthetics and accessibility.

Benefits of Un-styled UI Components

Let's delve into the key features that set un-styled components apart and explore why they may be a must-have for your upcoming projects.

Control Over Visual Appearance and Functionality:

Conventional UI libraries have preset styles that might not align with your design or aesthetics.

Let's use this scenario, for instance: you're working on an e-commerce platform that needs a product catalog. With unstyled UI components, you can tweak each product card's look, hover effects, and interactions to mirror your brand's identity.

This freedom extends to colors, typography, and layout choices, resulting in a coherent, captivating experience unique to your app.

Reduced Overhead and Enhanced Performance:

Often, in personal projects, we only require a handful of components from extensive libraries. But incorporating these libraries can introduce unnecessary styles and bulk that slow things down.

Un-styled components tackle this issue by letting you include only what you need. This speeds up your app, making it leaner and more efficient, without unnecessary dependencies.

Flexibility for Customization

Un-styled components empower you to craft elements seamlessly tailored to your project's demands. This covers their appearance, movements, and reactions to user interactions.

Whether you're building a simple form or a complex interactive feature, un-styled components give you the freedom to mold every detail to align with your design and purpose, harmonizing with your app's overall style.

Accessibility and User-Friendliness

Crafting accessible interfaces that adhere to WAI-ARIA design principles is important for developers. Unstyled UI components, often designed with accessibility in focus, offer enhanced usability for a broader user spectrum. This abstraction eliminates manual implementation.

Future-Ready Development

Technology evolves, and so do design trends and user expectations. Un-styled components ensure you're primed for what lies ahead. Integrating them empowers you to adapt your app's look and feel as trends shift, without being constrained by outdated styles.

Modular and Scalable Architecture

Un-styled components resemble building blocks that seamlessly fit into your project. This streamlines your code and makes it easier to manage. It also lets you reuse these blocks across different app sections, saving time while preserving consistency as your project expands.

Exploring Popular Un-styled UI Components

To give you more context into how un-styled components work, we'll now compare modal components from five common un-styled UI component libraries.

For most of these components, the Dialog components facilitate the creation of interactive, visually pleasing modal boxes for actions like profile editing, confirming decisions, or displaying extra information without navigating from the main content.

I'll also outline the overall features of these component libraries so you'll be able to integrate them into your future projects.

Let's now dive into a selection of the most notable un-styled UI component libraries and examine their dialog components.

Radix UI

Radix UI's Dialog component, which you can find in the @radix-ui/react-dialog package, is a versatile tool that helps you build popup windows in your React apps. It allows you to interact with certain areas of your program without leaving the current screen.

You can create many types of popup windows, including those that stop the flow (modal) and those that do not (non-modal).

For designing comprehensive dialogs, you have numerous building pieces including Trigger, Portal, Overlay, Content, Title, Description, and Close. You can style it to match your design. It also adheres to accessibility requirements so that everyone can use it.

When you press the Escape key or click the close button, the dialog closes. For screen reader users, special components such as Title and Description are available.

The documentation is extensive and provides examples for several scenarios and It works well with the React ecosystem.

Sample code from Radix:

To get started with Radix, you can run this command on your terminal:

npm install @radix-ui/react-popover@latest -E

To use the dialog component, you can import the components like so:

import React from 'react';
import * as Dialog from '@radix-ui/react-dialog';

const DialogComponent = () => (
  <Dialog.Root>
    <Dialog.Trigger asChild>
      <button>Open profilebutton>
    Dialog.Trigger>
    <Dialog.Portal>
      <Dialog.Overlay className="DialogOverlay" />
      <Dialog.Content className="DialogContent">
        <Dialog.Title className="DialogTitle">Edit profileDialog.Title>
        <Dialog.Description className="DialogDescription">
          Make changes to your profile here. Click save when you're done.
        Dialog.Description>
        <fieldset>
          <label className="Label" htmlFor="name">
            Name
          label>
          <input className="Input" id="name" defaultValue="Chinenye A" />
        fieldset>
        <fieldset className="Fieldset">
          <label className="Label" htmlFor="username">
            Username
          label>
          <input className="Input" id="username" defaultValue="@chinenye" />
        fieldset>
        <div style={{ display: 'flex', marginTop: 25, justifyContent: 'flex-end' }}>
          <Dialog.Close asChild>
            <button className="Button green">Save changesbutton>
          Dialog.Close>
        div>
        <Dialog.Close asChild>
          <button className="IconButton" aria-label="Close">
         Button
          button>
        Dialog.Close>
      Dialog.Content>
    Dialog.Portal>
  Dialog.Root>
);

export default DialogComponent;

Here's what it looks like:

Modal screen of the dialog component from Radix UI

To learn more about Radix and its other components, you can check out their documentation here.

shadcn's UI Component

shadcn UI components, which are based on Radix UI and Tailwind CSS, deliver a seamless and integrated user experience.

shadcn is efficient and lightweight because you can install only the components that you require. It supports two kinds of popup windows:

Those that require a response before closing Alert Dialog
Those that don't (which is useful for displaying messages)

The shadcn UI component is versatile since you can overlay content on the main screen or another popup. It's simple to use for keyboard and screen reader users as well.

To make your popups more visually appealing, you can apply effects like fading, sliding, or zooming. You can combine this with menus such as Context Menus or Dropdown Menus (also part of the Shadcn components) to increase functionality.

The components for the dialog are divided into sections like DialogTrigger, DialogContent, DialogHeader, among others for simpler implementation.

Sample code from shadcn:

To get started, you can install the shadcn dialog component by running
npx shadcn-ui@latest add dialog.

To use the component on your projects, you can import them like this:

import {
  Dialog,
  DialogContent,
  DialogDescription,
  DialogHeader,
  DialogTitle,
  DialogTrigger,
} from "@/components/ui/dialog"


  <DialogTrigger>OpenDialogTrigger>
  <DialogContent>
    <DialogHeader>
      <DialogTitle>Are you sure absolutely sure?DialogTitle>
      <DialogDescription>
        This action cannot be undone. This will permanently delete your account
        and remove your data from our servers.
      DialogDescription>
    DialogHeader>
  DialogContent>

And here's the result of the above code:

Shadcn dialog display

You can read their documentation for other use cases.

Headless UI Library:

Headless UI Library provides a fully managed, flexible approach to constructing modal windows. You can use it in both React and Vue applications.

The library lets you customize popup windows to match the look and feel of your program. It also has built-in accessibility features, making it usable by keyboard and screen reader users.

To fit the appearance of your application, you can style the Dialog and Dialog.Panel components with className or style props. The Dialog.Panel can have an overlay or backdrop that can be animated individually to grab attention. It enables you to use CSS to build scrollable dialogs.

The library provides seamless transitions while opening and dismissing popups, which improves the visual experience.

Code Sample from Headless UI:

To get started with this library, you can run this command to install it:
npm install @headlessui/react.

You can use the dialog components as depicted below:

import { Dialog, Transition } from '@headlessui/react'
import { Fragment, useState } from 'react'

export default function MyModal() {
  let [isOpen, setIsOpen] = useState(true)

  function closeModal() {
    setIsOpen(false)
  }

  function openModal() {
    setIsOpen(true)
  }

  return (
    <>
      <div className="fixed inset-0 flex items-center justify-center">
        <button
          type="button"
          onClick={openModal}
          className="rounded-md bg-black bg-opacity-20 px-4 py-2 text-sm font-medium text-white hover:bg-opacity-30 focus:outline-none focus-visible:ring-2 focus-visible:ring-white focus-visible:ring-opacity-75"
        >
          Open dialog
        button>
      div>

      <Transition appear show={isOpen} as={Fragment}>
        <Dialog as="div" className="relative z-10" onClose={closeModal}>
          <Transition.Child
            as={Fragment}
            enter="ease-out duration-300"
            enterFrom="opacity-0"
            enterTo="opacity-100"
            leave="ease-in duration-200"
            leaveFrom="opacity-100"
            leaveTo="opacity-0"
          >
            <div className="fixed inset-0 bg-black bg-opacity-25" />
          Transition.Child>

          <div className="fixed inset-0 overflow-y-auto">
            <div className="flex min-h-full items-center justify-center p-4 text-center">
              <Transition.Child
                as={Fragment}
                enter="ease-out duration-300"
                enterFrom="opacity-0 scale-95"
                enterTo="opacity-100 scale-100"
                leave="ease-in duration-200"
                leaveFrom="opacity-100 scale-100"
                leaveTo="opacity-0 scale-95"
              >
                <Dialog.Panel className="w-full max-w-md transform overflow-hidden rounded-2xl bg-white p-6 text-left align-middle shadow-xl transition-all">
                  <Dialog.Title
                    as="h3"
                    className="text-lg font-medium leading-6 text-gray-900"
                  >
                    Payment successful
                  Dialog.Title>
                  <div className="mt-2">
                    <p className="text-sm text-gray-500">
                      Your payment has been successfully submitted. We’ve sent
                      you an email with all of the details of your order.
                    p>
                  div>

                  <div className="mt-4">
                    <button
                      type="button"
                      className="inline-flex justify-center rounded-md border border-transparent bg-blue-100 px-4 py-2 text-sm font-medium text-blue-900 hover:bg-blue-200 focus:outline-none focus-visible:ring-2 focus-visible:ring-blue-500 focus-visible:ring-offset-2"
                      onClick={closeModal}
                    >
                      Got it, thanks!
                    button>
                  div>
                Dialog.Panel>
              Transition.Child>
            div>
          div>
        Dialog>
      Transition>
    
  )
}

Here's what that looks like:

Sample modal made with Headless UI

For more details about this component, you can check out their documentation.

PrimeReact UI

PrimeReact UI has a flexible Dialog component that lets you show content in overlay windows.

The dialog's appearance and disappearance times can be changed. It includes tools like resizing and drag-and-drop as well.

It automatically inserts a scrollbar for easy navigation if the material is too long. Based on various screen widths, you can adjust the dialog's width. The position setting allows you to place the dialog in different screen corners.

It is compatible with screen readers and keyboard navigation because it was created with accessibility in mind. Keyboard keys allow users to traverse the dialog. It complies with integration best practices and works nicely with other libraries.

Code sample from PrimeReact UI:

To get started, run this command on your terminal:

npm install primereact

Here is a code snippet of the dialog component:

import React, { useState } from "react";
import { Button } from 'primereact/button';
import { Dialog } from 'primereact/dialog';

export default function BasicDemo() {
    const [visible, setVisible] = useState(false);

    return (
        <div className="card flex justify-content-center">
            <Button label="Show" icon="pi pi-external-link" onClick={() => setVisible(true)} />
            <Dialog header="Header" visible={visible} style={{ width: '50vw' }} onHide={() => setVisible(false)}>
                <p className="m-0">
                    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 
                    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
                    consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. 
                    Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
                p>
            Dialog>
        div>
    )
}

Here's what it looks like:

Position of dialog component on center-right of the screen

For more information about the library, visit their documentation here.

Reach UI Dialog Component:

The Reach UI Dialog component is a great option for designing user friendly and accessible popup windows.

It provides accurate control and is simple to use. It functions flawlessly on a variety of gadgets. It has usability enhancing accessibility features, and it's simple to make alert popups.

It also supports pinch zooming and is compatible with iPads and iPhones.

Code Sample from Reach UI:

To get started, you can run this command on your terminal to install the components: npm install @reach/dialog.

To use the components within your application, you can import them like this:

import { Dialog, DialogOverlay, DialogContent } from "@reach/dialog";
import "@reach/dialog/styles.css";

function Dialog() {
  const [showDialog, setShowDialog] = React.useState(false);
  const open = () => setShowDialog(true);
  const close = () => setShowDialog(false);

  return (
    <div>
      <button onClick={open}>Open Dialogbutton>

      <Dialog isOpen={showDialog} onDismiss={close}>
        <button className="close-button" onClick={close}>
          <VisuallyHidden>CloseVisuallyHidden>
          <span aria-hidden>×span>
        button>
        <p>Hello there. I am a dialogp>
      Dialog>
    div>
  );
}

Here's what they look like:

Dialog component from reach ui

To learn more about this library and its components, you can check out their documentation here.

Wrapping Up

This article highlighted several popular un-styled component libraries, including Radix UI, shadcn's UI Component, Headless UI Library, PrimeReact UI, and Reach UI Dialog Component.

To sum up, using un-styled UI components lets you customize your components according to your needs. It also brings performance efficiency and future adaptability.

These components offer reduced overhead, as they let you use only the components you need. This results in a more efficient application.

The flexibility of un-styled components also lets you tailor elements for specific project requirements, while prioritizing accessibility and user-friendliness. Integrating un-styled UI components elevates your ability to create accessible, visually appealing, and efficient user interfaces.

Astro UI Framework [Full Book]

freeCodeCamp — Wed, 12 Jul 2023 20:58:29 +0000

By Emmanuel Ohans

Astro is a new UI framework that's designed for speed. And if you want to learn how to use it, you've come to the right place.

Introduction
Chapter 1: Build your first Astro Application
Chapter 2: Astro Components In-depth
Chapter 3: Build Your Own Component Island
Chapter 4: The Secret Life of Astro Component Islands
Chapter 5: Oh my React! (How to Build a React Documentation Site Clone)
Chapter 6: Server-side Rendering (SSR) in Astro
Chapter 7: Be Audible! (How to Build a Fullstack Astro Project)
Chapter 8: Build Your Own Astro Integrations
Conclusion

Introduction

I'm not one of those bandwagon-jumping folks who drool over every shiny new library or framework that hits the scene just because it's trending. I'm more of a "wait-and-see" kinda person.

So, you're probably wondering why I wrote a book about the reasonably new UI framework, Astro.

Well, let me tell you.

I’ve been in this game for almost a decade now, and I've seen frameworks come and go like a bad case of indigestion. And Astro may not live forever, either.

But here's the thing: when you use a new UI framework, it's not just about getting stuff to work and slapping some apps together willy-nilly. No, no, no. The real magic lies in understanding the principles and concepts behind the framework's creation. And that's exactly the mindset I had when I wrote this book.

You’ve got to ask yourself: what makes this framework so unique? How is it different from all the other fluff out there? How can you apply its mental model to the bigger picture of developing applications for the web? Plus, what framework-agnostic principles can you pick up along the way?

The good news is I've got answers to all these burning questions sprinkled throughout the book like confetti.

Now, let's talk about performance, shall we? Of course, that’s a whole different ballgame depending on what kind of application you're dealing with. But for specific applications, for example content-focused applications, Astro is a total game-changer. Its performance defaults are off the charts.

The more I researched Astro, the more I was fascinated to write this book.

And here's the kicker: this book goes beyond just Astro. In specific chapters, we will discuss concepts you can apply to whatever framework you work with. And that's not just cool – that’s downright practical.

Astro is paving the way for a new architecture on the web: the component island architecture. And my goal is to help you understand it well enough to build some seriously robust production applications.

So, don't just scratch the surface. Instead, let’s dive deep and get to know this framework.

This is why I am writing this book. And hey, six months in, and I’m still loving it.

So, what are you waiting for? Grab your favourite drink (tea over coffee, here), dig in, and let's get building!

Cheers 🥂

A Note About This Book

Okay, if you haven’t already noticed, I write like I speak. I use plain language and analogies that even my nan could (potentially) understand — when I do it right.

This book does not read in a typical technical documentation style—sorry, fellow nerds.

In my opinion, technical books should be easy on the eyes and a breeze to read. And why not have a bit of a laugh while we're at it?

If you're up for a good time while you learn a thing or two (well, a lot more), then let's get cracking!

This Book vs the Official Documentation

Some resources just parrot the official documentation. But I don't find these very helpful.

As such, this book differs from the official documentation in a couple of ways:

The tone of writing: this book adopts a non-technical documentation writing style for ease of understanding. Whether you appreciate this or not is left to your taste.
Doesn’t follow the Diataxis framework: the Astro technical documentation is written following the Diataxis framework. The framework suggests structuring content around four distinct types: tutorial, how-to-guide, explanation, and reference.
This book breaks out of this strict structure to emphasise understanding and practical learning. This book is not a reference and doesn’t aim to replace the official Astro references. In the Diataxis lingo, understanding Astro may be defined as a mix of how-to guides and a careful blend of tutorials with elaborate explanations interwoven.
Advanced usage: some advanced Astro uses are tucked away in the official references – without explanations or practical examples. This is perfectly fine for a documentation site. Experienced engineers can spend time digging into these. However, this book bridges the gap.
For example, consider building custom Astro integrations. You will not find a better (practical) resource than this book.
Real-world applications: sometimes, to piece together a puzzle, it’s essential to see it at play in near real-world examples. This book explains important concepts and goes beyond that to put them to practice in comparative real-world examples.
Saves time: This book will save you countless hours tinkering with references and code samples as a by-product of the above distinctions. Yes, you can spend hours digging deep into the docs or Astro source code, but I’ve spent hours (months, actually) doing so! So I can present the learnings without you doing as much of the work. But don’t be fooled – you still have to do the work of reading the book.

Consider reading (or skimming) the official documentation after reading this book or using it as a reference. This book complements the official docs, it does not replace them.

How the Book is Structured

Every chapter in this book is one of the following:

A concept chapter
A project chapter
A project and concept chapter

The mix of these different chapter types will keep you engaged and make your learning effective. Remember, the goal is proper understanding.

Concept chapters

Concept chapters are the foundational chapters for the rest of the book.

In concept chapters, we’ll learn the core concepts of Astro. These chapters will include code examples and throwaway applications. We will build no real-world projects in these chapters.

Project chapters

Showtime! Bring together what we've learned to build a real-world project.

In project chapters, we’ll apply previous concepts we’ve learned towards building a near real-world project.

Concept and project chapters

Bring together the best of the worlds. Build and learn new concepts along the way.

A project and concept chapter focuses on building a real-world application while introducing new concepts.

Chapters Overview

Below’s a summary of the chapters of the book:

Chapter 1: Build your first application with Astro

The book begins hands-on with a project and concept chapter.

In this chapter, we’ll learn the basics of Astro while building a feature-rich personal website.

Chapter 2: Astro components in-depth

This is a concept chapter that goes in-depth into Astro components. We will go beyond the basics and master (arguably) the essential Astro entity.

We will start by exploring an argument to ditch the JavaScript runtime overhead where appropriate. We will then study the behaviour of Astro component markup, styles and scripts, and the powerful template syntax.

Chapter 3: Build your own component island

This project chapter moves away from Astro and considers the component island architecture in isolation.

We will consider an overview of application rendering, comprehend the island architecture from the ground up, and build our own implementation from scratch.

This chapter will solidify your fundamental knowledge of the new web performance-focused architecture pattern.

Chapter 4: The Secret Life of Astro Component Islands

This is a concept chapter where we’ll get hands-on experience working with framework components in Astro. I’ll introduce you to responsible hydration and why it matters.

We will build many throwaway applications to explore how component islands work in Astro and why they are significant.

Chapter 5: Oh My React! (The React Documentation Site Clone)

In this project and concept chapter, we will explore techniques for handling large amounts of content within an Astro application. Additionally, we will examine real-world use cases to provide practical examples.

This chapter will solidify the previous concepts learned and introduce some new ones while we build out a clone of the React documentation site with production best practices.

Chapter 6: Server-side rendering (SSR) in Astro

This concept chapter will explore server-side rendering and the new features unlocked in an Astro server-side rendered application. We will explore dynamic routing, API endpoints, Server streaming, and much more.

Chapter 7: Be Audible! (Full stack Astro Project)

This project chapter will take you beyond static sites into building full stack applications with Astro. In this chapter, I’ll argue that if you can build the app as an MPA and leverage component islands, you can build it with Astro.

Chapter 8: Build your own Astro integrations

This is a project and concept chapter where we’ll answer the question, what happens when you want a feature outside what Astro provides by default?

We will leverage hooks into Astro’s build process to build custom functionalities. These are called Astro integrations.

Chapter 9: Conclusion

Here, we will step back and appreciate how far we’ve come. Then we will reiterate the features that make Astro stand out. Features you’ve already seen in practice!

This is where our journey likely ends, and your journey into the world of Astro begins.

Prerequisites

I tried to make this book “work for everyone”, but that’s incredibly difficult.

So, to make the best out of this book:

You should already know some HTML, CSS and JS: this is not a web development beginner guide.
You should already know the basics of TypeScript: I don’t expect you to be a TypeScript champion, but surface-level understanding will prepare you for all the TypeScript in this book.

I wrote this book specifically for mid, senior, and senior+ engineers, and the book contains chapters of varying technical difficulty. But I’ve done my best to explain these clearly and visually to satisfy different skill levels.

Typographic Conventions

When text is written in a monospaced font, it typically represents code samples. These samples may be self-contained fragments or refer to a specific section of an application's code.

Below’s an example:

---
const { author } = Astro.props;
const book = "Understanding Astro.js";
---

<h1 data-name={book}>A new bookh1>

Sometimes, to show the source of the code, I added a comment to the file path at the top of the code block, as shown below:

{/** 📂 src/pages/index.astro **/}
---
const { author } = Astro.props;
const book = "Understanding Astro.js";
---

<h1 data-name={book}>A new bookh1>

With code fragments referring to changes in a nearby application code, you’ll find an ellipsis to signify no code changes in the previous code, like this:

// ...
A changed book name

The code above suggests the previous code block remains the same, except for the new

with A changed book name.

Finally, the book uses the npm package manager. For example, the code to install a package will be described as shown below:

npm install some-package

You can use the associated commands for other package managers, such as yarn or pnpm.

Phew! That’s enough housekeeping. Now, let’s dive into Astro!

Want to get the eBook?

Download ebook on Github

500+ pages of value
4+ practical project chapters
100+ carefully crafted illustrations and images
Learn techniques to build faster applications
Integrate React, Svelte, Vue, Tailwind and more into an Astro project
Learn to build your own component islands implementation from scratch
Learn to build full stack applications with Astro (without sacrificing performance)
Go beyond the basics and parse Astro code into ASTs and build custom project features

Download the free ebook on GitHub.

Chapter one.

Chapter 1: Build your first Astro Application

"Long is the road to learning by precepts, but short and successful by examples." – Seneca the Younger.

This essay will get started with the basics of Astro by building a practical application: a personal website. To view the complete application, see the GitHub repo.

What you’ll learn

Build a personal website with Astro.
Set up a local development environment for Astro.
Familiarity with Astro components, layouts, and pages.
A working knowledge of styles and scripts in Astro.
Theming Astro sites via CSS variables.
Leveraging markdown pages for ease.
Deployment of a static Astro application.

Project Overview

I remember my first commercial web development project. In retrospect, it was a disaster. One built by a passionate self-taught engineer, but a disaster still.

Let’s make your first Astro project one you’ll remember for good.

Getting started

Astro is a web framework designed for speed. Before we get to the good stuff, let’s ensure we’re both on the same page.

Install Node.js

Firstly, make sure you have Node.js installed.

If you're unsure, run node --version in your terminal. You will get back a Node version if you have Node.js installed.

Get NodeJS version from the CLI.

Don’t have Node installed? Then, visit the official download page and install the necessary package for your operating system. It’s as easy as installing any other computer program. Click, click, click!

The NodeJS download page.

How to set up your code editor

I’ll avoid any heated debate(s) on what code editor you should be writing software with. Quite frankly, it doesn't matter to me.

However, I use Visual Studio Code (VSCode).

You can develop Astro applications with any code editor, but VSCode is also the officially recommended editor for Astro.

If you’re building with VSCode, install the official Astro extension. This helps with syntax and semantic highlighting, diagnostic messages, IntelliSense, and more.

The official Astro VSCode extension.

Let’s now get started setting up our first Astro project. To do this, we must install Astro. The fastest way to do this is to use the Astro automatic CLI.

To start the install wizard, run the following command:

npm create astro@latest

If on pnpm or yarn, the command looks as follows:

# using pnpm
pnpm create astro@latest


# using yarn 
yarn create astro

Starting a new project with the Astro CLI wizard.

This will start the wizard, which will guide us through helpful prompts. It’s important to mention that we can run this from anywhere on our machine and later choose where exactly we want the project created.

When asked, “Where should we create your new project?” go ahead and pass a file path. In my case, this is documents/dev/books/understanding-astro/astro-beginner-project.

Alternatively, we could have run the npm create astro@latest command in our desired directory and just entered a shorter file path, for example, ./astro-beginner-project.

When asked, “How would you like to start your new project?” go ahead and choose “Empty”.

Answering the template CLI prompt.

We want a fresh start to explore Astro from the ground up.

Now, we will be asked whether to install dependencies or not. Select yes and hit enter to continue the installation.

Installing dependencies in the CLI prompt.

Once the dependencies are installed, answer the “Do you plan to write TypeScript?” prompt with a yes and choose the “strictest” option.

We want strong type safety.

Choosing Typescript in the CLI prompt.

Afterwards, answer the “Initialise a new Git repository?” question with whatever works for you. I’ll go with a yes here and hit enter.

Initialising git in the CLI prompt.

And voilà! Believe it or not, our new project is already created and ready to go!

Change into the directory where you set up the project. In my case, this looks like the following:

cd ./documents/dev/books/understanding-astro/astro-beginner-project

And then run the application via the following:

npm run start

This will start the live application on an available local port 🚀

The basic Astro project running on localhost:3000

Project Structure

Open the newly created project in your code editor, and you’ll notice that the create astro CLI wizard has included some files and folders.

Astro has an opinionated folder structure. We can see some of this in our new project. By design, every Astro project will include the following in the root directory:

File / Directory	What?
astro.config.mjs	The Astro configuration file. This is where we provide configuration options for our Astro project.
tsconfig.json	A Typescript configuration file. This specifies the root files and Typescript compiler options.
package.json	A JSON file that holds the project metadata. This is typically found at the root of most Node.js projects.
public/	This directory holds files and assets that will be copied into the Astro build directory untouched, e.g., fonts, images and files such as `robots.txt`
src/	The source code of our project resides here.

Let’s now look at the files in our newly generated project.

`tsconfig.json` file

The content of our tsconfig.json file is the following:

{
  "extends": "astro/tsconfigs/strictest"
}

The extends property points to the base configuration file path to inherit from, that is, inherit the typescript configuration from the file in astro/tsconfigs/strictest.

Using your editor, navigate to the referenced path – for example in vscode by clicking on the link while holding CMD. This will navigate us to node_modules/astro/tsconfigs/strictest.json, where we’ll find a well-annotated file:

{
  ...
  "compilerOptions": {
    // Report errors for fallthrough cases in switch statements
    "noFallthroughCasesInSwitch": true,

    // Force functions designed to override their parent class to be specified as `override`.
    "noImplicitOverride": true,

    // Force functions to specify that they can return `undefined` if a possible code path does not return a value.
    "noImplicitReturns": true,
     ...
  }
}

This is very well annotated, so we won’t spend time on this. But the compilerOptions for TypeScript are set in this file. The point to make here is Astro keeps a list of TypeScript configurations (base, strict and strictest) that our project leverage when we initialise via the CLI wizard.

In this example, we’ll leave the tsconfig.json file as is. TypeScript (and consequently the tsconfig.json file) is optional in Astro projects. But I strongly recommend you leverage TypeScript. We’ll do so all through the book.

`package.json` file

The package.json file is easy to reason about. It holds metadata about our project and includes scripts for managing our Astro project, like npm start, npm run build, and npm preview.

`package-lock.json` file

The package-lock.json file is an autogenerated file that holds information on the dependencies/packages for our project. We won’t be touching this file manually. Instead, it is automatically generated (and updated) by npm.

Note that a project’s lock file may differ depending on the package manager, for example yarn or pnpm.

`astro.config.mjs` file

Most frameworks define a way for us to specify our project-specific configurations. For example, Astro achieves this via the astro.config file.

import { defineConfig } from 'astro/config';

export default defineConfig({});

At the moment, it defines an empty configuration. So we’ll leave it as is. But this is the right place to specify different build and server options, for example.

`src/env.d.ts` file

d.ts files are called type declaration files. Yes, that’s for TypeScript alone, and they exist for one purpose: to describe the shape of some existing module. The information in this file is used for type checking by TypeScript.

///

The content of the file points to astro/client. This is essentially a reference to another declaration file at astro/client.d.ts

`src/pages/index.astro` file

As mentioned earlier, the src folder is where the source code for our project resides. But what’s the pages directory, and why’s there an index.astro file?

First, consider the contents of the index.astro file:

---
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>Astrotitle>
  head>
  <body>
    <h1>Astroh1>
  body>
html>

You’ll notice that it looks remarkably similar to standard HTML, with some exceptions.

Also, notice what’s written within the tag: an

element with the text `Astro`.

If we visit the running application in the browser, we have the

rendered.

The rendered page heading.

Now change the text to read

`Hello world`

and notice how the page is updated in the browser:

The updated page heading.

This leads us nicely to discuss pages in Astro — what I consider the entry point to our application.

Introduction to Astro Pages

Astro leverages a file-based routing system. It achieves this by using the files in the src/pages directory.

For example, the src/pages/index.astro file corresponds to the index page served in the browser.

The project’s index page.

Let’s go ahead and create an src/pages/about.astro page with similar content to index.astro as shown below:

// 📂 src/pages/about.astro
---
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>About ustitle>
  head>
  <body>
    <h1>About ush1>
  body>
html>

Copy and paste the exact content of index.astro in about.astro.
Change the
to have the text About us.

Now, if we navigate to /about in the browser, we should have the new page rendered.

The “About us” page.

What makes a valid Astro page?

We’ve defined Astro pages as files in the src/pages/directory. Unfortunately, this is only partly correct.

For example, if we duplicate the favicon.svg file in public/favicon.svg into the pages directory, does this represent a favicon page?

Duplicating the favicon in the pages directory.

Even though index.astro and about.astro correspond to our website’s index and about pages, /favicon will return a 404: Not found error.

The /favicon route.

This is because only specific files make a valid astro page. For example, if we consider the index and about files in the pages directory, you perhaps notice something: they both have the .astro file ending!

In layperson’s terms, these are Astro files, but a more technical terminology for these is Astro components.

So, quick quiz: what is an Astro component?

That’s easy—a file with the .astro ending.

10 points to you! Well done.

Anatomy of an Astro component

We’ve established that index.astro and about.astro represent Astro components and are valid Astro pages.

Now, let’s dig into the content of these files.

Consider the contents of the index.astro page:

// 📂 src/pages/index.astro
---
---

<html lang="en">
  

html>

Notice the distinction between the two parts of this file’s content.

The section at the bottom contains the page’s markup:

// 📂 src/pages/index.astro
// ... 
"en">

This part is called the component template section.

While the top section contains a rather strange divider-looking syntax:

---
---

This part is called the component script section, and the --- is called a fence.

Together, these make up an Astro component.

Let’s take the component script section for a spin.

The section’s name hints at what this section of the component does. Within the component script code fence, we may declare variables, import packages and fully take advantage of JavaScript or TypeScript.

Oh yes, TypeScript!

Let’s start by creating a variable to hold our user’s profile picture, as shown below:

// 📂 src/pages/index.astro
---
const profilePicture = "https://i.imgur.com/JPGFE75.jpg";
---

We may then take advantage of the component template section to reference this image as shown below:

// 📂 src/pages/index.astro
---
const profilePicture = "https://i.imgur.com/JPGFE75.jpg";
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>Astrotitle>
  head>
  <body>
    
    <img
      src={profilePicture}
      alt="Frau Katerina's headshot."
      width="100px"
      height="100px"
    />
  body>
html>

Note that the profilePicture variable is referenced using curly braces { }. This is how to reference variables from the component script in the component markup.

Now we should have the image rendered on the home page:

Rendering the user profile photo.

It’s not much, but it’s honest work, eh?

Let’s go ahead and flesh out the page to have the user’s profile markup:

// 📂 src/pages/index.astro
// ...
  
    
    <div>
      <img
        src={profilePicture}
        alt="Frau Katerina's headshot."
        width="100px"
        height="100px"
      />
      <div>
        <h1>Frau Katerinah1>
        <h2>VP of Engineering at Goooogleh2>
        <p>
          Helping developers be excellent and succeed at building scalable
          products
        p>
      div>
    div>
  
// ...

As you might have noticed, we’re writing HTML looking syntax in the component markup section!

Now we should have the user photo and their bio rendered in the browser as follows:

The user profile photo and bio.

Component Styles

Styling in Astro is relatively easy to reason about. Add a

The user details should now be styled as expected.

Applying styles to the index.astro page component.

If we inspect the eventual styles applied to our UI elements via the browser developer tools, we’ll notice that the style selectors look different.

For example, to style the user name, we’ve written the following CSS:

.profile__details > h1 {
  margin-top: 0;
}

However, what’s applied in the browser looks something like this:

.profile__details:where(.astro-J7PV25F6) > h1:where(.astro-J7PV25F6) {
  margin-top: 0;
}

Why is this?

The actual style declarations for the h1 element remain unchanged. The only difference here is the selector.

The h1 element now has auto-generated class names, and the selector is now scoped via the :where CSS selector.

This is done internally by Astro. This makes sure the styles we write don’t leak beyond our component. For example, if we styled every h1 in our component as follows:

h1 {
  color: red
}

The eventual style applied in the browser will be similar to the following:

h1:where(.astro-some-unique-id) {
  color: red
}

This will ensure all other h1 in our project remains the same, and this style only applies to our specific component h1.

Page Layouts

Look at the pages of our completed application. You may notice that they all have identical forms.

A breakdown of the application page structure.

There’s a navigation bar, a footer, and some container that holds the page’s main content.

Should we repeat these similar UI structures across all pages?

Most people will answer “No”. So, is there a way to share reusable UI structures across pages?

Yes, yes, yes! This is where layouts come in.

Layouts are Astro components with a twist. They are used to provide reusable UI structures across pages, for example navigation bars and footers.

Conventionally, layouts are placed in the src/layouts directory. This is not compulsory but is a widespread pattern.

Let’s go ahead and create our first layout in src/layouts/Main. We’ll do this by moving away all the reusable UI structures currently in index.astro as follows:

// 📂 src/layouts/Main.astro
---
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    {/* Add a new meta description tag */}
    <meta name="description" content="Frau Katarina's website" />
    {/* Title is hardcoded as Astro, for now. */}
    <title>Astrotitle>
  head>
  <body>
    <main>
      {/* We want the content of each page to go here */}
    main>
  body>
html>

We’ve moved the , and elements to the Main.astro layout.
We’ve also introduced a new tag for SEO.
We’ve equally introduced a
element where we want the rest of our page to go in.
Note that the file name of the layout is capitalised, that is Main.astro, not main.astro.

On the one hand, layouts are unique because they mostly do one thing: provide reusable structures. But, on the other hand, they aren’t unique. They are like other Astro components and can do everything a component can.

How to Render Components and Slots

Rendering an Astro component is similar to how you’d attempt to render an HTML element. For example, we’d render a div by writing the following:


 render something within the div

The same goes for Astro components.

To render the Main.astro component, we’d do something similar:


  render something within the Main component

Let’s put this into practice. We may now use the Main layout in the index.astro page. To do this, we will do the following:

Import the Main layout from "../layouts/Main.astro"
Substitute the , and elements for the
layout in index.astro.

---
import Main from "../layouts/Main.astro";

const profilePicture = "https://i.imgur.com/JPGFE75.jpg";
---

<Main>
  <div class="profile">
    <img
      src={profilePicture}
      class="profile__picture"
      alt="Frau Katerina's headshot."
      width="100px"
      height="100px"
    />
    <div class="profile__details">
      <h1>Frau Katerinah1>
      <h2>VP of Engineering at Goooogleh2>
      <p>
        Helping developers be excellent and succeed at building scalable
        products
      p>
    div>
  div>
Main>

If we checked our app, we’d have a blank index page.

Blank application page.

Why’s that?

Unlike HTML elements, the child elements in the

tag aren’t automatically rendered.

{/** Child div will not be automatically rendered */}

  <div>Hello from childdiv>
<Main>

The

layout component is rendered, and nothing else. The child components aren’t. Hence, the empty page.

To render the child elements of an Astro component, we must specify where to render these using a element.

Injecting child elements into a slot.

Let’s add a within Main.astro :

//...
  
    <main>
      {/* We want the content of each page to go here */}
       <slot /> 
    main>

Page refactored to use a reusable layout component.

We should now have our page rendered with the reusable layout in place.

Capitalising Component Names

We’ve capitalised the file name of the Main.astro layout component, but is this important?

Theoretically, the answer to that is no.

We could create a file with a lower cased name, for example mainLayout.astro and import the component as follows:

import Main from "../layouts/mainLayout.astro";

This is perfectly correct.

But where we encounter issues is if we name the imported component with a lowercase:

// main NOT Main
import main from "../layouts/mainLayout.astro";

In this case, we’ll encounter issues when we attempt to render the component, as the name collides with the standard HTML main element.

For this reason, it’s common practice to capitalise both component file names and the imported variable name.

The Global Style Directive

The Main layout is in place but doesn’t add much to our page. Let’s start by adding some styles for the headers and also centre the page’s content:


<style>
  h1 {
    font-size: 3rem;
    line-height: 1;
  }

  h1 + h2 {
    font-size: 1.1rem;
    margin-top: -1.4rem;
    opacity: 0.9;
    font-weight: 400;
  }

  main {
    max-width: 40rem;
    margin: auto;
  }
style>

With this, we’ll have the main element centred, but the headers, h1 and h2 remain unstyled.

A comparison of the changes before and after the layout component style.

This is because styles applied via the

Now, we should have a decent-looking theme toggler.

A styled theme toggle button.

The `:global()` Selector

Let’s take a moment to consider the strategy we’ll use for toggling the theme.

We’ll toggle a CSS class on the root element whenever a user clicks the toggle.

Adding a new “dark” class on toggle.

For example, if the user was viewing the site in light mode and clicked to toggle, we’ll add a .dark class to the root element and, based on that, apply dark-themed styles.

If the user is in dark mode, clicking the toggle will remove the .dark class. We’ll refer to this as a class strategy for toggling dark mode.

Based on this strategy, we must update our local ThemeToggler style to display the relevant icon depending on the global .dark class.

To do this, we will leverage the :global selector.

Here’s how we’d achieve this:


<style>
 /**...**/

 /** If a parent element has a .dark class, target the .sun icon and make the path black (shows the icon) */
 :global(.dark) .sun {
   fill: black;
 }

 /** If a parent element has a .dark class, target the .moon icon and make the path transparent (hides the icon) */
 :global(.dark) .moon {
   fill: transparent;
 }
style>

To see this at work, inspect the page via the developer tools, and add a dark class to the root element. The toggle icon will be appropriately changed.

Inspecting icon change with a root dark class.

In practice, limit :global only to appropriate use cases, because mixing global and locally scoped component styles will become challenging to debug. But this is permissible, given our use case.

Event Handling

We’ve handled the styles for our toggle, assuming a .dark root class. Now, let’s go ahead and handle the toggle click event with a

In the real world, we quickly realise that the defaults don’t always satisfy every project requirement.

For example, consider the un-styled flash of incorrect theme when we refresh our home page. For a user who chose the dark theme previously, refreshing the page shows light-themed rendered content before changing to dark after the script is parsed.

Transitioning light themed content viewed on Regular 3G throttling.

This occurs because we restore the user-chosen theme only after the page’s HTML has been parsed, that is the default behaviour of processed Astro scripts.

To prevent this, we will use the is:inline directive, which will make the script blocking, that is, it'll be executed immediately and stops parsing until completed.

Since scripts with the is:inline attribute aren’t processed, they’ll be added multiple times if used in reusable components that appear more than once on the page.

So, let’s go ahead and move the theme restoration code bit into Main.astro — because the Main layout is only included once per page.

We’ll also make sure to add this within the of the layout, as shown below:


<head> 
       
    
    <script is:inline>
      const DARK_THEME_CLASS = "dark";
      const COLOUR_MODE = "COLOUR_MODE";
      const LIGHT_THEME = "LIGHT";
      const DARK_THEME = "DARK";
      const rootEl = document.documentElement;
      const getInitialColourMode = () => {
        /** ... */
      }
      const initialColourMode = getInitialColourMode();
      // 👀 remove string type on mode 
      const setInitialColourMode = (mode) => {
         /** ... */
      };
      /** Set the initial colour mode as soon as the script is executed */
      setInitialColourMode(initialColourMode);
    script>
  head>

We’re explicitly adding this to the because Astro will not process the is:inline script. As such, it won’t be moved to the head by Astro.

Be careful with is:inline as it removes the default non-blocking nature of scripts. But it’s ideal for this use case.

Open your developer tools and throttle the network. Then go ahead and refresh after toggling dark mode. We should have eradicated the flash of incorrect theme:

Throttling the network via the chrome developer tools.

Global Selectors in Scripts

Understanding how Astro processes the

Inspect the elements via the developer tools. You’ll notice that the

To enjoy the benefits of partial hydration, developers will add mini-island.js to their page with the promise of having a small JS footprint — a small price to pay to get partially hydrated islands of interactivity.

API design

Our first objective is to make sure our solution is framework agnostic. An excellent native solution for framework-agnostic implementations is web components.

By definition, web components are a suite of technologies that allows us to create reusable custom elements.

If you’re new to web components, instead of rendering a standard HTML element, for example a div, we will create our custom HTML element, mini-island.

mini-island.js will expose a custom element with the following basic usage:


 This is an island

Within , a developer will be able to leverage an island of interactivity on an otherwise static page.

We will support three different attributes to handle partial and lazy hydration: client:idle, client:visible and client:media={QUERY}.

Here’s an example of how they’d be used on :

 
<mini-island client:visible /> 
<mini-island client:media="(max-width: 400px)" />

These attributes will affect how the island is hydrated.

client:idle: load and hydrate JavaScript when the whole page is loaded and the browser is idle.
client:visible: we will load and hydrate the island JavaScript once the island is visible, for example, when it's entered the user’s viewport.
client:media: we will load and hydrate the island once the query is satisfied, for example client:media="(max-width: 400px)".

There’s one final piece to our API design. How will developers define the scripts or markup to be hydrated?

We will use the

User Interface - freeCodeCamp.org

How to Build Responsive UIs in Flutter

Table of Contents

Prerequisites

Understanding Responsive vs Adaptive Design

Core Flutter Layout Widgets for Responsive UI

Container/SizedBox

Overly Fixed Sizing (Not Responsive)

Responsive / Flexible Sizing

SizedBox for Spacing or Constraints

Row, Column

Expanded and Flexible

LayoutBuilder

FractionallySizedBox and AspectRatio

MediaQuery and Screen Information

Using MediaQuery

Example: Responsive Typography

Breakpoints, Orientation and Large-Screen Adaptation

Orientation

Breakpoints and Adaptive Layouts

Large Screens and Safe Use of Space

Responsive Typography, Images and Assets

Typography

Images and BoxFit

Asset Density and Pixel Ratio

Flexible Layouts: Expanded, Flexible, FractionallySizedBox

Expanded and Flexible

FractionallySizedBox

AspectRatio

Advanced Tools and Packages

flutter_screenutil

responsive_builder

Others

Handling Safe Areas, Notches and Insets

Adaptive UI for Tablets/Desktop and Multi-Window

Best Practices and Performance Considerations

Testing and Debugging Responsive Layouts

Building Reusable Responsive Widgets/Custom Widgets

Example: ResponsiveText Widget

Example: BreakpointAwareLayout Widget

Example of A Complete Sample Responsive Screen

Project Setup and Imports

App Entry Point: The MyApp Class

The Responsive Home Screen (MyHomePage)

Building the Core Content

Full Walkthrough: Code Explained in Depth

Imports and App Entry Point

Explanation:

App Root: The MyApp Widget

Explanation:

The Home Screen Layout MyHomePage

The Scaffold and AppBar

Explanation:

SafeArea + LayoutBuilder

Explanation:

Handling Large and Small Screens

Explanation:

Building the Core Content

Explanation:

Why This Works

Key Takeaways

Conclusion

References

How to Create Tables Using the React-Data-Table-Component Library in React & TypeScript

What will we build

1. Create a React and TypeScript Project

2. Remove the Default Code Set by React

3. Install the Libraries We'll Need

4. Import Bootstrap in the App Component

5. Create a Table Component

6. Import the react-data-table-component Library to Start Using it

7. Create the Table in the Table Component

8. Add Pagination and Sorting, and Make Each Row Selectable

Pagination and selectableRows

Sorting

9. Add Searching and Filtering

10. View the Table

How to Use Shadcn with Next.js 14

Table of Contents

What is Shadcn?

App Entry Point: The `MyApp` Class

The Responsive Home Screen (`MyHomePage`)

App Root: The `MyApp` Widget

The Home Screen Layout `MyHomePage`

Pagination and `selectableRows`

`tsconfig.json` file

`package.json` file