DEV Community: Prince Tomar

How Flutter Builds and Updates Your UI (Explained Simply)

Prince Tomar — Mon, 18 Aug 2025 01:34:16 +0000

How Flutter Builds and Updates Your UI (Explained Simply)

If you’ve used Flutter for a while, you know how fun it is to compose widgets and get instant results on screen. But behind that smooth developer experience, Flutter’s engine is doing a ton of work every frame to keep things responsive and fast.

This post is a walkthrough of what really happens when you write something as simple as:

Scaffold(
  appBar: AppBar(title: Text('Hello Flutter')),
  body: Center(
    child: Text('Welcome!'),
  ),
);

We’ll unpack how Flutter turns that into pixels, how it decides what needs to rebuild, and how you can use this knowledge to debug or optimize your apps.

Whether you’re just starting out or have a decade of experience in UI frameworks, this will give you a clear mental model of Flutter’s rendering pipeline.

The Three Phases: Build, Layout, Paint

Every frame Flutter draws goes through three broad phases. Think of it as:

Build → What widgets exist?
Layout → How big are they and where do they go?
Paint → What do they look like?

Let’s break these down with examples.

1. The Build Phase: Creating Widgets and Elements

Whenever Flutter needs to update the UI (like after setState), it triggers a build.

Here’s what happens:

Widgets are immutable configurations (like Text('Hello')).
Flutter creates or reuses Elements, which are the living nodes in the widget tree.
Each Element points to a RenderObject (the actual layout + paint engine).

A simple setState in a StatefulWidget rebuilds the subtree. Flutter compares old and new widgets:

If the type is the same → it reuses the element and render object.
If the type changes → it replaces them.

This is why using const widgets helps. For example:

// Bad: rebuilds a new Text widget each time
Text('Static label')

// Good: Flutter can reuse the same instance
const Text('Static label')

2. The Layout Phase: Measuring and Positioning

Once the widget tree is settled, layout begins. Flutter walks the tree twice:

Down the tree: parents send constraints to children (e.g. “you can be up to 300px wide”).
Up the tree: children report their chosen size back.

Example:

Row(
  children: [
    Expanded(child: Text('A')),
    Expanded(child: Text('B')),
  ],
);

Here, each Expanded tells its child: “take half the width”. The Text widgets measure themselves, report back, and the Row lays them side by side.

3. The Paint Phase: Drawing Pixels

After layout, each render object gets a canvas to paint on. This includes:

Backgrounds
Text
Images
Decorations

Painting flows top-down. Parent first, then children.

For example:

Container(
  color: Colors.blue,
  child: Text('Hello', style: TextStyle(color: Colors.white)),
);

The Container paints its blue background.
The Text paints “Hello” on top.

How Flutter Updates Efficiently

Flutter doesn’t rebuild everything every frame. It’s smarter than that.

Widget diffing: If only properties change, the element + render object stay alive.
Layout skip: If the size doesn’t change, layout can be skipped.
Repaint boundaries: Flutter can repaint only parts of the screen (like list items) instead of everything.

Example:

RepaintBoundary(
  child: Image.network(url),
);

If something outside changes, the image won’t repaint unnecessarily.

Debugging with This Mental Model

When you hit layout or performance issues, knowing this pipeline helps.

Yellow/black overflow stripes → a child render object asked for more space than constraints allowed.
Widgets disappearing → the child reported size = zero or was positioned outside.
Jank while scrolling → too many objects are rebuilding or repainting.

Tools to help:

debugPaintSizeEnabled = true → shows layout bounds.
debugDumpRenderTree() → prints the render tree.
Flutter DevTools → inspect widget/repaint boundaries.

Example: Why `ListView.builder` is Faster than `ListView(children: [])`

ListView(children: []) builds all widgets at once. That means layout + paint for every child, even offscreen.

ListView.builder only builds what’s visible, thanks to slivers and lazy rendering. That’s why your 10,000-row list scrolls smoothly.

When to Go Deeper (Custom Layouts and Painting)

Most of the time, you don’t need to mess with render objects directly. But sometimes you might:

Want a custom layout (like a staggered grid).
Want custom drawing beyond what CustomPainter can do.
Need to optimize for a high-performance visualization.

Flutter gives you tools like CustomMultiChildLayout and RenderBox if you really need them.

Takeaway

Here’s the thing: you don’t need to be a rendering engine expert to build Flutter apps. But having a mental model of how widgets → elements → render objects → pixels helps you:

Debug weird layout issues.
Write more efficient code.
Appreciate what Flutter is doing for you every frame.

The next time you hit hot reload, remember — it’s not magic. It’s a careful dance of build, layout, and paint happening in under 16ms.

What’s Next?

Try debugPaintSizeEnabled in your app to see the layout boxes.
Compare ListView(children: []) vs ListView.builder.
Read Flutter’s Rendering docs for the deep dive.

And if you’ve built custom layouts or debugged tricky rendering issues, share your tips in the comments — other devs will thank you.

Building Face Detection and Emotion Recognition in Flutter Using Google ML Kit

Prince Tomar — Tue, 15 Jul 2025 06:28:24 +0000

Face detection used to sound futuristic. Now it's just part of how tech sees and responds to people. Whether it’s unlocking your phone, putting cat ears on your selfie, or tracking how users feel about a product — facial analysis is everywhere.

Let’s walk through how to build this in Flutter using Google’s ML Kit. We'll detect faces in a live camera feed, grab facial landmarks, and even infer simple emotions like happy, sleepy, or neutral.

Whether you’re just starting with Flutter or already shipping apps, this is worth adding to your toolkit.

Why Even Care About Face Detection?

It’s not just about knowing there’s a face. You can:

Track multiple faces in real time
Get details like smile intensity, eye openness, head rotation
Build smarter features: filters, auto-focus, or even mood-based UI
Add a touch of fun or utility — or both

🔧 Setup: What You’ll Need

Step 1: Add Dependencies

In pubspec.yaml, toss in:

dependencies:
  google_mlkit_face_detection: ^0.10.0
  camera: ^0.10.5
  permission_handler: ^11.0.0

Run:

flutter pub get

Step 2: Android & iOS Permissions

Android

Set minSdkVersion to 21 in android/app/build.gradle
Add this to AndroidManifest.xml:

<uses-permission android:name="android.permission.CAMERA" />

iOS

Open Info.plist and add:

<key>NSCameraUsageDescription</key>
<string>This app uses the camera for face detection.</string>

📸 Open the Camera Feed

Let’s stream live images from the camera:

final controller = CameraController(camera, ResolutionPreset.medium);
await controller.initialize();
await controller.startImageStream(onImageAvailable);

Your onImageAvailable function will handle incoming frames for face detection.

🧠 Face Detection in Action

Set up the face detector like this:

final options = FaceDetectorOptions(
  enableContours: true,
  enableClassification: true, // for smile & eye open detection
  performanceMode: FaceDetectorMode.fast,
);

final faceDetector = FaceDetector(options: options);

Process incoming images from the stream:

Future<void> onImageAvailable(CameraImage image) async {
  final inputImage = getInputImageFromCameraImage(image);
  final faces = await faceDetector.processImage(inputImage);

  for (Face face in faces) {
    final smile = face.smilingProbability;
    final leftEye = face.leftEyeOpenProbability;
    print('Smile: $smile | Left Eye Open: $leftEye');
  }
}

These probabilities (from 0.0 to 1.0) give you real-time signals to work with.

😄 Emotion Detection (Basic)

ML Kit doesn’t return labels like "happy" or "sad", but we can infer:

String analyzeEmotion(Face face) {
  final smile = face.smilingProbability ?? 0;
  final eye = face.leftEyeOpenProbability ?? 0;

  if (smile > 0.8) return "Happy";
  if (eye < 0.3) return "Sleepy";
  return "Neutral";
}

You can tweak thresholds and combine features depending on your use case.

Want deeper emotion classification? You’ll need a custom model via TensorFlow Lite. But that’s a different beast — and worth its own article.

⚡ Where You Can Use This

Real-time selfie filters (like Snap lenses, but yours)
Smile-to-unlock actions
Mood-based UI tweaks or chatbot reactions
Attendance systems that detect faces, not just IDs
Face-aware focus tracking in camera apps

🔐 Privacy Matters

Even though ML Kit processes everything on-device, be upfront:

Ask for camera permissions clearly
Don’t store facial data unless absolutely necessary
Mention any facial analysis in your privacy policy

People care about how they’re being watched. Respect that.

🧪 Test Smart

Face detection is tricky to test on emulators. Use a real device, preferably with decent lighting. Try different angles, faces, and distances.

If you’re using live camera feed, latency and device performance will also affect results — especially if you’re tracking multiple faces.

🚀 Want to Go Beyond?

If you’re feeling ambitious:

Build filters using facial contours
Animate avatars using facial landmarks
Combine with voice recognition for AI assistants
Integrate TensorFlow Lite models for emotion labels like “angry”, “excited”, etc.

The face is just the start. Combine it with other signals and your app starts to feel… aware.

✅ Wrap-Up

Face detection in Flutter is no longer a hacky side project — it’s production-ready, thanks to Google ML Kit.

You can build apps that see, analyze, and respond — in real time, offline, and without sending anything to the cloud.

Give it a shot. Add some eyes to your app.

If this helped, consider clapping, sharing, or reaching out if you build something cool with it. I'm always up for seeing how people push Flutter and ML in the real world.

Remix

Prince Tomar — Sun, 04 May 2025 18:36:48 +0000

Stop Letting One Bug Break Everything: Master Component Error Boundaries in Remix JS (Beginner to Pro Guide)

Prince Tomar ・ May 4

Stop Letting One Bug Break Everything: Master Component Error Boundaries in Remix JS (Beginner to Pro Guide)

Prince Tomar — Sun, 04 May 2025 18:35:10 +0000

How to Implement Component Error Boundaries in Remix JS: A Beginner to Advanced Guide

When building modern web applications with Remix, one of the biggest challenges developers face is gracefully handling errors without compromising the entire user experience. Imagine your dashboard is working fine—except one widget fails and suddenly your entire page goes blank.

