Routes and layouts in Deno - Deep Dive

Overview - Routes and layouts

What is it?

Routes and layouts are ways to organize how a web application shows different pages and parts. Routes decide which page to show when you visit a certain web address. Layouts are templates that wrap pages with common parts like headers or footers. Together, they help build clear and reusable web structures.

Why it matters

Without routes and layouts, web apps would be messy and hard to manage. Every page would need to repeat the same code, and users would get lost navigating. Routes let users go to the right page easily, and layouts keep the look consistent. This saves time for developers and makes apps easier to use.

Where it fits

Before learning routes and layouts, you should know basic web development and how servers handle requests. After this, you can learn about state management and dynamic data loading to make pages interactive and personalized.

Mental Model

Core Idea

Routes map web addresses to pages, and layouts wrap pages with shared design parts to keep apps organized and consistent.

Think of it like...

Think of routes as street addresses that tell you where a house is, and layouts as the style of the neighborhood that makes all houses look like they belong together.

┌─────────────┐       ┌─────────────┐
│   Browser   │──────▶│   Router    │
└─────────────┘       └─────────────┘
                            │
                            ▼
                   ┌─────────────────┐
                   │   Layout (wrap)  │
                   └─────────────────┘
                            │
                            ▼
                   ┌─────────────────┐
                   │    Page Content  │
                   └─────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Basic Routing

Concept: Routes connect URLs to specific pages or components in a web app.

In Deno, routing means defining which code runs when a user visits a certain URL. For example, visiting '/home' shows the home page. Routes are like instructions that say: if the URL matches this path, show this page.

Result

Users see the correct page when they visit a URL.

Knowing that routes link URLs to pages helps you control what users see and when.

2

Foundation

What Are Layouts in Web Apps

Concept: Layouts provide a common structure around pages, like headers and footers.

Instead of repeating the same header or menu on every page, layouts wrap pages with these shared parts. This means you write the header once, and every page inside the layout shows it automatically.

Result

Pages share a consistent look and feel without repeating code.

Understanding layouts saves time and keeps your app design uniform.

3

Intermediate

Defining Routes in Deno Frameworks

🤔Before reading on: do you think routes in Deno are defined by file names or by code configuration? Commit to your answer.

Concept: Routes can be set up by file structure or explicit code to map URLs to handlers.

Many Deno frameworks use file-based routing, where the file path matches the URL path. For example, a file named 'about.ts' handles '/about'. Alternatively, you can define routes in code by specifying paths and functions.

Result

You can create routes by organizing files or writing route definitions.

Knowing both ways lets you choose the best method for your project style.

4

Intermediate

Creating Nested Layouts for Reuse

🤔Before reading on: do you think layouts can contain other layouts, or is there only one layout per app? Commit to your answer.

Concept: Layouts can be nested to build complex page structures with shared parts at different levels.

You can have a main layout with header and footer, and inside it, a dashboard layout with a sidebar. Pages inside the dashboard layout get both the main and dashboard layouts automatically.

Result

Your app can have layered designs that are easy to manage and update.

Understanding nested layouts helps build scalable and maintainable UI structures.

5

Advanced

Dynamic Routes and Layouts Interaction

🤔Before reading on: do you think dynamic routes can use the same layouts as static routes, or do they need special layouts? Commit to your answer.

Concept: Dynamic routes use variables in URLs and can share layouts with static routes or have their own.

For example, a route like '/user/[id]' shows user profiles dynamically. This route can use the main layout or a special user layout. You decide which layout fits best for dynamic content.

Result

Your app can handle many pages with similar structure but different data.

Knowing how dynamic routes and layouts work together lets you build flexible apps that handle many cases.

6

Expert

Optimizing Routes and Layouts for Performance

🤔Before reading on: do you think layouts always load all parts at once, or can they load pieces only when needed? Commit to your answer.

Concept: Advanced apps load layouts and routes efficiently by splitting code and loading parts only when needed.

Using techniques like lazy loading, you can load the header or sidebar only when the user visits pages that need them. This reduces initial load time and improves user experience.

Result

Your app feels faster and uses less data on first load.

Understanding performance optimization in routing and layouts is key for professional-grade apps.

Under the Hood

When a user visits a URL, the Deno server or framework matches the URL to a route handler. This handler loads the page component and wraps it with the layout components. Layouts are components that render shared UI parts and include a placeholder for the page content. The framework manages this composition and sends the final HTML or response to the browser.

Why designed this way?

This design separates concerns: routing focuses on navigation, layouts on UI consistency. It avoids repeating code and makes apps easier to maintain. File-based routing simplifies setup by using the file system as a map, while code-based routing offers flexibility. Nested layouts allow complex UI hierarchies without duplication.

User Request
   │
   ▼
┌─────────────┐
│   Router    │
│(matches URL)│
└─────┬───────┘
      │
      ▼
┌─────────────┐
│  Layout(s)  │
│(wrap pages) │
└─────┬───────┘
      │
      ▼
