DEV Community: Kenneth Angelo Reyes

Dynamic Component Rendering in React

Kenneth Angelo Reyes — Tue, 26 Oct 2021 18:38:26 +0000

When defining application components, a good strategy is to split by functionality.

In a blogging application, we'll have a component to represent the WYSIWYG editor then, another to hold the publish settings. In this particular example, the publish settings component is pretty static. Meaning, it will always have the same fields and behavior.

But, what if the publish settings contents vary dynamically? A good example of this can be found in Photoshop. In this case, depending on the tool selected, the Property Panel will be rendered differently.

This is where dynamic component rendering comes in. When a tool is selected, Photoshop will intelligently determine what will be rendered on the property pane.

In this post, let's explore how to implement dynamic component rendering in React.

Let's go!

The Design

In this section, we'll talk about what makes up a dynamic component rendering implementation.

There are 3 items we need to prepare:

Configuration - In its most basic form, the configuration is simply a mapping between a condition and a component.
Dynamic Components - Of course, we'd need to have the components that will actually be dynamically rendered.
Dynamic Render Function - This is the function that will actually perform the decision of which component to render.

Next, we'll look at dynamic component rendering in action.

The Implementation

For our example, we'll look at a Property Editor component whose contents can be dynamically changed based on user selection.

We'll configure each of the 3 items mentioned in the previous section. Let's start.

Configuration

For the configuration, we'll implement a basic mapping between a key and a functional component to represent that key:

const Config = {
  assign: AssignPropertyEditor,
  log: LogPropertyEditor
}

Based on this configuration, our dynamic component renderer will have 2 different components to choose from.

Dynamic Components

For the dynamic components, we implement them as if they're normal components.

The AssignPropertyEditor component looks like this:

const AssignPropertyEditor = ({ codeData, updateData }) => {
    const type = codeData.type;
    const localData = codeData.data;

    if (type === "assign") {
        const onVariableChange = (event) => {
            localData.variable = event.target.value;

            updateData(localData);
        };

        const onValueChange = (event) => {
            localData.value = event.target.value;

            updateData(localData);
        };

        return (
            <div>
                <strong>Assign:</strong><br/>
                <input name="assign_var" type="text" defaultValue={localData.variable} placeholder="Variable" onChange={onVariableChange} />
                &nbsp;=&nbsp;
                <input name="assign_val" type="text" defaultValue={localData.value} placeholder="Value" onChange={onValueChange} />
            </div>
        );
    } 

    return null;
};

While the LogPropertyEditor looks like this:

const LogPropertyEditor = ({ codeData, updateData }) => {
    const type = codeData.type;
    const localData = codeData.data;

    if (type === "log") {
        const onMessageChange = (event) => {
            localData.message = event.target.value;

            updateData(localData);
        };

        return (
            <div>
                <strong>Log:</strong><br />
                <input name="log_message" type="text" defaultValue={localData.message} placeholder="Message" onChange={onMessageChange} />
            </div>
        );
    }

    return null;
};

The only pattern we need to be aware of is that both components should receive the same set of properties. Of course, they should use these properties in the same way.

In our example, the codeData will hold the data for each component. Then, the updateData property is a callback function which the dynamic components will execute when their respective data has changed.

Dynamic Render Function

For better context, we'll show the render function as included in its entire component:

function App() {
  const [activeData, setActiveData] = useState();

  const onUpdateCodeData = (data) => {
    // react to data update from dynamic components
  };

  const renderPropertyEditor = () => {
    if (activeData && activeData.type !== null && Config[activeData.type]) {
      const PropertyEditor = Config[activeData.type];
      return (<PropertyEditor codeData={activeData} updateData={onUpdateCodeData} />);
    } else {
      return (<em>Select an element type to display.</em>);
    }
  };

  const onDisplayAssignEditor = () => {
    setActiveData({ type: "assign", data: { variable: "a", value: "100" } });
  };

  const onDisplayLogEditor = () => {
    setActiveData({ type: "log", data: { message: "hello world!" } });
  };

  return (
    <div>
      <div>
        <h1>Toolbox</h1>
        <ul>
          <li><button onClick={onDisplayAssignEditor}>Update to ASSIGN</button></li>
          <li><button onClick={onDisplayLogEditor}>Update to LOG</button></li>
        </ul>
      </div>
      <div>
        <h1>Property Editor</h1>
        {renderPropertyEditor()}
      </div>
    </div >
  );
}

The dynamic render function is the renderPropertyEditor function. It uses the activeData variable to determine which component to render.

The key code in this function is:

const PropertyEditor = Config[activeData.type];
return (<PropertyEditor codeData={activeData} updateData={onUpdateCodeData} />);