This guide will walk you through implementing component-level error boundaries in Remix using a practical and open-source approach. No packages to install—we’ll reference the actual GitHub repo and dive into real-world usage with step-by-step guidance.

🔍 What is an Error Boundary?

In React, an error boundary is a component that catches JavaScript errors in its child component tree and displays a fallback UI instead of crashing the whole app. Remix comes with route-level error boundaries by default—but sometimes, that’s too much power in the wrong hands.

🤕 Why Global Error Boundaries Can Hurt UX

Remix uses route-specific <ErrorBoundary> elements, which work well for full-page errors. However, if a tiny widget like a comments section crashes, Remix replaces the entire route with a fallback.

This is frustrating for users. Why should the whole page disappear because of one bad API call?

🛠️ Component-Level Error Boundaries to the Rescue

That’s where the remix-comonent-error-boundary repo steps in. It allows isolated, localized error handling inside your components. The goal is simple: if one part of your UI breaks, everything else should keep working.

👉 Check out the full repo here:
🔗 https://github.com/princetomar27/remix-comonent-error-boundary

🚀 Setting Up the Project

No NPM install needed—this is a DIY solution built inside a Remix app. Clone the GitHub repo:

git clone https://github.com/princetomar27/remix-comonent-error-boundary.git
cd remix-comonent-error-boundary
npm install
npm run dev

You’ll find a working demo where various components are wrapped with custom error boundaries.

🧱 Introducing `<ComponentErrorBoundary>`

The core idea is to create a reusable wrapper component that catches errors inside its children and renders a fallback UI.

Example Usage

<ComponentErrorBoundary>
  <Comments items={items} />
</ComponentErrorBoundary>

If <Comments> throws an error, only that part fails—not your whole page.

🎨 Custom Fallback UI

Want to personalize the error message? Pass a fallbackRender prop:

<ComponentErrorBoundary
  fallbackRender={({ error }) => (
    <p style={{ color: 'red' }}>💥 Error: {error.message}</p>
  )}
>
  <Comments items={items} />
</ComponentErrorBoundary>

You can also style it, add a retry button, or log it to Sentry.

🧪 Example: Breaking the Comments Component

In the demo, there's a Comments component that simulates an error. When wrapped in a ComponentErrorBoundary, only that section of the page shows an error. Everything else works fine.

This is especially powerful in scenarios like:

Blog comments
Embedded third-party widgets
Analytics charts
File uploaders

🔁 Replacing `useFetcher` with `useComponentFetcher`

Why?

Remix's useFetcher throws caught errors up to the route boundary. That defeats the purpose of using component boundaries.

Solution

Use a custom useComponentFetcher hook that wraps useFetcher and catches errors locally.

const fetcher = useComponentFetcher<typeof loader>();

Use it exactly like useFetcher, but with error boundaries in mind.

⚙️ How `useComponentFetcher` Works

Here's an example in the Comments component:

export function Comments({ items }: { items?: number[] }) {
  const fetcher = useComponentFetcher<typeof loader>();
  items = fetcher.data?.items ?? items ?? [];

  return (
    <ul>
      {items.map((id) => (
        <li key={id}>Comment #{id}</li>
      ))}
    </ul>
  );
}

If something goes wrong in the fetcher, the component boundary catches it instead of blowing up the page.

🔄 Updating Loaders and Actions

Avoid throwing errors. Instead, use a utility function like error() that returns a standard shape:

export async function loader() {
  try {
    const data = await fetchSomething();
    return json(data);
  } catch (err) {
    return error(err);
  }
}

This prevents Remix from escalating the error to a full-route boundary.

✅ Benefits Recap

🎯 Targeted error handling
🚀 Better performance for dashboards and widgets
🤝 Plays well with nested UIs
🧠 Easier debugging
🌐 Supports server/client harmony

🔍 Best Practices

Group related components under one error boundary
Use fallbackRender to create rich, user-friendly messages
Hook up logging with tools like Sentry or LogRocket
Avoid overusing boundaries—balance flexibility with performance

⚠️ Common Pitfalls to Avoid

Don’t throw from loaders/actions unless you want a full-page crash
Avoid nesting too many boundaries—it complicates tracing
Fallback UIs should be minimal and fast

🌎 Real-World Scenarios

Component error boundaries shine in:

Admin dashboards with multiple independent panels
Activity feeds where one slow API shouldn't block the UI
Product detail pages where reviews or suggestions might fail

🧾 Conclusion

Component-level error boundaries in Remix offer a robust, elegant solution to a long-standing problem. With the approach shown in the remix-comonent-error-boundary GitHub repo, you can isolate issues, avoid page crashes, and provide a better user experience—all without installing a package.

💡 Tip: Start with just one component. Gradually adopt boundaries in high-risk areas.

❓ FAQs

1. What happens if I don’t use useComponentFetcher?
Errors will bypass your component boundary and go straight to the route-level error fallback.

2. Can I wrap any component in ComponentErrorBoundary?
Yes—as long as it’s a React component.

3. How do I log errors from the boundary?
Use fallbackRender to trigger logging to Sentry or another service.

4. Is there a performance hit?
Negligible. Component boundaries are lightweight and React-optimized.

5. Can I combine global and component-level error boundaries?
Absolutely. Use global for critical failures, component for localized ones.

Role-Based Route Permissions in Remix / React Router v7

Prince Tomar — Sat, 05 Apr 2025 20:36:24 +0000

🎯 Implementing role-based access control (RBAC) in single-page applications can be challenging. This guide demonstrates how to build a comprehensive role-based navigation system in Remix that:

Loads permissions configuration once at startup
Enforces permissions on both client and server
Tracks and validates navigation transitions
Provides a clean API for your components

We'll start with the basics and progressively advance to a complete solution.

Project Setup

Begin by creating a Remix project. We'll build an e-commerce application with the following user roles:

CUSTOMER
SUPPORT_AGENT
STORE_MANAGER
SYSTEM_ADMIN

Each role will have access to different areas of the application.

Step 1: Define Routes and Permissions

Start by defining your routes and permissions in a JSON configuration file:

// app/config/routePermissions.json
{
  "publicRoutes": ["LOGIN", "REGISTER", "ACCESS_DENIED"],
  "routeConfig": {
    "SYSTEM_ADMIN": ["DASHBOARD", "USER_MANAGEMENT", "PRODUCT_MANAGEMENT", "STORE_SETTINGS", "ORDERS", "REPORTS", "ACCOUNT", "LOGOUT"],
    "STORE_MANAGER": ["DASHBOARD", "PRODUCT_MANAGEMENT", "STORE_SETTINGS", "ORDERS", "REPORTS", "ACCOUNT", "LOGOUT"],
    "SUPPORT_AGENT": ["DASHBOARD", "CUSTOMER_SUPPORT", "ORDERS", "ACCOUNT", "LOGOUT"],
    "CUSTOMER": ["DASHBOARD", "ORDERS", "WISHLIST", "ACCOUNT", "LOGOUT"]
  },
  "routeTransitions": {
    "DASHBOARD": ["LOGIN", "USER_MANAGEMENT", "PRODUCT_MANAGEMENT", "STORE_SETTINGS", "CUSTOMER_SUPPORT", "ORDERS", "WISHLIST", "REPORTS", "ACCOUNT", "ACCESS_DENIED", "*"],
    "USER_MANAGEMENT": ["DASHBOARD"],
    "PRODUCT_MANAGEMENT": ["DASHBOARD", "STORE_SETTINGS"],
    "STORE_SETTINGS": ["DASHBOARD", "PRODUCT_MANAGEMENT"],
    "CUSTOMER_SUPPORT": ["DASHBOARD", "ORDERS"],
    "ORDERS": ["DASHBOARD", "CUSTOMER_SUPPORT"],
    "WISHLIST": ["DASHBOARD", "ORDERS"],
    "REPORTS": ["DASHBOARD", "ORDERS", "PRODUCT_MANAGEMENT"],
    "ACCOUNT": ["DASHBOARD"],
    "LOGIN": ["DASHBOARD", "REGISTER"],
    "REGISTER": ["LOGIN"],
    "ACCESS_DENIED": ["*"],
    "*": ["DASHBOARD"]
  }
}

This configuration defines:

publicRoutes: Routes that don't require authentication
routeConfig: Routes accessible by each role
routeTransitions: Valid navigation paths between routes

Step 2: Create Route Utilities

Next, define route utilities to be used throughout the application:

// app/utils/routeUtils.ts
export enum UserRoleEnum {
  SYSTEM_ADMIN = 'SYSTEM_ADMIN',
  STORE_MANAGER = 'STORE_MANAGER',
  SUPPORT_AGENT = 'SUPPORT_AGENT',
  CUSTOMER = 'CUSTOMER',
}

export interface RouteInfo {
  key: string;
  path: string;
  name: string;
}

export const AppRoutes = {
  LOGIN: { key: 'LOGIN', path: '/login', name: 'Login' },
  REGISTER: { key: 'REGISTER', path: '/register', name: 'Register' },
  ACCESS_DENIED: { key: 'ACCESS_DENIED', path: '/access-denied', name: 'Access Denied' },
  DASHBOARD: { key: 'DASHBOARD', path: '/dashboard', name: 'Dashboard' },
  USER_MANAGEMENT: { key: 'USER_MANAGEMENT', path: '/users', name: 'User Management' },
  PRODUCT_MANAGEMENT: { key: 'PRODUCT_MANAGEMENT', path: '/products', name: 'Product Management' },
  STORE_SETTINGS: { key: 'STORE_SETTINGS', path: '/settings', name: 'Store Settings' },
  CUSTOMER_SUPPORT: { key: 'CUSTOMER_SUPPORT', path: '/support', name: 'Customer Support' },
  ORDERS: { key: 'ORDERS', path: '/orders', name: 'Orders' },
  WISHLIST: { key: 'WISHLIST', path: '/wishlist', name: 'Wishlist' },
  REPORTS: { key: 'REPORTS', path: '/reports', name: 'Reports' },
  ACCOUNT: { key: 'ACCOUNT', path: '/account', name: 'Account' },
  LOGOUT: { key: 'LOGOUT', path: '/logout', name: 'Logout' },
} as const;

export type AppRouteKeys = keyof typeof AppRoutes;