┌─────────────┐
│   Page      │
│ (content)   │
└─────────────┘
      │
      ▼
┌─────────────┐
│  Response   │
│  to Browser │
└─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think every page needs its own unique layout? Commit to yes or no.

Common Belief: Each page should have a completely separate layout to be unique.

Reality: Most pages share common layouts to keep design consistent and reduce repeated code.

Why it matters: Creating unique layouts for every page wastes time and makes maintenance harder.

Quick: Do you think routes must always be defined in code, not files? Commit to yes or no.

Common Belief: Routes have to be manually coded; file names don't affect routing.

Reality: Many frameworks use file-based routing where file names automatically define routes.

Why it matters: Ignoring file-based routing misses a simpler, less error-prone way to manage routes.

Quick: Do you think layouts slow down page loading because they add extra code? Commit to yes or no.

Common Belief: Layouts add unnecessary overhead and slow down the app.

Reality: Properly designed layouts improve performance by reusing code and enabling optimizations like lazy loading.

Why it matters: Avoiding layouts due to performance fears can lead to duplicated code and harder-to-optimize apps.

Quick: Do you think dynamic routes require completely different layouts than static routes? Commit to yes or no.

Common Belief: Dynamic routes must have special layouts different from static pages.

Reality: Dynamic and static routes often share layouts; layouts are about UI structure, not URL type.

Why it matters: Separating layouts unnecessarily complicates design and increases code duplication.

Expert Zone

1

Layouts can pass data and callbacks to pages, enabling shared state and interaction patterns.

2

Route matching order matters; more specific routes should be defined before generic ones to avoid conflicts.

3

Some frameworks support route groups that share layouts and middleware, improving modularity.

When NOT to use

Avoid complex nested layouts for very simple apps where a single layout suffices. For apps with highly dynamic UI, consider component-level composition instead of rigid layouts. If you need full control over routing logic, use code-based routing instead of file-based.

Production Patterns

In production, routes are organized by feature folders with nested layouts for dashboards, profiles, and public pages. Lazy loading and code splitting are used to optimize load times. Middleware is applied at route groups to handle authentication and logging.

Connections

State Management

Builds-on

Understanding routes and layouts helps organize where and how state is shared across pages and components.

Design Systems

Builds-on

Layouts enforce consistent design patterns, which are the foundation of reusable design systems.

Urban Planning

Analogy-based structural similarity

Just like routes and layouts organize a city’s streets and building styles, web routes and layouts organize navigation and UI consistency.

Common Pitfalls

#1 Repeating header and footer code on every page instead of using layouts.

Wrong approach:

export default function Page() {
return (
<>
Site Header
Page Content
Site Footer

);
}

Correct approach:

export default function Layout({ children }) {
return (
<>
Site Header
{children}
Site Footer

);
}

export default function Page() {
return Page Content;
}

Root cause:

Not understanding that layouts can wrap pages to avoid code duplication.

#2 Defining routes only in code when the framework supports file-based routing.

Wrong approach:

router.get('/about', () => renderAbout());
router.get('/contact', () => renderContact());

Correct approach:

Create files:
/pages/about.tsx
/pages/contact.tsx
Framework auto-maps these to '/about' and '/contact'.

Root cause:

Ignoring simpler file-based routing conventions leads to extra manual work.

#3 Loading all layout parts immediately, causing slow page loads.

Wrong approach:

import Sidebar from './Sidebar';

export default function Layout({ children }) {
return (
<>

{children}

);
}

Correct approach:

import { lazy } from 'react';
const Sidebar = lazy(() => import('./Sidebar'));

export default function Layout({ children }) {
return (
<>

{children}

);
}

Root cause:

Not using lazy loading to optimize performance.

Key Takeaways

Routes connect URLs to the right pages, guiding users through your app.

Layouts wrap pages with shared UI parts, keeping design consistent and code DRY.

File-based routing simplifies route setup by matching files to URLs automatically.

Nested layouts let you build complex, reusable page structures efficiently.

Optimizing routes and layouts with lazy loading improves app speed and user experience.

Practice

1. What is the main purpose of routes in a Deno web application?

easy

A. To store user data in a database

B. To style the application with CSS

C. To connect URLs to specific content or pages

D. To handle server hardware settings

Solution

1. Step 1: Understand what routes do

   Routes link a URL path to the content or page that should show when that URL is visited.

2. Step 2: Compare options to this definition

   Only To connect URLs to specific content or pages describes connecting URLs to content, which matches the purpose of routes.

3. Final Answer:

   To connect URLs to specific content or pages -> Option C

4. Quick Check:

   Routes = URL to content connection [OK]

Hint: Routes map URLs to pages or content [OK]

Common Mistakes:

• Confusing routes with styling or database tasks
• Thinking routes manage server hardware
• Mixing routes with layout responsibilities

2. Which of the following is the correct way to define a route handler in a Deno Oak application?

easy

A. router.route('/home', function() { return 'Home'; });

B. router.get('/home', (ctx) => { ctx.response.body = 'Home'; });