In this section of the code, we literally treat the functional component passed in the configuration as a stand-alone component named PropertyEditor. Whatever component the activeData.type value maps to, will be the one receiving the activeData and onUpdateCodeData properties. This will also be the same component to be rendered.

A More Realistic Example

For a more real-world example, you can check out Speed Build. It's a simple low-code app builder created using React and ReactFlow. Speed Build's code can be found here.

The parent component and the render function can be found at src/Editor/Canvas.js. Additionally, all the dynamic property components are located at the src/PropertyPanel directory.

For more similar projects that can help you learn software/web development, you can check out my DevPinch initiative.

Conclusion

So, that's it! We've implemented dynamic component rendering in react!

Here's a quick demo:

Glad that you've reached the end of this post. Let me know what you think of this approach by sending in your comments.

I hoped you learned something new from me today!

Hey, you! Follow me on Twitter!

Feature Management in ReactJS

Kenneth Angelo Reyes — Mon, 11 Oct 2021 10:04:46 +0000

In this post, I'll show you how to implement feature management on your React applications. Feature management is the way to control which features are available based on certain scenarios.

Why Do Feature Management?

Here are some scenarios where controlling feature availability is necessary:

The feature should only be turned on after a marketing event. With feature flags, the feature can already be sitting in production and an administrator can just simply enable it via configuration once the event is done.
The feature should only be available to users on a specific plan.

All of these scenarios share the same concept. In this post, we'll focus on the 2nd one. Let's go!

The Requirements

Let's say we're building a blog application that offers the ff. features:

Updating Title and Content
Publishing to multiple blog platforms
Scheduling the publish time

Now, let's say the app offers 3 plans to users: Basic, Pro, and, Ultimate.

With these plans, the team has decided to have a plan comparison table that looks like this:

Feature	Basic	Pro	Ultimate
Update Title and Content	Yes	Yes	Yes
Schedule the publish time	No	Yes	Yes
Publish to multiple blog platforms	No	No	Yes

We now have all the requirements defined. Let's start building!

The Starting Point

For your reference, the initial state of the project can be found here.

For simplicity, we only have the New Blog page in this version.

The page contains the following:

A Role Switcher to simulate changing of the plans
All the features are still available to the user

Here's how it looks like at this point:

The Role Switcher

Here's a look at the RoleSwitcher component:

function RoleSwitcher({ plans, activePlan, setActivePlan }) {
    const navItemTags = () =>
        plans.map((label, index) =>
            <li className="nav-item" key={index}>
                <button className={"nav-link" + (activePlan === index ? " active" : "")} onClick={e => setActivePlan(index)}>{label}</button>
            </li>
        );

    return (
        <ul className="nav nav-pills">
            {navItemTags()}
        </ul>
    );
};

The component receives 3 properties which are passed by the App component.