export const getRoutePath = (route: AppRouteKeys): string => AppRoutes[route].path;
export const getRouteName = (route: AppRouteKeys): string => AppRoutes[route].name;
export const getRouteFromPath = (path: string): AppRouteKeys | undefined => {
  const entry = Object.entries(AppRoutes).find(([_, info]) => info.path === path);
  return entry ? (entry[0] as AppRouteKeys) : undefined;
};

export type RouteInfoType = (typeof AppRoutes)[AppRouteKeys];

export function normalizeUserRole(role: string | undefined): UserRoleEnum | undefined {
  if (!role) return undefined;
  return UserRoleEnum[role as keyof typeof UserRoleEnum];
}

Step 3: Create a Navigation Store

Use Zustand for navigation state management:

// app/stores/navigationStore.ts
import { create } from 'zustand';
import { AppRouteKeys } from '~/utils/routeUtils';

interface NavigationState {
  currentRoute: AppRouteKeys | null;
  previousRoute: AppRouteKeys | null;
  setRoute: (route: AppRouteKeys) => void;
}

// Define state updater type
type SetState = (fn: (state: NavigationState) => Partial<NavigationState>) => void;

export const useNavigationStore = create<NavigationState>((set: SetState) => ({
  currentRoute: null,
  previousRoute: null,
  setRoute: (route: AppRouteKeys) =>
    set((state: NavigationState) => ({
      previousRoute: state.currentRoute,
      currentRoute: route,
    })),
}));

Thanks for pointing that out! Here's the complete dev.to-style article including Step 6 and Step 7, maintaining every single word from your original content:

🎯 Role-Based Route Permissions in Remix: Step-by-Step Guide

✅ Step 4: Create the Route Configuration Service

This is where the magic happens. We'll create a singleton service that loads the route permissions once at startup:

// app/config/routeConfigLoader.server.ts
import { UserRoleEnum, AppRouteKeys, AppRoutes } from '~/utils/routeUtils';
import * as routePermissions from './routePermissions.json';

// Wildcard constant for route permissions
const WILDCARD = '*' as AppRouteKeys;

// Cast the imported JSON to the expected structure
const appRoutePermissions = routePermissions as unknown as {
  routeConfig: Record<string, AppRouteKeys[]>;
  routeTransitions: Record<string, AppRouteKeys[]>;
  publicRoutes: AppRouteKeys[];
};

// Define types for our lookup tables
export type RouteTransitionMap = Record<string, Record<string, boolean>>;
export type RoleRouteMap = Record<string, Record<string, boolean>>;
export type TransitionLookupKey = `${string}:${string}:${string}`;
export type TransitionLookupMap = Record<TransitionLookupKey, boolean>;

// Singleton class to hold pre-computed route permissions
class RouteConfigService {
  private static instance: RouteConfigService;

  // Pre-computed lookup tables
  private routeTransitionMap: RouteTransitionMap = {};
  private roleRouteMap: RoleRouteMap = {};
  // Cache for transition lookups - only populated on demand
  private transitionLookupCache: Record<string, boolean> = {};
  private publicRoutes: Set<string> = new Set();

  private isInitialized = false;

  private constructor() {}

  static getInstance(): RouteConfigService {
    if (!RouteConfigService.instance) {
      RouteConfigService.instance = new RouteConfigService();
    }
    return RouteConfigService.instance;
  }

  init(): void {
    if (this.isInitialized) return;

    console.log('Initializing route configuration...');

    // Initialize public routes
    this.initializePublicRoutes();

    // Initialize route transition map
    this.initializeRouteTransitionMap();

    // Initialize role-based route maps
    this.buildRoleRouteMaps();

    // Pre-compute common transition lookups
    this.buildTransitionLookupMap();

    this.isInitialized = true;
    console.log('Route configuration initialized successfully');
  }

  private initializePublicRoutes(): void {
    const { publicRoutes } = appRoutePermissions;
    publicRoutes.forEach(route => this.publicRoutes.add(route));
  }

  private initializeRouteTransitionMap(): void {
    const { routeTransitions } = appRoutePermissions;

    // Get all route keys from both sources and destinations
    const routeKeys = new Set<string>();
    Object.keys(routeTransitions).forEach((key) => routeKeys.add(key));
    Object.values(routeTransitions).forEach((destinations) => {
      destinations.forEach((dest) => {
        if (dest !== WILDCARD) routeKeys.add(dest);
      });
    });

    const allRoutes = Array.from(routeKeys);

    allRoutes.forEach((fromRoute) => {
      this.routeTransitionMap[fromRoute] = {};

      allRoutes.forEach((toRoute) => {
        this.routeTransitionMap[fromRoute][toRoute] = false;
      });

      const allowedTransitions = routeTransitions[fromRoute] || [];
      allowedTransitions.forEach((toRoute) => {
        const routeStr = String(toRoute);
        if (routeStr === '*') {
          allRoutes.forEach((route) => {
            this.routeTransitionMap[fromRoute][route] = true;
          });
        } else {
          this.routeTransitionMap[fromRoute][toRoute] = true;
        }
      });
    });

    if (routeTransitions['*']) {
      const wildcardDestinations = routeTransitions['*'];

      allRoutes.forEach((fromRoute) => {
        wildcardDestinations.forEach((toRoute) => {
          const routeStr = String(toRoute);
          if (routeStr !== '*') {
            this.routeTransitionMap[fromRoute][toRoute] = true;
          }
        });
      });
    }
  }

  private buildRoleRouteMaps(): void {
    const { routeConfig } = appRoutePermissions;

    const routeKeys = new Set<string>();
    Object.keys(routeConfig).forEach((key) => routeKeys.add(key));
    Object.values(routeConfig).forEach((routes) => {
      routes.forEach((route) => {
        if (route !== WILDCARD) routeKeys.add(route);
      });
    });

    const allRoutes = Array.from(routeKeys);

    Object.values(UserRoleEnum).forEach((role) => {
      this.roleRouteMap[role] = {};

      allRoutes.forEach((route) => {
        this.roleRouteMap[role][route] = false;
      });

      const allowedRoutes = routeConfig[role] || [];
      allowedRoutes.forEach((route) => {
        if (route === WILDCARD) {
          allRoutes.forEach((r) => {
            this.roleRouteMap[role][r] = true;
          });
        } else {
          this.roleRouteMap[role][route] = true;
        }
      });
    });
  }

  private buildTransitionLookupMap(): void {
    const userRoles = Object.values(UserRoleEnum);
    const commonRoutes = [AppRoutes.DASHBOARD.key, AppRoutes.LOGIN.key];

    commonRoutes.forEach((fromRoute) => {
      const possibleDestinations = this.routeTransitionMap[fromRoute] || {};
      const toRoutes = Object.keys(possibleDestinations);

      toRoutes.forEach((toRoute) => {
        userRoles.slice(0, 2).forEach((userRole) => {
          this.validateRouteAccess(fromRoute, toRoute, userRole);
        });
      });
    });
  }

  private createLookupKey(
    fromRoute: string,
    toRoute: string,
    userRole: UserRoleEnum
  ): TransitionLookupKey {
    return `${fromRoute}:${toRoute}:${userRole}` as TransitionLookupKey;
  }

  public validateRouteAccess(
    fromRoute: string,
    toRoute: string,
    userRole: UserRoleEnum
  ): boolean {
    const key = this.createLookupKey(fromRoute, toRoute, userRole);

    if (this.transitionLookupCache[key] !== undefined) {
      return this.transitionLookupCache[key];
    }

    const hasRouteAccess = this.hasRouteAccess(toRoute as AppRouteKeys, userRole);

    if (!hasRouteAccess) {
      this.transitionLookupCache[key] = false;
      return false;
    }

    const isTransitionAllowed = this.routeTransitionMap[fromRoute]?.[toRoute] || false;

    this.transitionLookupCache[key] = isTransitionAllowed;
    return this.transitionLookupCache[key];
  }

  isTransitionAllowed(
    fromRoute: AppRouteKeys,
    toRoute: AppRouteKeys,
    userRole: UserRoleEnum
  ): boolean {
    if (!this.isInitialized) {
      this.init();
    }

    if (this.isPublicRoute(toRoute)) {
      return true;
    }

    return this.validateRouteAccess(fromRoute, toRoute, userRole);
  }

  isPublicRoute(route: AppRouteKeys): boolean {
    return this.publicRoutes.has(route);
  }

  hasRouteAccess(
    route: AppRouteKeys,
    userRole: UserRoleEnum
  ): boolean {
    if (!this.isInitialized) {
      this.init();
    }

    if (this.isPublicRoute(route)) {
      return true;
    }

    return this.roleRouteMap[userRole]?.[route] || false;
  }
}

// Export singleton instance
export const routeConfigService = RouteConfigService.getInstance();

// Initialize during server startup
routeConfigService.init();

export default routeConfigService;

This singleton service initializes once at server startup and caches permission lookups for efficiency. It provides methods to check if:

A route is public
A user role has access to a specific route
A transition from one route to another is allowed

✅ Step 5: Create a Navigation Hook

Now let's create a hook to handle navigation with permission checks:

// app/utils/navigation.ts
import { useNavigate, useLocation } from '@remix-run/react';
import { useNavigationStore } from '~/stores/navigationStore';
import { AppRouteKeys, AppRoutes, getRouteFromPath } from './routeUtils';