C. router.add('/home', (req, res) => res.send('Home'));

D. router.handle('/home', () => { print('Home'); });

Solution

1. Step 1: Recall Oak router syntax

   In Oak, routes are defined using methods like router.get(path, handler).

2. Step 2: Check each option's syntax

   router.get('/home', (ctx) => { ctx.response.body = 'Home'; }); uses router.get with a context parameter and sets ctx.response.body, which is correct Oak syntax.

3. Final Answer:

   router.get('/home', (ctx) => { ctx.response.body = 'Home'; }); -> Option B

4. Quick Check:

   Oak route syntax = router.get(path, ctx) [OK]

Hint: Use router.get with ctx and set ctx.response.body [OK]

Common Mistakes:

• Using non-existent router methods like add or handle
• Not setting ctx.response.body for response
• Confusing callback parameters with Express.js style

3. Given this Deno Oak route and layout setup, what will be the output when visiting '/about'?

const router = new Router();
router.get('/about', (ctx) => { ctx.response.body = 'About Page'; });

const layout = (content) => `
Header
${content}
Footer
`;

// Middleware to wrap response
app.use(async (ctx, next) => {
  await next();
  ctx.response.body = layout(ctx.response.body);
});

app.use(router.routes());
app.use(router.allowedMethods());

medium

A. HeaderAbout PageFooter

B. About Page

C. HeaderFooter

D. Error: layout function not applied

Solution

1. Step 1: Understand route response

   The route sets ctx.response.body to 'About Page' when '/about' is visited.

2. Step 2: Understand middleware wrapping

   The middleware runs after the route, wrapping the body with header and footer HTML using the layout function.

3. Final Answer:

   <header>Header</header>About Page<footer>Footer</footer> -> Option A

4. Quick Check:

   Middleware wraps route output with layout [OK]

Hint: Middleware modifies response after route sets it [OK]

Common Mistakes:

• Ignoring middleware wrapping
• Assuming route output is unchanged
• Confusing order of middleware and routes

4. Identify the error in this Deno Oak route and layout code snippet:

const router = new Router();
router.get('/contact', (ctx) => {
  ctx.response.body = 'Contact Page';
});

const layout = (content) => `
Header
${content}
Footer
`;

app.use(router.routes());
app.use(router.allowedMethods());

app.use(async (ctx, next) => {
  await next();
  ctx.response.body = layout(ctx.response.body);
});

medium

A. router.allowedMethods() is missing

B. Middleware wrapping layout runs after routes, so layout is applied too late

C. ctx.response.body is not set in route handler

D. Middleware wrapping layout runs after routes, so layout is not applied

Solution

1. Step 1: Analyze middleware order

   router.routes() and router.allowedMethods() are registered before the layout middleware.

2. Step 2: Recall route handler behavior in Oak

   When router.routes() matches a route, it executes the handler. The handler sets the response body but does not call next(), terminating the middleware chain at that point.

3. Step 3: Determine layout application

   Subsequent middleware, including the layout wrapper, are never reached for matched routes. Thus, the layout is not applied.

4. Final Answer:

   Middleware wrapping layout runs after routes, so layout is not applied -> Option D

5. Quick Check:

   Middleware after router.routes() skipped on match [OK]

Hint: Layout middleware must precede router.routes() [OK]

Common Mistakes:

• Placing layout middleware after routes
• Forgetting to set ctx.response.body in route
• Misunderstanding middleware execution order

5. You want to create a Deno Oak app with a layout that adds a header and footer to all pages, but only for routes under '/app'. Which approach correctly applies the layout only to those routes?

hard

A. Use a middleware that checks if ctx.request.url.pathname starts with '/app' and wraps response body with layout only then

B. Apply the layout middleware globally to all routes without condition

C. Add the header and footer HTML directly inside each route handler under '/app'

D. Use router.allowedMethods() to apply layout only to '/app' routes

Solution

1. Step 1: Understand the requirement

   The layout should wrap only routes under '/app', not all routes.

2. Step 2: Evaluate each option

   Use a middleware that checks if ctx.request.url.pathname starts with '/app' and wraps response body with layout only then uses middleware that checks the URL path and applies layout conditionally, which is correct and efficient.

3. Step 3: Why other options fail

   Apply the layout middleware globally to all routes without condition applies layout to all routes, ignoring the condition. Add the header and footer HTML directly inside each route handler under '/app' duplicates layout code in every route, which is not DRY. Use router.allowedMethods() to apply layout only to '/app' routes misuses router.allowedMethods(), which only handles HTTP method responses.

4. Final Answer:

   Use a middleware that checks if ctx.request.url.pathname starts with '/app' and wraps response body with layout only then -> Option A

5. Quick Check:

   Conditional middleware applies layout selectively [OK]

Hint: Check URL path in middleware to apply layout selectively [OK]

Common Mistakes:

• Applying layout middleware globally without condition
• Repeating layout code in each route
• Misusing router.allowedMethods() for layout