function App() {
  const availablePlans = Config.availablePlans;
  const [activePlan, setActivePlan] = useState(0);

  <RoleSwitcher 
    plans={availablePlans} activePlan={activePlan} 
    setActivePlan={setActivePlan} />

The App component then refers to the availablePlans exposed by Config.js

const Config = {
    availablePlans: ['Basic', 'Pro', 'Ultimate']
};

The RoleSwitcher displays all the available plans and allows the user to set the activePlan. The activePlan variable will then be passed to the Editor component later on.

The Feature-Based Approach

Now, let's update the other features to only be shown on the appropriate plan.

In this approach, we let the plans identify the features that are going to be available in them.

Therefore, we need to make changes to the Config file:

const Config = {
    availablePlans: [
        {
            id: 0,
            name: 'Basic',
            features: []
        },
        {
            id: 1,
            name: 'Pro',
            features: ['scheduledPost']
        },
        {
            id: 2,
            name: 'Ultimate',
            features: ['scheduledPost', 'multiplePublishers']
        }
    ]
};

In the above change, each plan inside the availablePlans array now has a list of features that are available in them.

Then, let's update the RoleSwitcher to support this new format:

function RoleSwitcher({ plans, activePlan, setActivePlan }) {
    const navItemTags = () =>
        plans.map((plan) =>
            <li className="nav-item" key={plan.id}>
                <button 
                    className={"nav-link" + (activePlan.id === plan.id ? " active" : "")} 
                    onClick={e => setActivePlan(plan)}>{plan.name}</button>
            </li>
        );

    return (
        <ul className="nav nav-pills">
            {navItemTags()}
        </ul>
    );
};

The initialization section of the App component also needs to be updated:

const availablePlans = Config.availablePlans;
const [activePlan, setActivePlan] = useState(availablePlans[0]);

And now, for the star of this post, let's talk about the FeatureBlock component!

The Feature Block Component

function FeatureBlock(props) {
    const isFeatureVisible = props.activePlan.features
        .find(feature => feature === props.featureName);

    if (isFeatureVisible) {
        return (
                <>
                    {props.children}
                </>
            );
    } else {
        return null;
    }
};

The FeatureBlock component is a wrapper component and receives the following:

The activePlan property to determine the selected plan
The featureName property to which will be matched against the features list of the activePlan property. If a match is found, the FeatureBlock's children will be rendered.
The component's children which are conditionally rendered based on the above 2 properties

For simplicity, we'll only use the FeatureBlock component to wrap the publisher and scheduled inputs in the Editor component. This is because the title and content fields are available to all plans anyway.

The Editor component will now have this structure:

function Editor({ activePlan }) {
    return (
        <div className="col col-12">
            <h1>New Post</h1>
            <!--Title and content fields here-->
            <FeatureBlock activePlan={activePlan} 
                featureName="multiplePublishers">
                <!--The publishers selection here-->
            </FeatureBlock>
            <FeatureBlock activePlan={activePlan} 
                featureName="scheduledPost">
                <!--The schedule input here-->
            </FeatureBlock>
            <!--Save and submit buttons here-->
    );
}

After all these changes, the RoleSwitcher will now toggle the visibility of the publisher and schedule inputs.

As you can see, everything is functioning as expected. But, there's a problem with the Config file.

It's too centralized! Once the app grows, the Config file has the potential to be bloated. Let's solve this in the next section.

By the way, here's the code at this point.

The Plan-Based Approach

To solve the problem with the Config file, we should follow a plan-based approach.

In this approach, we're inverting the dependency. Instead of letting the plan define the features available, we let the features specify which plans they should be available on. This is a more modular and cleaner approach.

The Editor component will now have this structure:

function Editor({ activePlan }) {
    return (
        <div className="col col-12">
            <h1>New Post</h1>
            <!--Title and content fields here-->
            <FeatureBlock activePlan={activePlan} 
                planNames={["Ultimate"]}>
                <!--The publishers selection here-->
            </FeatureBlock>
            <FeatureBlock activePlan={activePlan} 
                planNames={["Pro", "Ultimate"]}>
                <!--The schedule input here-->
            </FeatureBlock>
            <!--Save and submit buttons here-->
    );
}

The FeatureBlock will also be updated to support this change:

function FeatureBlock(props) {
    const isFeatureVisible = props.planNames.find(plan =>
        plan === props.activePlan.name);

    if (isFeatureVisible) {
        return (
            <>
                {props.children}
            </>
        );
    } else {
        return null;
    }
};

Now that the Config will not be responsible for storing the plan-to-feature mappings anymore, it can already be simplified to:

const Config = {
    availablePlans: [
        {
            id: 0,
            name: 'Basic'
        },
        {
            id: 1,
            name: 'Pro'
        },
        {
            id: 2,
            name: 'Ultimate'
        }
    ]
};

Here's the code at this point.

In Summary

We've successfully implemented Feature Management in React!

What I've provided is simply a skeletal reference. You can expand it further to support more advanced requirements.

In my case, I was thinking to implement user-specific feature availability. In this scenario, specific features can only be available to users who pass certain conditions.

For example, what if only want to make the scheduled publishing feature available to users from a certain location? We'll explore this in my next article which I'll upload in the next few days!

Glad that you've reached the end of this post. Let me know what you think of this approach by sending in your comments.

I hoped you learned something new from me today!

Hey, you! Follow me on Twitter!

Building an API using Express and MongoDB

Kenneth Angelo Reyes — Fri, 01 Oct 2021 18:57:36 +0000

In this post, we'll go through the process of creating an API built using Express and MongoDB.

We'll cover the ff. steps:

Setting up MongoDB
Creating an Express application
Optimizing your Express routes
Handling errors

Let's start!

Setting up MongoDB

In this section, we'll go through creating and configuring a remote MongoDB instance.

Using a MongoDB instance hosted on the cloud

Instead of installing a local MongoDB instance, we'll use Atlas which is MongoDB's official database-as-a-service.

Create a MongoDB Atlas account here.
Create a cluster. For new accounts, you can use the forever free tier!
Create the super admin user.

Managing your databases using Compass

To better visualize our data, we'll be using the official GUI for MongoDB, Compass.

Download the latest Compass version here.
Install the thing!
Get the database connection string from Atlas.
1. Access your Atlas dashboard. Then, on your cluster panel, click the Connect button.
2. On the Connect popup, create your super admin user.
3. Then, for the Connection Method, choose Connect using MongoDB Compass.
4. Then, choose the latest Compass version and then copy the connection string.
5. Replace the credentials in the connection string with your actual credentials.
6. Keep the connection string somewhere safe so you can use it in the next steps.
Launch Compass, key in your connection string, then, click Connect.
Once connected, you can now click on the Create Database button.
Specify the database name and the first collection's name. Then, click the Create Database button on the popup.
1. For this example, I created a database named audit-log-demo and a collection named user-profile.
You should now see audit-log-demo as part of the database list.
Now, let's add test data to our database.
1. Click on the audit-log-demo database. You will be directed to the collection list page.
2. Click on the user-profile collection. You will be directed to the collection management page.
3. Under the Documents tab, click on the Add Data > Insert Document button.
4. In the Insert to Collection popup, paste the following properties just below the _id property:
```
"firstName": "Tony",
"lastName": "Stark",
"age": 25   
```

Creating an Express application

In this section, let's go through the step-by-step process of creating an Express application and letting this application establish a connection to our new MongoDB instance.

Setting up

Open your favorite CLI and navigate to your desired working directory.
Create a new package using npm init. Follow the prompts and provide the necessary details.
Install both express and the mongodb driver by executing npm install mongodb express --save
Get the database's connection string from Atlas.
1. Access your Atlas dashboard. Then, on your cluster panel, click the Connect button.
2. Then, for the Connection Method, choose Connect your application.
3. Then, choose the appropriate NodeJS version and then copy the connection string.
4. Replace the credentials in the connection string with your actual credentials.
5. Keep the connection string somewhere safe so you can use it in the next steps.
Create a new environment setting with key ALD_CONN_STRING and set its value to your connection string.

Connecting to the database

At the root of your working directory, create an index.js file with this content:

const { MongoClient, ObjectId } = require('mongodb');
const express = require('express');

const mongoConnString = process.env.ALD_CONN_STRING;
const mongoClient = new MongoClient(mongoConnString);

const expressApp = express();
const expressPort = 3000;

expressApp.get('/profile', async (req, res, next) => {
    try {
        await mongoClient.connect();

        const db = mongoClient.db('audit-log-demo');
        const col = db.collection('user-profile');

        const profileList = await col.find({}).toArray();

        res.send({
            data: profileList
        });
    } catch (err) {
        next(err);
    }
    finally {
        await mongoClient.close();
    }
});

expressApp.listen(expressPort, () => {
    console.log(`Example app listening at http://localhost:${expressPort}`)
});

In the above code, we used the ALD_CONN_STRING environment variable to retrieve the connection string. Then, we instantiated the MongoDB and Express clients. We also introduced one route (/profiles) which retrieves all the documents in the user-profile collection.

Run your application by executing node index.js on your CLI.

Then, using your favorite REST client (I'm using Postman), access the /profiles endpoint of your API. You should get this result:

{
    "data": [
        {
            "_id": "<GUID>",
            "firstName": "Tony",
            "lastName": "Stark",
            "age": 25
        }
    ]
}

Adding a new route

To further expand the capabilities of the API, we add a new route to get a specific profile by ID.

To do this, we just need to add the following code to your index.js file just before the listen call:

expressApp.get('/profile/:id', async (req, res, next) => {
    try {
        await mongoClient.connect();

        const db = mongoClient.db('audit-log-demo');
        const col = db.collection('user-profile');

        const profile = await col.findOne({ _id: ObjectId(req.params.id) });

        res.send({
            data: profile
        });
    } catch (err) {
        next(err);
    }
    finally {
        await mongoClient.close();
    }
});

Checkpoint

You can check out the index.js code at this point by clicking here.

Optimizing your Express routes

At this stage, the 2 routes we created are as follows:

expressApp.get('/profiles', async (req, res, next) => {
    try {
        await mongoClient.connect();

        const db = mongoClient.db('audit-log-demo');
        const col = db.collection('user-profile');

        const profileList = await col.find({}).toArray();

        res.send({
            data: profileList
        });
    } catch (err) {
        next(err);
    }
    finally {
        await mongoClient.close();
    }
});

expressApp.get('/profile/:id', async (req, res, next) => {
    try {
        await mongoClient.connect();

        const db = mongoClient.db('audit-log-demo');
        const col = db.collection('user-profile');

        const profile = await col.findOne({ _id: ObjectId(req.params.id) });

        res.send({
            data: profile
        });
    } catch (err) {
        next(err);
    }
    finally {
        await mongoClient.close();
    }
});

The above code works, but, there's one major point of improvement in them:

In both routes, the parts that connect to the database and retrieve a reference to the collection are repeated. We should always follow the DRY (Don't Repeat Yourself) principle!

So how should we go about this? We introduce middleware to the code!

What's a middleware?

In Express, a middleware is a function that can be executed before or after the actual request handlers.

For our example, we need to define 2 middleware functions:

A middleware that establishes the connection to the database and will then pass this connection instance to the request handlers.
A middleware that closes the connection to the database. This middleware function will be executed after the request handlers.

Let's add in the middleware functions

Here's the code for the 2 middleware functions:

async function dbConnBeforeware(req, res, next) {
    const mongoConnString = process.env.ALD_CONN_STRING;
    const mongoClient = new MongoClient(mongoConnString);

    await mongoClient.connect();
    console.log("Database connection established!");

    req.dbClient = mongoClient;
    req.dbDatabaseRef = mongoClient.db('audit-log-demo');

    next();
}

async function dbConnAfterware(req, res, next) {
    await req.dbClient.close();

    console.log("Database connection closed!");

    next();
}

To use them, we need to adjust the way the routes are defined to:

async function getAllProfilesHandler(req, res, next) {
    try {
        const col = req.dbDatabaseRef.collection('user-profile');

        const profileList = await col.find({}).toArray();

        res.send({
            data: profileList
        });

        next();
    } catch (err) {
        next(err);
    }
}

async function getProfileByIdHandler(req, res, next) {
    try {
        const col = req.dbDatabaseRef.collection('user-profile');

        const profile = await col.findOne({ _id: ObjectId(req.params.id) });

        res.send({
            data: profile
        });

        next();
    } catch (err) {
        next(err);
    }
}

// For readability, we also created 2 new separate functions for the actual request handlers
expressApp.get('/profiles', dbConnBeforeware, getAllProfilesHandler, dbConnAfterware);
expressApp.get('/profile/:id', dbConnBeforeware, getProfileByIdHandler, dbConnAfterware);

Checkpoint

You can check out the index.js code at this point by clicking here.

Handling errors

Another point of improvement with the current code is error handling.

If something goes wrong in the request handlers, the default Express error handler will be triggered. But, this default error handler does not close the database connection established.

To fix this, we introduce our very own error handler by adding this code after the route definition section:

expressApp.use(async function (err, req, res, next) {
    if (req.dbClient) {
        await req.dbClient.close();
        console.log("Database connection closed!");
    }

    console.error(err.stack);
    res.status(500).send('Something broke!');
});

In this custom error handler, we close the connection if any, and then log the error to the console. Lastly, we inform the API consumer that something went wrong.

Now, when an error occurs, you should get this response (Postman screenshot):

Checkpoint

You can check out the index.js code at this point by clicking here.

At this point, I added a forced error to the getProfileByIdHandler handler to simulate an error happening.

To view the version of the code without any of the forced errors, click here.

In Summary

We've successfully created an API built on Express and MongoDB!

Additionally, we've also gone through 2 rounds of code optimizations:

Middleware usage - for reducing code redundancy
Custom error handling - for ensuring the database connection is closed even when issues occur

I think there are still a couple of improvements on this:

Once your API grows, you should split the route definitions into multiple code files.
The dbConnBeforeware can also be made configurable so you can use it for other routes that handle data from another collection.

What other improvements do you have in mind? And what do you think of this approach? Let me know your thoughts in the comments

Glad that you've reached the end of this post. I hoped you learned something new from me today.

Hey, you! Follow me on Twitter!

A Quick Look: The Software Architecture of Common Web App Features

Kenneth Angelo Reyes — Wed, 29 Sep 2021 08:28:33 +0000

In this post, I'll walk you through how to implement some of the most common web application features.

For each feature, we'll show the ff. three details:

A real-world example as well as a description of the main challenges for the feature
A list of components used in the feature
Component diagram

Note though that the component list and diagram are not representative of how the real-world examples I provided were actually implemented.

Lastly, the components mentioned here will be abstractions and will therefore not be attached to any specific services/platforms. This will be more of a conceptual overview.

With all of that out of the way, let's start diving in!

Reporting

The idea of a reporting feature is to display summarized and useful information to users. In most cases, reporting features deal with tons of data. In the above screenshot from Google Analytics, all the data received from websites are summarized and presented using various graphs.

The primary challenge for a reporting feature is ensuring that the summarized data loads quickly. Therefore, the process of summarizing data should be done by a different process separate from the frontend. The frontend's job is to retrieve the summarized data. Nothing more.

Component Breakdown

Data Ingestor. This component receives all the data from all possible sources.
Data Transformer. The raw data is then transformed by a separate process.
Reporting Database. Once the data is transformed, it will then be stored in a separate reporting table/cache. This reporting table/cache will then be accessed directly by the frontend.

Component Diagram

Search

For sites with high data volume, providing a search feature is crucial. Search pages should be able to provide results quickly. For more complicated sites, search results are not just ranked by text matching but also by determining search keyword relevance as well.

To achieve this, the searchable items should be indexed beforehand.

Component Breakdown

Search Index.
Middle Man. This is the one responsible for interacting with the search index and sending over the search results to the frontend. Paginating and counting over the results should be done by this component as well.
Cache. For apps with a really large amount of data, the search results are even cached.

Component Diagram

Social Feed

A social feed basically shows a list of items relevant to a user, like text or image posts. The relevancy is usually based on two factors:

The closeness of the post author to the user
The amount of interest the user has in the post's topic

To achieve this, feeds should be pre-calculated. Meaning, a separate and ongoing process will determine the posts that will make up a user's feed. This way, the feed items are prepared before the user even visits his/her feed page.

Component Breakdown

User Database. Will house all the users and their relationships.
Post Database. Will house all the posts created by users. This database should also contain the post's topics as determined by the system.
Feed Generator. The one responsible for determining and compiling the posts relevant to a user. The compiled posts will then be generated as "feed items" and will be stored in a feed database.

Component Diagram

Images

Images are not technically a full-blown feature but they should be handled properly to deliver a better user experience.

For example, a user can upload a high-definition image (20MB) and, if there's no post-processing done on this original image, showing it on galleries will be a performance concern. Imagine serving a 20MB file to 1,000 users every minute. I won't do that math, but, that's not really ideal.

Component Breakdown

Image Processor. This will transform the original image into multiple versions (in different sizes) depending on what's needed by the frontend.

Component Diagram

In this diagram, it is assumed that the images are displayed on a gallery page showing the small version. Then, on a details page which shows a medium version of the image.

And now, the end is near...

I hoped you enjoyed reading this article and learned something new from me. I'd be happy to hear your thoughts so be sure to comment down below.

Credits

Social Feed sample photo by dole777 from Unsplash.

Hey, you! Follow me on Twitter!

How To Break Down User Stories Into Smaller Tasks

Kenneth Angelo Reyes — Tue, 28 Sep 2021 09:20:16 +0000

In this post, I'll talk about my strategy for breaking down user stories into smaller tasks.

What's a User Story?

Before we start, let's define what user stories are. A user story is an informal, natural language description of a software system feature.

One of the common formats used for creating a user story is this:

As a <user with this role>, I should be able to <perform this action> to <achieve this goal>.

Let's look at a real-world example for a blog application:

As a content editor, I should be able to create a draft to work on an article over some time.

Why Do I Need To Define Smaller Tasks?

In my experience, breaking down user stories into smaller tasks can help identify common tasks that were originally spread out across multiple user stories.

Remember, user stories are closer to business requirements and not technical ones.

Here's a good example. Let's say that there are a couple of user stories defined to confirm with a user before proceeding with an action. When we break these user stories down, we'll discover that there's a need for a confirmation popup. Since this is a reusable component, we can better plan who will implement it and when will it be implemented.

Essentially, breaking down user stories into smaller tasks allow devs to:

Better plan their tasks, therefore, allowing them to provide more accurate estimates
Have a better bug-fixing experience since issues can be mapped to each specific task instead of the larger-scoped user story
Reduce duplicate work (as described in the confirmation popup scenario above)

Let's Break It Down

Now, let's work on the real-world example I gave earlier.

When breaking down a user story, I first think of the following categories:

Security
Pre-conditions
Action

Each category can either have one or multiple tasks. Let's discuss in detail in each of their respective sections.

Security

The most important category and is even the first part of the user story. In this category, we'll answer the question:

Who is allowed to perform the action?

The example user story is only targeted at content editors. Therefore, we need to ensure that.

Since the user story is simple enough, I'll only add one task under this category:

Check that the user should have a Content Editor role.

For more complicated systems, another consideration can be delegation. If a content editor went on leave and has assigned his/her backup editor, the check for this can be another task as well.

Also, the reason why I define the security-related tasks first is that it is going to be used by all the subsequent tasks. This means, that it will be the first task I do and will be implemented as a common/reusable component.

Pre-conditions

The tasks under this category should answer this question:

What needs to be done before the user can perform the action?

Note that these actions should only be performed after the security checks.

For our example user story, the ff. tasks can be added as part of this category:

Check that the user already has a blog. If not, ask the user to create a blog first.

In some cases, the smaller tasks here might get attached to another user story.

For example, instead of "asking to create a blog", we may link to a "getting started" feature that was defined by a different user story.

That doesn't mean we don't need to ensure these conditions are met first. These checks are still part of the user story.

Action

Now, on to the main requirement. In this category, we answer this question:

How can we enable the action for the user?

Additionally, we should also include validation tasks under this category.

In our case, we'll add the ff. tasks under this category:

Add a New Draft button to the main navigation.
Once the New Draft button is clicked, display the main WYSIWYG editor.
Add a Save button to the WYSIWYG editor.
Once the Save button is clicked, if there's content in the editor, we create a new draft record and navigate to the draft listing page.
Once the Save button is clicked, if the editor is empty, we navigate away from the editor.

In the above tasks, everything about the WYSIWYG editor is out of scope. The kind of editor plugin or the other behaviors that should be available in it should all be considered in a separate user story. We just assume that the editor is available for integration.

In Summary

We've reached the end! That one-liner user story has been broken down into 7 smaller tasks.

Just for a quick recap, here are the tasks:

Category	Task Description
Security	Check that the user should have a Content Editor role.
Pre-conditions	Check that the user already has a blog. If not, ask the user to create a blog first.
Action	Add a New Draft button to the main navigation.
Action	Once the New Draft button is clicked, display the main WYSIWYG editor.
Action	Add a Save button to the WYSIWYG editor.
Action	Once the Save button is clicked, if there's content in the editor, we create a new draft record and navigate to the draft listing page.
Action	Once the Save button is clicked, if the editor is empty, we navigate away from the editor.

Again, breaking down user stories into smaller tasks enables better task planning and management. It is a necessary step for devs.

Also, there are other approaches to doing this. If you happen to know one, I'd love to hear from you so, share your thoughts in the comments below!

Hey, you! Follow me on Twitter!

Modular Routing in React

Kenneth Angelo Reyes — Mon, 27 Sep 2021 15:48:01 +0000

In a React + React Router environment, routing configuration is a one-to-one mapping between a route and that route's display elements.

Here's a basic example:

<Route exact path='/' component={Home} />
<Route exact path='/drafts' component={DraftListing} />
<Route path='/drafts/:draftId' component={DraftUpdate} />

The above approach is suitable for simple applications, but, for complex ones, it's not really ideal.

Complex applications are usually composed of several modules. Each module is then composed of several components. If this is the application's structure, it is just reasonable for the routing model to follow the same structure, right?

Well, that's just what we're going to do! In this post, let's look at implementing modular routing in React.

We're doing this in 3 steps:

Setup a theoretical application and identify its modules and components
Implement a regular routing model for the said application
Transform the regular routing model into a modular one

Let's start!

The Application, the Modules, and the Components

Let's say we're building a blog-writing application and we have decided to implement the ff. modules:

Post Management
Draft Management

Given the above modules, we'll probably design the routing map like this:

Module	Route
Post Management	/posts
Draft Management	/drafts

Looking at the above routings, it seems like we're only going to have 3 components directly representing each of our main modules. But, we all know that these modules are still going to be composed of one or more components.

In fact, we can even argue that these modules are "smaller applications" themselves. For instance, Post Management should also have a route navigating to the Update Post component. Draft Management should have this behavior as well (navigate to the Update Draft component).

So, what do we do now? We "push up" the concept of modules and identify the actual components of the application.

Here's the new routing map but with an added Component column.

Module	Component	Route
Post Management	Post Listing	/posts
	Update Post	/posts/:postId
Draft Management	Draft Listing	/drafts
	Update Draft	/drafts/:draftId

The Regular Routing Approach

Now, we have identified the modules and components for our application. Let's go ahead and implement them!

Create A New React App First

Of course, the first step is to create a brand new React application.

npx create-react-app reactjs-module-based-routing
cd reactjs-module-based-routing

Then, we'll install the React Router for Web Applications library since we're building a web application.

npm install --save react-router-dom

For simplicity, we remove all of the other files under the /src directory.

Then, we create a new index.js file:

import React from 'react';
import ReactDOM from 'react-dom';

import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

And a new App.js as well:

function App() {
  return (
    <div>

    </div>
  );
}

export default App;

Check out the code at this point here.

Create The Components

For better maintainability, the components should be grouped by their module. So, we'll have one directory per module and each of these directories will only contain the components relevant to their respective module.

Just to recap, we'll need to create the components:

Draft Listing
Draft Update
Post Listing
Post Update

Lastly, we'll need to create a Home component as well just so we can render a homepage.

For the Draft and Post Update components, we will use the useParams function from react-router-dom to get the draft or post ID passed in the URL.

Here's how the Draft Update component looks like:

import { useParams } from 'react-router-dom';

function DraftUpdate() {
    let { draftId } = useParams();

    return (
        <h1>This is Draft Update: {draftId}</h1>
    );
}

export default DraftUpdate;

For the Draft and Post Listing components, we will use the Link component from react-router-dom to render links to fake drafts or posts.

Here's how the Draft Listing component looks like:

import { Link } from 'react-router-dom';

function DraftListing() {
    return (
        <div>
            <h1>This is Draft Listing</h1>
            <ul>
                <li><Link to='/drafts/1'>Draft 1</Link></li>
                <li><Link to='/drafts/2'>Draft 2</Link></li>
            </ul>
        </div>
    );
}

export default DraftListing;

You can check out how the code looks like at this point here.

Create The Initial Routing

Now, onto the actual routing. We'll need to add the ff. code to the App component:

<BrowserRouter>
  <nav>
    <ul>
      <li><Link to='/'>Home</Link></li>
      <li><Link to='/drafts'>Drafts</Link></li>
      <li><Link to='/posts'>Posts</Link></li>
    </ul>
  </nav>
  <Switch>
    <Route exact path='/' component={Home} />
    <Route exact path='/drafts' component={DraftListing} />
    <Route exact path='/posts' component={PostListing} />
  </Switch>
</BrowserRouter>

In the updated App code, we now have a navigation section, and the routes to the Homepage, Draft Listing, and Post Listing have been defined.

Now, how should we add the routes to the draft and post update components?

We can do this by updating the Switch section of the App component code:

<Switch>
  <Route exact path='/' component={Home} />
  <Route exact path='/drafts' component={DraftListing} />
  <Route path='/drafts/:draftId' component={DraftUpdate} />
  <Route exact path='/posts' component={PostListing} />
  <Route path='/posts/:postId' component={PostUpdate} />
</Switch>

Technically, the above approach will already work. But, there's actually a couple of issues here:

The references to the route names are scattered across the files which makes the project hard to maintain. For example, the path drafts can be found in both the App and DraftListing components. If we want to change this path, we'd have to update both files.
The routing for the Draft Management and Post Management module are mixed up together in one file. Essentially defeating the purpose of defining modules in the first place.

Before moving to the next section, you can check out what the code looks like at this point here.

Transforming to Modular Routing

To address the issues I mentioned, we have to consider one very important thing:

Modules should be stand-alone.

Modules should be treated as smaller applications inside a larger one. They have to be in charge of everything related to them and that includes routing. This means that we should detach a module's routing configuration from the App component and place the configuration inside its respective module.

To do this, we need to introduce Module Routers.

Module Routers

A module router, as its name suggests, handles all the routing for a module. For this example, Module Routers are special components.

Before creating the module router we first need to update the current routing configuration.

In the App component, instead of directly specifying the routes to the Draft Management components, we now do this:

// From these
<Switch>
    <Route exact path='/drafts' component={DraftListing} />
    <Route path='/drafts/:draftId' component={DraftUpdate} />
</Switch>

// To these
<Switch>
  <Route path='/drafts' component={DraftRouter} />
</Switch>

So, what we're doing here is:

All routing that starts with the path /drafts will be handled by the DraftRouter

We then create the actual DraftRouter component. It looks like this:

function DraftRouter() {
    let { path } = useRouteMatch();

    return (
        <div>
            <strong>You are in draft management</strong>
            <Switch>
                <Route exact path={path}>
                    <DraftListing modulePath={path} />
                </Route>
                <Route path={`${path}/:draftId`} component={DraftUpdate} />
            </Switch>
        </div>
    );
}

Here's what's happening inside the DraftRouter:

We use the useRouteMatch function to get the current route path. This way, we don't have to hardcode the phrase drafts and it will only be defined in the App component.
We then defined a couple of sub-routes. If we received only the /drafts path, we'll render the DraftListing component. If we received the draft ID path, we render the DraftUpdate component.

Additionally, you may have noticed the modulePath property of the DraftListing component. This is because, at this point, we've updated the DraftListing component to this:

function DraftListing(props) {
    return (
        <div>
            <h1>This is Draft Listing</h1>
            <ul>
                <li><Link to={`${props.modulePath}/1`}>Draft 1</Link></li>
                <li><Link to={`${props.modulePath}/2`}>Draft 2</Link></li>
            </ul>
        </div>
    );
}

As you can see, we used the modulePath property to dynamically inject the /drafts path. There's no need to hardcode that path in this component as well.

I've also updated the Post Management module to follow this approach.

To check out the final state of the code, click here.

Summary

So, that's it! We've successfully implemented modular routing in React.

At this stage, our src directory looks like this:

With this approach, we can now enjoy the ff. benefits:

If we need to change a module's root path, we just need to change it in one place, in the App component.
If we need to remove/disable a module, we can simply remove its routing configuration from the App component.
The routes are easier to maintain since each module has its own configuration.

Anyway, I hoped you learned something new from me today. Let me know your thoughts in the comments!

Hey, you! Follow me on Twitter!