export const useNavigation = () => {
  const navigate = useNavigate();
  const location = useLocation();
  const { currentRoute, setRoute } = useNavigationStore();

  const goTo = async (to: AppRouteKeys) => {
    try {
      // Check if we're in a browser environment
      if (typeof window === 'undefined') {
        console.warn('Attempted to use navigation in server environment');
        return false;
      }

      const path = location.pathname;
      const currentRouteFromPath = getRouteFromPath(path) as AppRouteKeys;

      // Use the route from path or fallback to the store value
      let fromRoute = currentRouteFromPath || currentRoute;

      if (!fromRoute) {
        console.warn(`⚠️ [Navigation] Cannot determine current route from path ${path}`);
        fromRoute = 'UNKNOWN' as AppRouteKeys; // Use a fallback
      } else if (currentRouteFromPath !== currentRoute) {
        // If there's a mismatch, log it and update the store
        console.log(
          `📍 [Navigation] Updating route in store: path=${currentRouteFromPath}, store=${currentRoute || 'null'}`
        );
      }

      // Always update navigation store with current route
      setRoute(fromRoute);

      sessionStorage.setItem('navigation_from', fromRoute);
      sessionStorage.setItem('navigation_to', to);

      const originalFetch = window.fetch;

      window.fetch = function (input: RequestInfo | URL, init?: RequestInit) {
        const newInit: RequestInit = init ? { ...init } : {};
        const headers = new Headers(newInit.headers || {});

        // Get navigation info from sessionStorage
        const navFrom = sessionStorage.getItem('navigation_from') || fromRoute;

        // Set navigation headers for server-side validation
        headers.set('X-Client-Navigation', 'true');
        headers.set('X-Navigation-From', navFrom);
        headers.set('X-Navigation-To', to);

        newInit.headers = headers;

        return originalFetch(input, newInit);
      };

      setTimeout(() => {
        window.fetch = originalFetch;
      }, 2000); // Delay restoration to allow Remix navigation to complete

      // Execute the navigation
      const targetPath = AppRoutes[to].path;

      // Update route in store
      setRoute(to);

      // Perform navigation
      navigate(targetPath);

      // Clear navigation state after successful navigation
      setTimeout(() => {
        sessionStorage.removeItem('navigation_from');
      }, 200);

      return true;
    } catch (error) {
      console.error('Navigation error:', error);
      return false;
    }
  };

  return { goTo };
};

/**
 * Helper function to determine the route key from a URL path
 */
export function getRouteKeyFromPath(path: string): AppRouteKeys | null {
  return getRouteFromPath(path) as AppRouteKeys | null;
}

✅ Step 6: Create a Secure Link Component

This component enhances <Link> by integrating our navigation tracking and route config. It prevents default navigation and relies on the goTo() function from our useNavigation() utility, which logs and manages transitions.

app/components/SecureLink.tsx

import React from 'react';
import { AppRouteKeys, AppRoutes } from '~/utils/routeUtils';
import { Link } from '@remix-run/react';
import { useNavigation } from '~/utils/navigation';
import { useNavigationStore } from '~/stores/navigationStore';

type SecureLinkProps = {
  to: AppRouteKeys;
  className?: string;
  children: React.ReactNode;
  onClick?: (e: React.MouseEvent) => void;
};

/**
 * A secure link that uses our custom navigation logic.
 * All permission checks happen server-side via middleware.
 */
export function SecureLink({ to, className, children, onClick }: SecureLinkProps) {
  const { goTo } = useNavigation();

  const handleClick = (e: React.MouseEvent) => {
    e.preventDefault();

    const { currentRoute } = useNavigationStore.getState();
    console.log(`🔗 [SecureLink] Navigating from ${currentRoute || 'UNKNOWN'} to ${to}`);

    if (!currentRoute) {
      console.warn('⚠️ No currentRoute in navigation store. This might lead to incorrect navigation tracking.');
    }

    goTo(to); // handles history + header metadata

    if (onClick) {
      onClick(e);
    }
  };

  const targetPath = AppRoutes[to].path;

  return (
    <Link
      to={targetPath}
      className={className}
      onClick={handleClick}
      data-testid={`secure-link-${to}`}
      data-route-key={to}
      preventScrollReset={false}
    >
      {children}
    </Link>
  );
}

✅ Step 7: Create a Navigation Middleware

This middleware sits server-side and intercepts navigations. It enforces rules based on user roles, allowed transitions, and route access using your route config.

app/middleware/navigationMiddleware.server.ts

import { redirect } from '@remix-run/node';
import type { Session } from '@remix-run/node';
import { UserRoleEnum, AppRouteKeys, getRouteFromPath } from '~/utils/routeUtils';
import routeConfigService from '~/config/routeConfigLoader.server';

interface NavigationContext {
  request: Request;
  session: Session;
}

/**
 * Validates navigation intent against route permissions and allowed transitions.
 */
export async function processNavigation({ request, session }: NavigationContext): Promise<Response | null> {
  const isClientNavigation = request.headers.get('X-Client-Navigation') === 'true';

  const url = new URL(request.url);
  const path = url.pathname;
  const toRoute = getRouteFromPath(path) as AppRouteKeys;

  if (!toRoute) {
    return redirect('/access-denied');
  }

  if (routeConfigService.isPublicRoute(toRoute)) {
    return null;
  }

  const user = session.get('user');
  if (!user) {
    return redirect('/login');
  }

  const userRole = UserRoleEnum[user.role as keyof typeof UserRoleEnum];
  if (!userRole) {
    return redirect('/access-denied');
  }

  const hasAccess = routeConfigService.hasRouteAccess(toRoute, userRole);
  if (!hasAccess) {
    return redirect('/access-denied');
  }

  if (isClientNavigation) {
    const fromRoute = request.headers.get('X-Navigation-From') as AppRouteKeys;

    if (fromRoute) {
      const isTransitionAllowed = routeConfigService.isTransitionAllowed(fromRoute, toRoute, userRole);
      if (!isTransitionAllowed) {
        return redirect('/access-denied');
      }
    }
  }

  return null;
}

🧭 Step 8: Create a Root Loader with Middleware

Let’s connect our middleware logic into the Remix root loader. This helps us process authentication and navigation before the app renders anything.

// app/root.tsx
import type { LoaderFunctionArgs, MetaFunction } from '@remix-run/node';
import { json } from '@remix-run/node';
import {
  Links,
  LiveReload,
  Meta,
  Outlet,
  Scripts,
  ScrollRestoration,
  useLoaderData,
} from '@remix-run/react';
import { getSession, commitSession } from './sessions.server';
import { processNavigation } from './middleware/navigationMiddleware.server';
import { AppRouteKeys, getRouteFromPath } from './utils/routeUtils';
import { useEffect } from 'react';
import { useNavigationStore } from './stores/navigationStore';

export const meta: MetaFunction = () => {
  return [
    { title: 'E-Commerce Platform' },
    { name: 'description', content: 'Welcome to our e-commerce platform!' },
  ];
};

export async function loader({ request }: LoaderFunctionArgs) {
  const session = await getSession(request.headers.get('Cookie'));

  const navigationResult = await processNavigation({ request, session });
  if (navigationResult) return navigationResult;

  const url = new URL(request.url);
  const currentRoute = getRouteFromPath(url.pathname) as AppRouteKeys;

  return json({
    currentRoute,
    user: session.get('user'),
  }, {
    headers: {
      'Set-Cookie': await commitSession(session),
    },
  });
}

export default function App() {
  const { currentRoute, user } = useLoaderData<typeof loader>();
  const { setRoute } = useNavigationStore();

  useEffect(() => {
    if (currentRoute) {
      setRoute(currentRoute);
    }
  }, [currentRoute, setRoute]);

  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <Meta />
        <Links />
      </head>
      <body>
        <Outlet />
        <ScrollRestoration />
        <Scripts />
        <LiveReload />
      </body>
    </html>
  );
}

💡 Why this matters: By centralizing route and session logic in the root loader, we simplify access control and route tracking across the app.

🔐 Step 9: Create Session Utilities

Next up, let’s create reusable helpers to manage our session state using cookies.

// app/sessions.server.ts
import { createCookieSessionStorage } from '@remix-run/node';

const sessionStorage = createCookieSessionStorage({
  cookie: {
    name: 'app_session',
    secure: process.env.NODE_ENV === 'production',
    secrets: ['s3cr3t1'], // Replace with your secret
    sameSite: 'lax',
    path: '/',
    maxAge: 60 * 60 * 24 * 30, // 30 days
    httpOnly: true,
  },
});

export async function getSession(cookieHeader: string | null) {
  return sessionStorage.getSession(cookieHeader);
}

export async function commitSession(session: any) {
  return sessionStorage.commitSession(session);
}

export async function destroySession(session: any) {
  return sessionStorage.destroySession(session);
}

✅ Pro Tip: Store the session secret in an environment variable in production for security.

🧱 Step 10: Create a Layout Component

Let’s wrap your application with a consistent layout that includes navigation based on user roles.

// app/components/MainLayout.tsx
import React from 'react';
import { SecureLink } from './SecureLink';
import { UserRoleEnum } from '~/utils/routeUtils';
import { useLoaderData } from '@remix-run/react';

type MainLayoutProps = {
  children: React.ReactNode;
};

export default function MainLayout({ children }: MainLayoutProps) {
  const { user } = useLoaderData<{ user: { name: string, role: string } }>();

  const getNavLinks = () => {
    const role = user?.role as UserRoleEnum;

    const commonLinks = [
      { to: 'DASHBOARD', label: 'Dashboard' },
      { to: 'ACCOUNT', label: 'My Account' },
      { to: 'LOGOUT', label: 'Logout' },
    ];

    const roleSpecificLinks = {
      [UserRoleEnum.SYSTEM_ADMIN]: [
        { to: 'USER_MANAGEMENT', label: 'Users' },
        { to: 'PRODUCT_MANAGEMENT', label: 'Products' },
        { to: 'STORE_SETTINGS', label: 'Settings' },
        { to: 'REPORTS', label: 'Reports' },
      ],
      [UserRoleEnum.STORE_MANAGER]: [
        { to: 'PRODUCT_MANAGEMENT', label: 'Products' },
        { to: 'STORE_SETTINGS', label: 'Settings' },
        { to: 'ORDERS', label: 'Orders' },
        { to: 'REPORTS', label: 'Reports' },
      ],
      [UserRoleEnum.SUPPORT_AGENT]: [
        { to: 'CUSTOMER_SUPPORT', label: 'Support' },
        { to: 'ORDERS', label: 'Orders' },
      ],
      [UserRoleEnum.CUSTOMER]: [
        { to: 'ORDERS', label: 'My Orders' },
        { to: 'WISHLIST', label: 'Wishlist' },
      ],
    };

    return [...(roleSpecificLinks[role] || []), ...commonLinks];
  };

  const navLinks = getNavLinks();

  return (
    <div className="min-h-screen flex flex-col bg-gray-50">
      <header className="bg-white shadow">
        <div className="max-w-7xl mx-auto px-4">
          <div className="flex justify-between h-16">
            <div className="flex">
              <div className="flex-shrink-0 flex items-center">
                <span className="text-lg font-bold">E-Commerce Platform</span>
              </div>
              <nav className="ml-6 flex space-x-8">
                {navLinks.map((link) => (
                  <SecureLink
                    key={link.to}
                    to={link.to as any}
                    className="inline-flex items-center px-1 pt-1 text-sm font-medium text-gray-700 hover:text-blue-600"
                  >
                    {link.label}
                  </SecureLink>
                ))}
              </nav>
            </div>
            <div className="flex items-center">
              {user && (
                <div className="text-sm font-medium text-gray-700">
                  Welcome, {user.name} ({user.role})
                </div>
              )}
            </div>
          </div>
        </div>
      </header>

      <main className="flex-grow">
        <div className="max-w-7xl mx-auto py-6 sm:px-6 lg:px-8">
          {children}
        </div>
      </main>

      <footer className="bg-white shadow">
        <div className="max-w-7xl mx-auto py-4 px-4 sm:px-6 lg:px-8">
          <p className="text-center text-sm text-gray-500">
            © 2025 E-Commerce Platform. All rights reserved.
          </p>
        </div>
      </footer>
    </div>
  );
}

✅ Step 11: Create Route Middleware

// app/middleware/route-middleware.server.ts
import { redirect } from '@remix-run/node';
import type { Session } from '@remix-run/node';
import { AppRouteKeys, UserRoleEnum } from '~/utils/routeUtils';
import routeConfigService from '~/config/routeConfigLoader.server';

export async function requireUser(request: Request, session: Session) {
  const user = session.get('user');

  if (!user) {
    // Redirect to login if no user
    throw redirect('/login');
  }

  return user;
}

export async function requireRole(
  request: Request, 
  session: Session, 
  allowedRoles: UserRoleEnum[]
) {
  const user = await requireUser(request, session);
  const userRole = UserRoleEnum[user.role as keyof typeof UserRoleEnum];

  if (!userRole || !allowedRoles.includes(userRole)) {
    throw redirect('/access-denied');
  }

  return { user, role: userRole };
}

export async function validateRouteAccess(
  request: Request,
  session: Session,
  routeKey: AppRouteKeys
) {
  const user = await requireUser(request, session);
  const userRole = UserRoleEnum[user.role as keyof typeof UserRoleEnum];

  if (!userRole) {
    throw redirect('/access-denied');
  }

  const hasAccess = routeConfigService.hasRouteAccess(routeKey, userRole);

  if (!hasAccess) {
    throw redirect('/access-denied');
  }

  return { user, role: userRole };
}

✅ Step 12: Implement Route Files

Login Route

// app/routes/login.tsx
import { useActionData, Form } from '@remix-run/react';
import { redirect, json } from '@remix-run/node';
import type { ActionFunctionArgs } from '@remix-run/node';
import { getSession, commitSession } from '~/sessions.server';
import { UserRoleEnum } from '~/utils/routeUtils';

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const email = formData.get('email') as string;
  const password = formData.get('password') as string;

  let user = null;

  if (email === 'admin@example.com' && password === 'password') {
    user = {
      id: '1',
      name: 'Admin User',
      email: 'admin@example.com',
      role: 'SYSTEM_ADMIN',
    };
  } else if (email === 'manager@example.com' && password === 'password') {
    user = {
      id: '2',
      name: 'Store Manager',
      email: 'manager@example.com',
      role: 'STORE_MANAGER',
    };
  } else if (email === 'support@example.com' && password === 'password') {
    user = {
      id: '3',
      name: 'Support Agent',
      email: 'support@example.com',
      role: 'SUPPORT_AGENT',
    };
  } else if (email === 'customer@example.com' && password === 'password') {
    user = {
      id: '4',
      name: 'Customer User',
      email: 'customer@example.com',
      role: 'CUSTOMER',
    };
  }

  if (!user) {
    return json({
      error: 'Invalid email or password',
    });
  }

  const session = await getSession(request.headers.get('Cookie'));
  session.set('user', user);

  return redirect('/dashboard', {
    headers: {
      'Set-Cookie': await commitSession(session),
    },
  });
}

export default function Login() {
  const actionData = useActionData<typeof action>();

  return (
    <div className="min-h-screen flex items-center justify-center bg-gray-50">
      <div className="max-w-md w-full space-y-8 p-8 bg-white shadow rounded-lg">
        <div>
          <h2 className="mt-6 text-center text-3xl font-extrabold text-gray-900">
            Sign in to your account
          </h2>
        </div>
        <Form method="post" className="mt-8 space-y-6">
          <div className="rounded-md shadow-sm -space-y-px">
            <div>
              <label htmlFor="email" className="sr-only">
                Email address
              </label>
              <input
                id="email"
                name="email"
                type="email"
                autoComplete="email"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 border border-gray-300 placeholder-gray-500 text-gray-900 rounded-t-md focus:outline-none focus:ring-blue-500 focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Email address"
              />
            </div>
            <div>
              <label htmlFor="password" className="sr-only">
                Password
              </label>
              <input
                id="password"
                name="password"
                type="password"
                autoComplete="current-password"
                required
                className="appearance-none rounded-none relative block w-full px-3 py-2 border border-gray-300 placeholder-gray-500 text-gray-900 rounded-b-md focus:outline-none focus:ring-blue-500 focus:border-blue-500 focus:z-10 sm:text-sm"
                placeholder="Password"
              />
            </div>
          </div>

          {actionData?.error && (
            <div className="text-red-500 text-sm">{actionData.error}</div>
          )}

          <div>
            <div className="text-sm text-gray-600 mb-4">
              Available demo accounts:
              <ul className="list-disc pl-5 mt-2">
                <li>admin@example.com / password</li>
                <li>manager@example.com / password</li>
                <li>support@example.com / password</li>
                <li>customer@example.com / password</li>
              </ul>
            </div>
            <button
              type="submit"
              className="group relative w-full flex justify-center py-2 px-4 border border-transparent text-sm font-medium rounded-md text-white bg-blue-600 hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-blue-500"
            >
              Sign in
            </button>
          </div>
        </Form>
      </div>
    </div>
  );
}

✅ Step 13: Access Denied Route

File: app/routes/access-denied.tsx

// app/routes/access-denied.tsx
export default function AccessDenied() {
  return (
    <div className="min-h-screen flex items-center justify-center bg-gray-100 px-4">
      <div className="max-w-md w-full text-center">
        <h1 className="text-4xl font-bold text-red-600">Access Denied</h1>
        <p className="mt-4 text-gray-600">
          You do not have permission to access this page.
        </p>
        <a
          href="/dashboard"
          className="mt-6 inline-block text-blue-600 hover:underline"
        >
          Go to Dashboard
        </a>
      </div>
    </div>
  );
}
}

✅ Step 14: Logout Route

File: app/routes/logout.tsx

// app/routes/logout.tsx
import { redirect } from '@remix-run/node';
import type { LoaderFunctionArgs } from '@remix-run/node';
import { getSession, destroySession } from '~/sessions.server';

export async function loader({ request }: LoaderFunctionArgs) {
  const session = await getSession(request.headers.get('Cookie'));

  return redirect('/login', {
    headers: {
      'Set-Cookie': await destroySession(session),
    },
  });
}

Embracing Security Through Structure: A Complete RBAC Solution

The Journey Complete

We've built a comprehensive role-based navigation system for a Remix application that:

Loads permission configuration just once at server startup
Enforces permissions on both the client and server
Validates navigation transitions to prevent unauthorized access
Provides a clean, type-safe API for components

Advantages That Scale

This approach delivers multiple benefits that extend beyond basic access control:

Performance: We precompute and cache permission lookups for efficiency, eliminating redundant calculations
Security: We enforce permissions on both client and server sides, creating a dual layer of protection
Maintainability: The permission system is centralized in a JSON file, making updates straightforward
Type Safety: TypeScript ensures we use valid routes everywhere, preventing navigation errors

Architecture That Empowers

The complete solution provides a robust foundation:

A type-safe route registry that keeps your application navigation in sync
A singleton service that loads permissions configuration once, optimizing memory usage
A navigation middleware for server-side enforcement, preventing backdoor access
Custom link components for client-side navigation, maintaining consistent UX
A Zustand store for tracking navigation state with minimal overhead

Beyond The Horizon

This architecture can scale to handle complex permission scenarios while keeping the API simple for developers. You can easily extend it to support more granular permissions, nested routes, or dynamic permissions based on data access.

By implementing this pattern, you've created not just a security layer, but a framework that makes your application more robust, maintainable, and user-focused. Your users will navigate confidently within their permitted boundaries, while you rest assured that your application's authorization model stands strong against unauthorized access attempts.

The journey to secure, role-based navigation is complete—but the possibilities for extending this foundation are just beginning.

Ultimate guide to Flutter Keys: Optimizing Your Flutter App's Performance

Prince Tomar — Mon, 30 Dec 2024 12:52:52 +0000

Ultimate guide to Flutter Keys: Optimizing Flutter Your App's Performance

Understanding and effectively using Flutter Keys is essential for creating dynamic, performant applications. Keys serve as unique identifiers for widgets, playing a crucial role in maintaining widget states, avoiding UI glitches, and enhancing app responsiveness. Whether you're a beginner or an experienced developer, this guide will provide you with insights into the practical applications of Flutter Keys, complete with examples, including a functional to-do app.

What Are Flutter Keys?

In Flutter, a Key is a unique identifier assigned to widgets, enabling Flutter's framework to differentiate between them during widget tree updates. When widgets are reordered or replaced, Keys ensure that their state is preserved and the UI behaves as expected.

Why Are Keys Important?

Without Keys, Flutter relies on its internal widget comparison mechanism. This default behavior can lead to:

Flickering animations due to unnecessary rebuilds.
State loss when widgets are dynamically reordered or replaced.
Performance degradation caused by inefficient updates.

Keys act as "anchors" for widgets in the widget tree, helping Flutter efficiently update only the necessary parts of the UI.

Types of Keys in Flutter

Flutter provides three primary types of Keys: GlobalKey, UniqueKey, and ValueKey. Each has specific use cases, explained below with examples.

1. GlobalKey

A GlobalKey uniquely identifies a widget across the entire widget tree. It is often used to interact with widgets outside their parent subtree.

Example: Form Validation

final GlobalKey<FormState> _formKey = GlobalKey<FormState>();

class RegistrationForm extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: [
          TextFormField(
            validator: (value) => value!.isEmpty ? 'Enter your name' : null,
          ),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState!.validate()) {
                print('Form is valid');
              }
            },
            child: Text('Submit'),
          ),
        ],
      ),
    );
  }
}

The GlobalKey enables access to the form's state for validation, regardless of its position in the widget tree.

2. UniqueKey

A UniqueKey generates a unique identifier for each widget instance, even if they have identical appearances.

Example: Dynamic List

List<Widget> generateItems(int count) {
  return List.generate(count, (index) {
    return ListTile(
      key: UniqueKey(),
      title: Text('Item $index'),
    );
  });
}

UniqueKeys ensure that each ListTile widget is treated as a distinct entity, preventing UI glitches when the list changes dynamically.

3. ValueKey

A ValueKey identifies widgets based on a specific value, such as an item ID. This makes it ideal for lists with identifiable data.

Example: Shopping Cart

ListView.builder(
  itemCount: items.length,
  itemBuilder: (context, index) {
    final item = items[index];
    return ListTile(
      key: ValueKey(item.id),
      title: Text(item.name),
      trailing: Text('Qty: ${item.quantity}'),
    );
  },
);

Here, ValueKeys use the unique item.id to maintain the correct association between widgets and data.

A Practical Example: To-Do App

Let’s build a simple to-do app to demonstrate the importance of using Keys.

Problem: Flickering and State Loss

Without Keys, removing an item from the list can cause the entire list to rebuild, resulting in:

Loss of checkbox states.
Flickering UI.

Solution: Using ValueKey

Full Example

import 'package:flutter/material.dart';

void main() => runApp(TodoApp());

class Todo {
  final String id;
  final String task;
  bool isCompleted;

  Todo({required this.id, required this.task, this.isCompleted = false});
}

class TodoApp extends StatefulWidget {
  @override
  _TodoAppState createState() => _TodoAppState();
}

class _TodoAppState extends State<TodoApp> {
  final List<Todo> _todos = [
    Todo(id: '1', task: 'Buy groceries'),
    Todo(id: '2', task: 'Walk the dog'),
    Todo(id: '3', task: 'Read a book'),
  ];

  void _toggleComplete(String id) {
    setState(() {
      final todo = _todos.firstWhere((todo) => todo.id == id);
      todo.isCompleted = !todo.isCompleted;
    });
  }

  void _removeTask(String id) {
    setState(() {
      _todos.removeWhere((todo) => todo.id == id);
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text('To-Do App')),
        body: ListView.builder(
          itemCount: _todos.length,
          itemBuilder: (context, index) {
            final todo = _todos[index];
            return ListTile(
              key: ValueKey(todo.id),
              title: Text(
                todo.task,
                style: TextStyle(
                  decoration: todo.isCompleted ? TextDecoration.lineThrough : null,
                ),
              ),
              leading: Checkbox(
                value: todo.isCompleted,
                onChanged: (_) => _toggleComplete(todo.id),
              ),
              trailing: IconButton(
                icon: Icon(Icons.delete),
                onPressed: () => _removeTask(todo.id),
              ),
            );
          },
        ),
      ),
    );
  }
}

Explanation

ValueKey: Each task is identified by its unique id.
State Preservation: When a task is added or removed, other tasks maintain their state (e.g., checkbox status).
Smooth UI Updates: The app avoids unnecessary rebuilds, resulting in a flicker-free experience.

Best Practices for Using Keys

Use judiciously: Avoid assigning Keys to every widget unnecessarily, as this can introduce overhead.
Ensure uniqueness: When using ValueKey, ensure the value (e.g., ID) is unique within the widget tree.
Minimize GlobalKey usage: While powerful, GlobalKeys can increase memory consumption if overused.

Conclusion

Flutter Keys are a vital tool for managing widget states, improving performance, and delivering a seamless user experience. By understanding their types and applying them appropriately, developers can avoid common UI issues and craft professional-grade applications. Whether you're fixing a flickering to-do list or optimizing a dynamic shopping cart, Keys can unlock the full potential of your Flutter apps.

Mastering Flutter Architecture: From CLEAN to Feature-First for Faster, Scalable Development

Prince Tomar — Thu, 03 Oct 2024 04:06:45 +0000

Understanding CLEAN Architecture in Flutter and Alternatives

In the Flutter development community, CLEAN architecture has gained traction for its organized structure and separation of concerns. Proposed by Uncle Bob, this architecture aims to make code more maintainable by dividing it into layers such as data, domain, and presentation. However, while the approach is theoretically sound, it has its challenges in practice, especially for those looking for simplicity and scalability.

In this article, we will explore why CLEAN architecture, though popular, may not always be the best solution. We will also look at two alternatives: feature-first and mixed approaches, which can simplify project structures while maintaining clarity.

What is the Problem with CLEAN Architecture?

The problem with CLEAN architecture often arises from its layer-first nature. In a typical CLEAN setup, files related to a particular feature (e.g., "Orders") are distributed across multiple folders. Let's consider the following folder structure:

Image 0: Traditional CLEAN Architecture

In this setup:

app contains configurations, extensions, services, and other essential utilities.
data has models, providers, and repositories.
domain is used for entities and use cases.
presentation holds controllers and UI-related files, spread across multiple subfolders.

For instance, the files related to the "Orders" feature might be scattered like this:

order_model.dart in the data/models folder.
order_service.dart in the data/providers folder.
order_list_controller.dart and order_details_controller.dart in presentation/controllers.
UI files like order_list_view.dart and order_details_view.dart in different subfolders under presentation/pages.

While this separation of concerns is great in theory, it leads to inconvenience in real-world projects. A developer working on a specific feature, such as "Orders," may need to switch between multiple folders, leading to fragmentation and slower development speed.

Why is it Inconvenient?

The key issue with CLEAN architecture lies in its overly layered structure, which increases complexity. For beginners, this can be intimidating, and for experienced developers, it can be inefficient when iterating on features.

As shown in Image 0, the CLEAN architecture leads to a structure where related files are separated by their roles in the system (models, services, controllers, etc.), but not by the feature they belong to. This complicates navigating and maintaining the codebase.

Simpler Alternatives: Feature-First Architecture

To address these problems, the feature-first architecture is a simpler, more scalable solution. Instead of organizing code by layer (data, domain, presentation), it organizes it by feature. This way, all the files related to a particular feature like "Orders" are in one place.

Image 1: Feature-First Structure

In Image 1, the folder structure is organized by feature:

auth/ contains everything related to authentication.
orders/ contains the order_model.dart, order_service.dart, order_details_controller.dart, order_list_controller.dart, and their corresponding views all in one place.

This structure is highly intuitive:

Easy to maintain: Developers can find all relevant files for a feature in a single folder.
Scalable: New features can be added by simply creating new folders, without affecting existing structures.

For example, the "Orders" feature has all the necessary files (controller, model, view) in one folder, making it much easier to work on than jumping between multiple directories.

Mixed Approach: A Balanced Middle Ground

For developers who prefer some level of layer separation but want to keep things simpler than CLEAN, a mixed approach can be useful. In this approach, there are only two main layers: view and data. Within these layers, files are organized by feature, offering the benefits of both worlds.

Image 2: Mixed Approach

In Image 2, the project is divided into common, data, and view layers:

common contains shared components, constants, and utilities.
data has feature-related services and models. For example, order_model.dart and order_service.dart are in the data/order folder.
view contains all UI components. For example, order_details_view.dart and order_list_view.dart are grouped in their respective subfolders like view/order_details and view/order_list.

This hybrid approach ensures that while data and view files are separated into their respective layers, they are still organized by feature within those layers. Developers can maintain separation of concerns without the overhead of deeply nested and fragmented file structures.

Advanced Mixed Approach: Modular Organization

If you want to further modularize your application, another variation of the mixed approach can be used. In this, the modules folder groups feature-specific data and views.

Image 3: Modular Organization

In Image 3, the modules folder contains:

order_details and order_list submodules, each with their own controller and view subfolders.
This approach extends the feature-first philosophy by grouping all logic for individual screens or modules, keeping things clean and organized.

Here, each feature module is almost self-contained, allowing for better modularization and isolation, which can help with testing and reusability.

Conclusion

While CLEAN architecture is well-known in the Flutter community, it is not always the best fit for every project. It tends to lead to overly complex and fragmented structures, making navigation and maintenance more challenging. A feature-first approach, as seen in Image 1, is much simpler, making it easy to scale as the project grows.

For those who prefer a little separation, the mixed approach shown in Images 2 and 3 offers a balance between simplicity and organization, separating data and views but still keeping features together.

Choosing the right architecture for your Flutter project depends on your team's needs and preferences, but it’s crucial to prioritize simplicity and scalability to ensure smooth development and maintainability over time.

Implementing Sentry for Error Monitoring in Flutter: A Complete Guide

Prince Tomar — Sat, 07 Sep 2024 02:52:24 +0000

Introduction

Error monitoring is a critical part of app development, helping you catch and fix bugs before they impact your users. Sentry is one of the most popular error-tracking services, and in this article, we'll explore how to integrate and use Sentry in your Flutter application.

Whether you're a beginner or an experienced developer, this guide will show you how to:

Set up Sentry for Flutter.
Capture different types of errors (UI, functional, asynchronous).
Handle errors for better app stability and debugging.

Step 1: Setting Up Sentry for Flutter

1.1. Create a Sentry Account

Before integrating Sentry into your Flutter app, you'll need to:

Create a free account at Sentry.io.
Create a new project for Flutter in Sentry.
Copy the DSN (Data Source Name) from your Sentry project settings.

Here's how to do that:

Go to Settings in your Sentry dashboard.
Navigate to Projects and select your project.
From the project sidebar, select the Client Keys (DSN) tab.
Copy your DSN and Security Header Endpoint, and paste them into your Flutter app's configuration.

The DSN is essential for connecting your Flutter app to Sentry.

1.2. Add Sentry to Your Flutter Project

In your pubspec.yaml file, add the following dependency:



dependencies:
  sentry_flutter: ^7.0.0 # Replace with the latest version

Run the following command to install the package:



flutter pub get

Step 2: Initializing Sentry in Flutter

Next, initialize Sentry at the start of your app. Modify your main.dart file like this:



import 'package:flutter/material.dart';
import 'package:sentry_flutter/sentry_flutter.dart';
import 'package:your_project/constants.dart'; // Your DSN in constants

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await SentryFlutter.init(
    (options) {
      options.dsn = AppConstants.sentryDSN; // Your DSN
      options.tracesSampleRate = 1.0; // Performance monitoring
      options.profilesSampleRate = 1.0; // Optional profiling
      options.debug = true; // Debug logs during development
    },
    appRunner: () => runApp(const MyApp()), // Your app
  );

  sentryInit();
}

Explanation:

WidgetsFlutterBinding.ensureInitialized() makes sure that the Flutter framework is initialized before starting Sentry.
SentryFlutter.init connects Sentry with your app using the DSN and initializes the app.
tracesSampleRate allows for performance monitoring.

Step 3: Capturing Errors in Flutter

Flutter apps can encounter many types of errors. Let's configure Sentry to capture all errors in your app:

3.1. Handling Flutter UI and Build Errors

Add the following function to capture Flutter-specific UI errors:



void sentryInit() async {
  FlutterError.onError = (FlutterErrorDetails details) async {
    await Sentry.captureException(
      details.exception, 
      stackTrace: details.stack,
    );
    FlutterError.presentError(details);
  };
}

3.2. Handling Uncaught and Platform-Specific Errors

To capture platform-specific and uncaught errors, use the PlatformDispatcher:



PlatformDispatcher.instance.onError = (error, stack) {
  Sentry.captureException(error, stackTrace: stack);
  return true; // Prevent app from crashing
};

3.3. Handling Asynchronous Errors

Flutter supports async operations, but they might throw errors too. Use runZonedGuarded to catch those:



runZonedGuarded(
  () {
    // Run your app logic here
  },
  (error, stackTrace) async {
    await Sentry.captureException(error, stackTrace: stackTrace);
  },
);

3.4. Example: Manually Throwing an Error

Let’s test the setup by throwing an error intentionally:



FloatingActionButton(
  onPressed: () {
    throw Exception("This is a test error!");
  },
  child: const Icon(Icons.error),
),

Pressing the button will trigger an exception, and Sentry will capture it.

Step 4: Advanced Error Handling

4.1. Capturing Logs and Breadcrumbs

Sentry supports breadcrumbs, which provide context about events leading up to an error:



Sentry.addBreadcrumb(Breadcrumb(
  message: "User clicked on login button",
  level: SentryLevel.info,
));

4.2. Performance Monitoring

By setting the tracesSampleRate, you can also monitor your app’s performance (e.g., UI jank):



options.tracesSampleRate = 1.0; // Enables 100% performance tracing

4.3. Reporting Custom Events

You can also report specific events manually:



Sentry.captureMessage("This is a custom log message.");

Step 5: Testing and Debugging

Make sure to test the error handling by simulating different types of errors:

UI errors: Introduce issues in the widget tree (e.g., widget overflows).
Async errors: Trigger errors during async operations (e.g., API calls).
Manual errors: Use throw Exception() to simulate unexpected errors.

Check your Sentry dashboard to ensure all the errors are properly logged.

Conclusion

Integrating Sentry into your Flutter app helps you capture real-time crashes and performance issues in production. With the steps outlined:

You can monitor UI, functional, and asynchronous errors.
Gain insight into app performance issues.
Log important events and context with breadcrumbs.

Whether you're new to error handling or an experienced developer, Sentry is an invaluable tool for improving app stability and debugging efficiency.

If you have any questions, feel free to ask in the comments!

Happy coding! 🎉

References:

Clean Code Architecture and BLoC in Flutter: A Comprehensive Guide for Beginners and Experts

Prince Tomar — Mon, 26 Aug 2024 01:25:30 +0000

Flutter has revolutionized the way we build cross-platform mobile and web applications. However, as the complexity of your project grows, you need a structured approach to maintain scalability, readability, and testability. This is where Clean Code Architecture and BLoC (Business Logic Component) pattern come into play. This article will guide you through the fundamentals and advanced concepts of these two key architectural patterns, helping both beginners and experienced developers understand how to apply them in Flutter.

What is Clean Code Architecture?
Why Use Clean Code Architecture in Flutter?
Layers of Clean Code Architecture
Introduction to BLoC Pattern
Why BLoC with Clean Architecture?
Building a Flutter App Using Clean Architecture and BLoC
- Project Structure
- Implementing the Domain Layer
- Implementing the Data Layer
- Implementing the Presentation Layer (BLoC)
Complete Code Example
Testing the Architecture
Best Practices and Advanced Tips

1. What is Clean Code Architecture?

Clean Code Architecture is a software design pattern proposed by Robert C. Martin (also known as Uncle Bob). The main goal of Clean Code Architecture is to ensure separation of concerns. It divides the system into layers, each with a distinct responsibility. These layers include:

Presentation Layer (UI)
Domain Layer (Business Logic)
Data Layer (Data Sources)

The architecture ensures that business logic is isolated from external dependencies such as UI frameworks, databases, or network libraries, making your code more flexible, reusable, and testable.

Key Principles of Clean Architecture

Separation of Concerns: Different parts of the code should handle different responsibilities.
Independence: The core business logic should be independent of UI, data sources, or any external frameworks.
Testability: Since your business logic is decoupled from external elements, it's easier to write unit tests for it.

2. Why Use Clean Code Architecture in Flutter?

While Flutter allows rapid development of UI, Clean Architecture helps you manage complexity in larger applications. Here are some reasons to use Clean Code Architecture in Flutter:

Maintainability: Separation of concerns ensures that changes in one layer won’t affect others.
Scalability: As your app grows, Clean Architecture makes it easier to extend functionalities without refactoring large parts of the codebase.
Testability: By isolating business logic, you can write meaningful unit tests without depending on the UI or data sources.

3. Layers of Clean Code Architecture

In Clean Code Architecture, there are three main layers:

1. Domain Layer (The Core)

This is the heart of your application. It contains:

Entities: Plain Dart classes that represent business models.
Use Cases: Interactors that encapsulate business logic and rules.
Repositories: Abstract contracts that define how data will be fetched.

// entities/user_entity.dart
class UserEntity {
  final String id;
  final String name;

  UserEntity({required this.id, required this.name});
}

// usecases/get_user_usecase.dart
class GetUserUseCase {
  final UserRepository repository;

  GetUserUseCase(this.repository);

  Future<UserEntity> execute(String userId) {
    return repository.getUser(userId);
  }
}

2. Data Layer

This layer handles the data sources and implements the repository interfaces defined in the domain layer. It includes:

Data Models: Classes that represent the data fetched from APIs or local databases.
Data Sources: Implementations for network requests, local databases, etc.
Repository Implementation: Concrete implementations of the repository.

// data/models/user_model.dart
class UserModel {
  final String id;
  final String name;

  UserModel({required this.id, required this.name});

  factory UserModel.fromJson(Map<String, dynamic> json) {
    return UserModel(
      id: json['id'],
      name: json['name'],
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'id': id,
      'name': name,
    };
  }
}

// data/repositories/user_repository_impl.dart
class UserRepositoryImpl implements UserRepository {
  final RemoteDataSource remoteDataSource;

  UserRepositoryImpl(this.remoteDataSource);

  @override
  Future<UserEntity> getUser(String userId) async {
    final userModel = await remoteDataSource.fetchUser(userId);
    return UserEntity(id: userModel.id, name: userModel.name);
  }
}

3. Presentation Layer

This layer contains the UI and State Management logic. This is where the BLoC pattern fits in. We use BLoC to manage state and interact with the domain layer's use cases.

// presentation/bloc/user_bloc.dart
class UserBloc extends Bloc<UserEvent, UserState> {
  final GetUserUseCase getUserUseCase;

  UserBloc(this.getUserUseCase) : super(UserInitial());

  @override
  Stream<UserState> mapEventToState(UserEvent event) async* {
    if (event is GetUserEvent) {
      yield UserLoading();
      try {
        final user = await getUserUseCase.execute(event.userId);
        yield UserLoaded(user);
      } catch (e) {
        yield UserError("Couldn't fetch user");
      }
    }
  }
}

4. Introduction to BLoC Pattern

BLoC (Business Logic Component) is a state management pattern that makes it easy to separate presentation logic from business logic in a Flutter app. The key components of the BLoC pattern are:

Events: Actions that the user or system triggers.
States: The state of the UI based on the events.
BLoC: Handles business logic by mapping events to states.

The main benefit of BLoC is that it allows us to decouple the UI from the logic. The BLoC listens to events (such as button presses) and emits new states that the UI can listen to.

// Event
abstract class UserEvent {}

class GetUserEvent extends UserEvent {
  final String userId;

  GetUserEvent(this.userId);
}

// State
abstract class UserState {}

class UserInitial extends UserState {}

class UserLoading extends UserState {}

class UserLoaded extends UserState {
  final UserEntity user;

  UserLoaded(this.user);
}

class UserError extends UserState {
  final String message;

  UserError(this.message);
}

5. Why BLoC with Clean Architecture?

Using BLoC with Clean Architecture ensures a clear separation between the UI and the business logic, making the code easy to test and maintain. BLoC is responsible for managing state transitions and business rules, while the Clean Architecture layers ensure that the BLoC interacts only with the necessary parts of the codebase, such as use cases and repositories.

6. Building a Flutter App Using Clean Architecture and BLoC

Now, let's build a Flutter app using Clean Architecture and BLoC. We'll create a simple app that fetches a user’s data from an API and displays it on the screen.

Project Structure

lib/
├── data/
│   ├── models/
│   ├── repositories/
│   └── datasources/
├── domain/
│   ├── entities/
│   └── usecases/
├── presentation/
│   ├── bloc/
│   └── screens/
└── main.dart

Implementing the Domain Layer

First, define the UserEntity and UserRepository.

// domain/entities/user_entity.dart
class UserEntity {
  final String id;
  final String name;

  UserEntity({required this.id, required this.name});
}

// domain/repositories/user_repository.dart
abstract class UserRepository {
  Future<UserEntity> getUser(String userId);
}

Next, create the GetUserUseCase to encapsulate the business logic.

// domain/usecases/get_user_usecase.dart
class GetUserUseCase {
  final UserRepository repository;

  GetUserUseCase(this.repository);

  Future<UserEntity> execute(String userId) {
    return repository.getUser(userId);
  }
}

Implementing the Data Layer

Define the UserModel and implement the repository.

// data/models/user_model.dart
class UserModel {
  final String id;
  final String name;

  UserModel({required this.id, required this.name});

  factory UserModel.fromJson(Map<String, dynamic> json) {
    return UserModel(
      id: json['id'],
      name: json['name'],
    );
  }
}

// data/repositories/user_repository_impl.dart
class UserRepositoryImpl implements UserRepository {
  final RemoteDataSource remoteDataSource;

  UserRepositoryImpl(this.remoteDataSource);

  @override
  Future<UserEntity> getUser(String userId) async {
    final userModel = await remoteDataSource.fetchUser(userId);
    return UserEntity(id: userModel.id, name: userModel.name);
  }
}

Implement the RemoteDataSource for network requests.

// data/datasources/remote_data_source.dart
class RemoteDataSource {
  Future<UserModel> fetchUser(String userId

) async {
    // Fake network request for simplicity
    await Future.delayed(Duration(seconds: 2));
    return UserModel(id: userId, name: 'John Doe');
  }
}

Implementing the Presentation Layer (BLoC)

Create the UserBloc to handle state management.

// presentation/bloc/user_bloc.dart
class UserBloc extends Bloc<UserEvent, UserState> {
  final GetUserUseCase getUserUseCase;

  UserBloc(this.getUserUseCase) : super(UserInitial());

  @override
  Stream<UserState> mapEventToState(UserEvent event) async* {
    if (event is GetUserEvent) {
      yield UserLoading();
      try {
        final user = await getUserUseCase.execute(event.userId);
        yield UserLoaded(user);
      } catch (e) {
        yield UserError("Couldn't fetch user");
      }
    }
  }
}

UI Implementation

Now, implement the UI using BlocBuilder to listen for state changes.

// presentation/screens/user_screen.dart
class UserScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('User Profile')),
      body: BlocProvider(
        create: (context) => UserBloc(GetUserUseCase(UserRepositoryImpl(RemoteDataSource()))),
        child: UserProfile(),
      ),
    );
  }
}

class UserProfile extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UserBloc, UserState>(
      builder: (context, state) {
        if (state is UserInitial) {
          return Center(child: Text('Press the button to fetch user data.'));
        } else if (state is UserLoading) {
          return Center(child: CircularProgressIndicator());
        } else if (state is UserLoaded) {
          return Center(child: Text('User: ${state.user.name}'));
        } else if (state is UserError) {
          return Center(child: Text(state.message));
        }
        return Container();
      },
    );
  }
}

7. Complete Code Example

Here’s the complete code for this app with Clean Architecture and BLoC in Flutter:

main.dart

void main() {
  runApp(MaterialApp(
    home: UserScreen(),
  ));
}

8. Testing the Architecture

One of the advantages of Clean Architecture is testability. Let's write unit tests for the GetUserUseCase to ensure that the business logic is working as expected.

void main() {
  final mockUserRepository = MockUserRepository();
  final getUserUseCase = GetUserUseCase(mockUserRepository);

  test('should return user when called with a valid ID', () async {
    // Arrange
    final user = UserEntity(id: '1', name: 'John Doe');
    when(mockUserRepository.getUser(any)).thenAnswer((_) async => user);

    // Act
    final result = await getUserUseCase.execute('1');

    // Assert
    expect(result, user);
  });
}

9. Best Practices and Advanced Tips

Use Dependency Injection: Consider using a package like get_it to manage dependencies in a scalable way.
Avoid Tight Coupling: Always ensure that your business logic does not depend on external frameworks like Flutter, APIs, or databases.
Separation of Layers: Ensure that UI, business logic, and data are kept in separate layers to maintain a clean architecture.

Conclusion

Clean Code Architecture and the BLoC pattern are powerful tools that help structure your Flutter applications, ensuring they are scalable, maintainable, and testable. By implementing the principles discussed here, both beginners and experienced developers can create well-structured, high-quality applications.

The real beauty of this approach lies in its flexibility and modularity. Your UI is decoupled from business logic, and the business logic is decoupled from data sources, making it much easier to extend or refactor parts of your app as it grows.

Feel free to tweak and build upon the concepts introduced in this article. Whether you're building a small app or a large enterprise-level application, adopting Clean Architecture and BLoC will set you on the path to writing maintainable and scalable code.

Flutter Web - Firebase Hosting

Prince Tomar — Thu, 15 Aug 2024 13:15:27 +0000

This article contains steps to host Flutter Web project on Firebase Hosting.

✅ Requirements

Flutter Project which does not use .env for configurations (Firebase Hosting Limitation).
Firebase Hosting access.
Bitbucket Admin access for configuring Pipelines.
(Optional)GCP IAM & Admin (Used to create Service Account, if you want to configure CI/CD pipeline.)
Firebase CLI

📄Sections

Setup Firebase Hosting

1.Create Firebase Project & Hosting Setup
2.run command -

firebase init

, in your project directory terminal

3.After running the command Firebase asks me if I wish to proceed.
Type y and hit the enter key.

4.Next, select what features you need in my project. In this article,
hosting is all we need, I've used arrow keys to move
between the features, select hosting using the space bar key,
and then hit the enter key.

5.To use an existing Firebase project? or creating a new
firebase project? or add to an existing Google Cloud Platform
Project? or don’t set up a default project? Since I have an
existing project, I will hit the enter key.

Use the arrow key to move and hit the enter key to select a
project.
Firebase asks what we want to use as the public directory. The
default name public is in the bracket and you can type the
name of any other directory you want to use. As I have the
public directory ready, I hit the enter key.

Before deploying our website, we must ensure that if everything works as desired in our local server.

RUN -

firebase serve

Firebase Deployment

Once testing is done, we deploy our project using the deployment command and make it live for other users. RUN - `

firebase deploy
`

DEV Community: Prince Tomar

How Flutter Builds and Updates Your UI (Explained Simply)

How Flutter Builds and Updates Your UI (Explained Simply)

The Three Phases: Build, Layout, Paint

1. The Build Phase: Creating Widgets and Elements

2. The Layout Phase: Measuring and Positioning

3. The Paint Phase: Drawing Pixels

How Flutter Updates Efficiently

Debugging with This Mental Model

Example: Why ListView.builder is Faster than ListView(children: [])

When to Go Deeper (Custom Layouts and Painting)

Takeaway

What’s Next?

Building Face Detection and Emotion Recognition in Flutter Using Google ML Kit

Why Even Care About Face Detection?

🔧 Setup: What You’ll Need

Step 1: Add Dependencies

Step 2: Android & iOS Permissions

📸 Open the Camera Feed

🧠 Face Detection in Action

😄 Emotion Detection (Basic)

⚡ Where You Can Use This

🔐 Privacy Matters

🧪 Test Smart

🚀 Want to Go Beyond?

✅ Wrap-Up

Remix

Stop Letting One Bug Break Everything: Master Component Error Boundaries in Remix JS (Beginner to Pro Guide)

Prince Tomar ・ May 4

Stop Letting One Bug Break Everything: Master Component Error Boundaries in Remix JS (Beginner to Pro Guide)

How to Implement Component Error Boundaries in Remix JS: A Beginner to Advanced Guide

🔍 What is an Error Boundary?

🤕 Why Global Error Boundaries Can Hurt UX

🛠️ Component-Level Error Boundaries to the Rescue

🚀 Setting Up the Project

🧱 Introducing <ComponentErrorBoundary>

Example Usage

🎨 Custom Fallback UI

🧪 Example: Breaking the Comments Component

🔁 Replacing useFetcher with useComponentFetcher

Why?

Solution

⚙️ How useComponentFetcher Works

🔄 Updating Loaders and Actions

✅ Benefits Recap

🔍 Best Practices

⚠️ Common Pitfalls to Avoid

🌎 Real-World Scenarios

🧾 Conclusion

❓ FAQs

Role-Based Route Permissions in Remix / React Router v7

🎯 Implementing role-based access control (RBAC) in single-page applications can be challenging. This guide demonstrates how to build a comprehensive role-based navigation system in Remix that:

Project Setup

Step 1: Define Routes and Permissions

Step 2: Create Route Utilities

Step 3: Create a Navigation Store

🎯 Role-Based Route Permissions in Remix: Step-by-Step Guide

✅ Step 4: Create the Route Configuration Service

✅ Step 5: Create a Navigation Hook

✅ Step 6: Create a Secure Link Component

✅ Step 7: Create a Navigation Middleware

🧭 Step 8: Create a Root Loader with Middleware

🔐 Step 9: Create Session Utilities

🧱 Step 10: Create a Layout Component

✅ Step 11: Create Route Middleware

✅ Step 12: Implement Route Files

Login Route

✅ Step 13: Access Denied Route

✅ Step 14: Logout Route

Embracing Security Through Structure: A Complete RBAC Solution

The Journey Complete

Advantages That Scale

Architecture That Empowers

Beyond The Horizon

Ultimate guide to Flutter Keys: Optimizing Your Flutter App's Performance

Ultimate guide to Flutter Keys: Optimizing Flutter Your App's Performance

What Are Flutter Keys?

Why Are Keys Important?

Types of Keys in Flutter

1. GlobalKey

Example: Why `ListView.builder` is Faster than `ListView(children: [])`

🧱 Introducing `<ComponentErrorBoundary>`

🔁 Replacing `useFetcher` with `useComponentFetcher`

⚙️ How `useComponentFetcher` Works