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:

1. Configuration - In its most basic form, the configuration is simply a mapping between a condition and a component.
2. Dynamic Components - Of course, we'd need to have the components that will actually be dynamically rendered.
3. 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!

Why Do Feature Management?

Here are some scenarios where controlling feature availability is necessary:

1. 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.
2. 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:

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!

In fact, I recently Tweeted about this, that content creation nowadays is about creating content once and distributing it everywhere.

When I started using Notion, my first idea was to apply this approach to my workspace. Here's how I did it.

The Databases

The first things I created in Notion are 2 databases:

• Topics
• Content

Topic Database

This is the database that will contain all of my topics & ideas. In this database, I only have one 1 template and it looks like this:

The 2 major fields in this template are:

• Tags - a multi-valued field that I can further use to classify my ideas
• Related to Content Calendar (Topic) - this is an auto-generated field because of a Relation field added in the templates under the Content database. We'll discuss this further later.

This database is using a Table view and it looks like this:

Content Database

This database will contain all of my actual content pieces.

I created 2 templates under this:

• Tweet - for posting on, well, Twitter
• Article - for posting on blogging platforms

Both templates have this structure:

The major fields for these templates are:

• Type - this is the type of content piece (Article or Tweet). Though, this is already predefined by the templates.
• Topic - this is the Relation field I mentioned earlier. This allows me to define which topic this piece of content is related to.

• Status - specifies the state of this content piece. It has the following possible values:

• Publication Date & URL - to allow me to specify the publication info once the content piece is published.

Lastly, the main body content of the template will be where I write the actual content.

Assets Sub-page

As you may have noticed, there's a default sub-page in these templates named Assets. This sub-page allows me to upload the assets that I'll embed in the content piece.

Based on its parent template, this sub-page will have a different default value under it.

• For Tweets, it'll look like this:

• For Articles:

Board View

For this template, I used a Board view so I can easily track the individual status of my content pieces:

Wrapping Up

So, this is how I manage my content in Notion! This approach really helped me become more organized.

Now, every time I think of an idea, I first log it in the Topics database. With Notion's mobile apps, I can even do this while on the go.

Then, I'll create the related content pieces depending on which platforms I'm targeting.

I'm also planning to create more Content templates to handle different platforms like Facebook or even YouTube.

Do you have any suggestions or comments on how I can improve this? I would love to hear your thoughts so leave them in the comments section below!

Hey, you! Follow me on Twitter!

We'll cover the ff. steps:

1. Setting up MongoDB
2. Creating an Express application
3. Optimizing your Express routes
4. 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.

1. Create a MongoDB Atlas account here.
2. Create a cluster. For new accounts, you can use the forever free tier!
3. 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.

1. Download the latest Compass version here.
2. Install the thing!
3. 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.
4. Launch Compass, **key in your connection string, then, click Connect**.
5. Once connected, you can now click on the Create Database button.
6. 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.
7. You should now see audit-log-demo as part of the database list.

8. 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

1. Open your favorite CLI and navigate to your desired working directory.
2. Create a new package using npm init. Follow the prompts and provide the necessary details.
3. Install both express and the mongodb driver by executing npm install mongodb express --save
4. 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.
5. Create a new environment setting with key ALD_CONN_STRING and set its value to your connection string.

Connecting to the database

1. 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.

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

3. 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:

1. A middleware that establishes the connection to the database and will then pass this connection instance to the request handlers.
2. 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:

1. Middleware usage - for reducing code redundancy
2. 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:

1. Once your API grows, you should split the route definitions into multiple code files.
2. 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!

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:

1. Setup a theoretical application and identify its modules and components
2. Implement a regular routing model for the said application
3. 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:

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.

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!

As part of this planning, we use conceptual data structures to represent data models. Once we start the implementation, we then translate these data structures into actual database tables. Ever wondered how that's done? Then you're at the right place!

In this post, we'll talk about how to represent some of the common data structures in an SQL database.

What data structures are we working on?

For the purpose of this post, we'll cover the ff. data structures:

• Linked Lists. A list of items where each item can be connected to one or both of the items directly beside them.
• Graphs. Consists of nodes that can be connected to one or more other nodes.
• Trees. Similar to graphs but without any loops.
• Stacks. A list of items and follows the last-in-first-out principle.
• Queues. A list of items and follows the last-in-first-out principle.

Let's simplify first!

We can go ahead and define the SQL representation for the data structures mentioned above, but, we can still simplify this!

In fact, some of the characteristics mentioned above are more tied to how these structures behave and not on how they store data. After realizing this, I further grouped the data structures into 2 categories:

• Linear Structures. These are the data structures that have "edges" or linear connections between their nodes. I placed Linked Lists, Graphs and, Trees under this category.
• Ranked Structures. These are the data structures that are similar to flat lists and where the order of the items is important. I placed Stacks and Queues under this category.

Now that we have these categories, we don't really need to represent each individual data structure in SQL. We just need to represent these 2 categories instead!

Time to represent!

It's time for me to show you how I will represent the above categories in SQL. Let's go!

Linear Structures

In terms of representing linear structures in SQL, we just need to take note of 2 things:

• Each node can have 1 or more edges
• Each edge can only go in 1 direction (from Node A to Node B). If we want to represent a reverse edge, we should create a different record for it.

Here's the ERD for Linear Structures:

In the above diagram, we used a many-to-many pattern where we defined 2 tables:

• Node. This represents each node in the linear structure.
• Edge. This represents each edge. For the direction, it's always represented as from NodeA to NodeB.

Additionally, each node can have 0 or more edges.

Ranked Structures

In terms of representing ranked structures, we just need to take note of 2 things:

• We need to represent lists
• Each list should contain one or more items with reference to an item's rank

Here's the ERD for Ranked Structures:

In the above diagram, we defined 3 tables:

• Item. This represents each item that can be part of a list.
• ItemList. This represents a list.
• ItemRank. This maps out which items belong to which list. Additionally, each mapping will also indicate the rank of an item in a particular list.

We made this diagram more flexible so that we can put a single item in multiple lists. Additionally, each ItemRank record has 2 primary keys: ItemListId and Rank. This means that in each list, we don't want items to share a particular rank.

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!

Summary

In this post, we went through how to represent some of the common data structures in an SQL database using the ff. steps:

1. What? Identify the characteristics of the data structure.
2. Simplify! Shift your focus to how the data structure stores data.
3. Represent! Use the simplified information to create a set of SQL tables to represent the data structure.

I know there are tons of other ways to represent these common data structures in SQL. If you know one, feel free to share them in the comments!

Hey, you! Follow me on Twitter!

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:

1. Security
2. Pre-conditions
3. 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:

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!

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

1. A real-world example as well as a description of the main challenges for the feature
2. A list of components used in the feature
3. 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!

Your professional growth can happen outside of work.

Looking back, I really believe that this mindset would've helped my younger self a lot. Let me tell you why.

The tech industry grows so fast!

5 years ago, my mindset was very linear. My strategy was just to gain enough experience at one company then, bring that experience to the next one. Outside work, it was all fun. I didn't spend any time studying or researching what's up in the tech space. Then, reality kicked me hard.

The first few roles I had were very similar in terms of the core tech stack used. I was introduced to some new frameworks/platforms along the way. At the time, I thought that being loyal to a single tech stack was enough.

After a few years, I moved to a start-up company. The tech stacks they were using were from everywhere! That's when I realized that most of my technical knowledge was no longer up to date. Azure was everywhere. It was the first time I heard about AngularJS but, Angular 2 was already booming. It felt like I was left behind.

I'm not discounting the experiences I gained from my first few roles. My knowledge of their respective tech domains improved a lot. Plus, I was also able to sharpen my soft skills during those times.

The point is, my personal choices have led me to play catch-up with the rapid changes in the tech industry. That wasn't fun to do. With all honesty, that's on me.

We all have agendas...

The thing is, companies have agendas. People do, too. The moment a person gets employed, the company's and that person's agendas are intersecting. Their technical interests are aligned at this time.

The only thing permanent is change. Sooner or later, there's going to be a time when these two agendas start moving away from each other for whatever reason. This can happen more frequently at the start of one's career since this is usually the "experimental" stage.

5 years ago, this parting of ways happened to me very quickly (and abruptly!). Unfortunately, because of my mindset at the time, I didn't have any vision of what's next. That's when I realized that I should've ensured that I had relevant and up-to-date skills way before these things happened.

Find a way to your goals.

I shouldn't have been content with only the knowledge that's directly in front of me. I should've explored my other interests and should've checked out the trends outside the bubble I'm in. If I found something interesting and I felt that it was worth studying, I should've gone for it.

Here's an example. Let's assume I'm currently a web developer in a company focusing on web apps. Then one day, I suddenly became curious about mobile development. This curiosity grew further because I also discovered that mobile development is becoming the next big thing in the industry. What should I do?

I believe there are two options:

• I can talk to the management and ask if this learning path can be supported. I can check if there are plans to build a mobile development team and bank on that.
• I can take on the learning path as a personal improvement exercise. This can serve as a stepping stone for me to move to a mobile development role in or out of my current company.

There are a few other scenarios here but, let's not focus on them. Let's focus on the common factor among all of these scenarios — putting in the effort is a must.

My growth. My responsibility.

Even if there's a bunch of training and learning opportunities provided by a company, it is still my choice whether to grab them or not. This is more true if I had to find these training and learning opportunities outside of the company. Whatever the case is, it should be a conscious effort on my part.

How should I study?

So, what kind of training and learning opportunities am I talking about? These can be conferences, online/in-person training, or certifications. One big concern on this, especially if they're totally not company-sponsored, is the cost. I personally believe that paying for these things is a form of investment in myself.

Of course, it is never a good idea to force oneself to pay for something if they're not comfortable doing so. So, I don't force it if it's not amenable to my current financial situation. During these times, I check free alternatives and focus more on self-practice.

When do I study?

Another big challenge is finding a way to fit all these learning activities into my schedule without affecting the quality of my work. It's not easy but, nobody said it'll be.

Here are a few approaches to handle this that I'd recommend to my younger self:

• Fit it during work hours. If the learning opportunities are company-sponsored then, this is doable. If not, try squeezing in some readings or watching some tutorials before the day ends. It would also be nice if there's a way to practice during this time. Of course, this is subject to company culture and policies. Check first before doing this.

• Pour in some extra time outside of work. Now, this is more challenging than finding time at work since everyone has their own circumstances. The benefit of doing it this way is that there'll be more freedom and flexibility when it comes to studying. Note though, that it's very important to find enough time to rest as well as to attend to personal responsibilities. Make sure to always protect your personal life!

• Be flexible. Not everything is black and white. If studying during working hours is not possible for a certain day, then probably do it outside work for that day. Of course, if you have to attend to some personal matters, then you can try to squeeze in studying during working hours — again, subject to the same conditions mentioned above.

Whatever approach is preferred, the ability to deliver quality work should not be affected in any way. Remember, the goal is to grow and not to get fired!

The key is finding the right balance to ensure obligations and aspirations do not conflict with each other.

And now, the end is near...

Thankfully, I'm already living by this mindset and I am always yearning for growth!

Honestly, I would've wanted to go back in time and physically tell my younger self all of these but that's not really possible, isn't it? Nevertheless, I hope this article can help some of the other younger developers out there.

Anyway, 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.

Also, follow me on Twitter!

The Paths Not Taken (and Taken)

It all started in September 2020 and, my main focus was "How can I share my knowledge in the most effective way?".

At the time, I had three possible paths in mind: side projects, technical articles and, video tutorials.

Since side projects and video tutorials are more interactive, they were my initial choices. Unfortunately, I was dealing with a lot of stuff then. Because of that, I know I lacked the biggest requirement for the two: time.

This is why I chose to write technical articles instead. Since every article is independent of each other, I can work on them whenever I'm free. Essentially, writing technical articles was the least demanding choice for me.

On Technical Articles

For my articles, I chose to focus on the following topics:

1. Tutorials - I cover the usual step-by-step instructions on how to do certain dev tasks.
2. Technical Thought Exercises- Like Marvel, I focus on the "what if?" questions in these articles.
3. The Developer Life - I know this is not 100% technical but, we do have lives, right?

As for my actual technical focus, I'm writing about JavaScript, C#, Azure, OutSystems, .NET, Java, HTML and, CSS. Basically, I cover the tech stack I'm more familiar with as well as whatever I'm studying at present.

Stepping It Up

2020 ended with me having published just two articles. My next article was published almost half a year later (June 2021). Since then, I've been publishing around two articles per month!

The majority of my articles are under the "Technical Thought Exercises" category. I'm planning to publish more tutorials in the next couple of weeks. Be sure to look out for my upcoming articles!

Wrapping It Up

I do believe that my writing style has significantly improved. I have learned a lot from others. I am now more focused on quality and branding. Of course, I'm always trying to be more consistent.

I know that I still have more to learn. I'm always open to trying out new things. In fact, I am currently registered to the Hashnode Bootcamp - The Art & Business of Technical Writing. I'm so excited to learn more during this event!

Anyway, thank you so much for reading about my journey!

What do you think should I write about next? Share your thoughts in the comments!

This post is part of a series that explores how flexible programming languages and frameworks can get. We all know that with any given task, there are several approaches available to achieve it. Let's look at this in action!

In this post, we will look at the different approaches in creating an Event Listener.

Of course, there's probably more than three ways to ways to do this in JavaScript, but, I carefully selected three unique ones that better matches the ff. categories: The Usual, The Okay, and The Complicated.

The Usual

function EventListener() {
    let _callbackA = () => {};
    let _callbackB = () => {};

    this.registerEventAHandler = function(callback) {
        _callbackA = callback;
    }

    this.registerEventBHandler = function(callback) {
        _callbackB = callback;
    }

    this.onEventA = function() {
        _callbackA();
    }

    this.onEventB = function() {
        _callbackB();
    }

    return this;
}

In the above implementation, we define a class that has two register functions for two event handlers. Additionally, there are two separate event triggers. Here's how it's used:

let listener = new EventListener();

listener.registerEventAHandler(() => {
    console.log('Event A Happened!');
});

listener.registerEventBHandler(() => {
    console.log('Event B Happened!');
});

listener.onEventA();

Only downside to this approach is that the handlers and the events are too tightly coupled. Every new event will require two sets of functions to be directly implemented in the class. It works but not really very flexible. Let's step it up a bit.

The Okay

function EventListener() {
    let _callbackMap = {};

    this.registerEventHandler = function(eventName, callback) {
        _callbackMap[eventName] = callback;
    }

    this.onEvent = function(eventName) {
        _callbackMap[eventName]();
    }

    return this;
}

The above's a more flexible version — the handlers are now decoupled from the event itself and we can now define multiple event handlers without touching the EventListener class.

The biggest change in this approach is now we've added the _callbackMap private variable. This will store the mapping between each event and their respective handler. This is how it's used:

let listener = new EventListener();

listener.registerEventHandler('Event A', () => {
    console.log('Event A Happened!');
});

listener.registerEventHandler('Event B', () => {
    console.log('Event B Happened!');
});

listener.onEvent('Event A');

But what if you need to attach multiple handlers to one event? Technically, this can still be done using this approach. Check this out:

let listener = new EventListener();

listener.registerEventHandler('Event A', () => {
    // First action 
    console.log('Event A Happened!');

    // Second action
    console.log('Now, let\'s do another thing for Event A!');
});

listener.onEvent('Event A');

The above solution works but is not really adhering to the Single Responsibility Principle. It's not really a good design to have one event handler to do two separate actions. By right, there should've been two handlers attached to the same event. Let's look at how that can be done in the next part.

The Complicated

We now want to be able to attach multiple handlers to a single event. Therefore, we need to change the data type of the _callbackMap variable since each event will now have a list of handlers. Take a look at the new code:

function EventListener() {
    let _callbackMap = {};

    this.registerEventHandler = function(eventName, callback) {
        if (!_callbackMap[eventName]) {
            _callbackMap[eventName] = [];
        }

        _callbackMap[eventName].push(callback);
    }

    this.onEvent = function(eventName) {
        if (_callbackMap[eventName]) {
            _callbackMap[eventName].forEach((handlerData) => {
                handlerData();
            });
        }
    }

    return this;
}

Here's how it's used:

let listener = new EventListener();

let eventAName = 'Event A';

listener.registerEventHandler(eventAName, () => {
    console.log('Event A Happened!');
});

listener.registerEventHandler(eventAName, () => {
    console.log('Now, let\'s do another thing for Event A!');
});

listener.onEvent(eventAName);

The output will now be:

Event A Happened!
Now, let's do another thing for Event A!

The above solution now allows multiple handlers for individual events. So, when the event is triggered, all the attached handlers will be executed in the order they were registered. Let's step it up a little bit more. What if we want to control the flow by which the event handlers are executed? Here's how:

function EventListener() {
    let _callbackMap = {};

    this.registerEventHandler = function(eventName, callback, priority = 1) {
        if (!_callbackMap[eventName]) {
            _callbackMap[eventName] = [];
        }

        _callbackMap[eventName].push({
            callback: callback,
            priority: priority
        });

        // rearrange the handlers for this event based on priority
        _callbackMap[eventName].sort((a, b) => {
            if (a.priority < b.priority) {
                return -1;
            } else if (a.priority > b.priority) {
                return 1;
            }

            return 0;
        });
    }

    this.onEvent = function(eventName) {
        if (_callbackMap[eventName]) {
            _callbackMap[eventName].forEach((handlerData) => {
                handlerData.callback();
            });
        }
    }

    return this;
}

let listener = new EventListener();

let eventAName = 'Event A';

listener.registerEventHandler(eventAName, () => {
    console.log('Event A Happened!');
}, 2);

listener.registerEventHandler(eventAName, () => {
    console.log('Now, let\'s do another thing for Event A!');
}, 1);

listener.onEvent(eventAName);

As for what's changed, the _callbackMap now has a priority field for each of its event-to-handler mapping. When an event is triggered, this priority is used to determine the order of execution of the handlers.

The output will now look like this:

Now, let's do another thing for Event A!
Event A Happened!

Pretty neat, right?

The End

For your reference, all the code for this post can be found here.

Anyway, there's most likely many more ways to implementing an Event Handler. Feel free to share them by commenting on this post.

I hoped you enjoyed exploring these with me. I'll be posting more in this series (covering other programming languages too!) so make sure to stay tuned!

RotoscodeJS can be embedded on any webpage and even on blogs (as long as the blog supports full embed scripts).

Here it is in action:

The Recording Process

So simple, right? Once the recording is complete, an embed code will be provided so you can embed the player widget on your website.

The Build

RotoscodeJS is made of 2 components:

• The VS Code Extension which serves as the recorder. ( Source )
• The embeddable player widget. ( Source )

Your Turn

Let me know your thoughts on RotoscodeJS. Any feedback is welcome. Looking forward to hearing from you!

If you want to stay updated on RotoscodeJS or on any of my other projects, follow @projectkenneth (that's me!) on Twitter.

This post is part of a series that explores how flexible programming languages and frameworks can get. We all know that with any given task, there are several approaches available to achieve it. Let's look at this in action!

In this post, we will look at the different approaches in implementing an Algorithm Selector. For this article’s purposes, an Algorithm Selector is basically a method or class that determines which appropriate algorithm is best used for a certain input.

Let's say that I want to implement an Algorithm Selector for sorting algorithms. To select the correct algorithm you'll use, I'll base it on the length of the array:

• For smaller arrays, I decided to use Bubble Sort.
• For larger arrays, I want to use Quick Sort.

In this example, let's set the threshold to 100. Any array with more than 100 items will be considered a "large" array.

Of course, there's probably more than 3 ways to ways to do this in Java (or any OOP language for that matter), but, I carefully selected three unique ones that better matches the ff. categories: The Usual, The Okay, and The Complicated.

The Usual

private int[] sort(int[] arrToSort) {
    if (arrToSort.length <= 100) {
        return this.bubbleSort(arrToSort);
    }

    return this.quickSort(arrToSort);
}

public void execute() {
    var fiftyArray = Helpers.generateArray(50);
    var hundredFiftyArray = Helpers.generateArray(150);

    this.sort(fiftyArray); // bubble sort
    this.sort(hundredFiftyArray); // quick sort
}

In the above implementation, I simply used an if statement to determine the correct algorithm to use. Pretty straightforward and it just works. Let's step it up a bit.

The Okay

private int[] sort(int[] arrToSort) {
    var sortingAlgos = new ISortingAlgorithm[] {
        new BubbleSort(),
        new QuickSort()
    };

    var canSort = false;
    var i = 0;
    do {
        canSort = sortingAlgos[i].canSort(arrToSort);

        if (canSort) {
            return sortingAlgos[i].sort(arrToSort);
        }

        i++;
    } while (!canSort && i < sortingAlgos.length);

    return arrToSort;
}

public void execute() {
    var fiftyArray = Helpers.generateArray(50);
    var hundredFiftyArray = Helpers.generateArray(150);

    this.sort(fiftyArray); // bubble sort
    this.sort(hundredFiftyArray); // quick sort
}

Now we're onto something. I've modified the sort method to use a more flexible way of identifying the best algorithm to use. Instead of hardcoding using an if statement, all sorting algorithms are implemented in their own class. These algorithm classes implements the ISortingAlgorithm interface.

public interface ISortingAlgorithm {
    int[] sort(int[] arrToSort);
    boolean canSort(int[] arrToSort);
}

This interface exposes a canSort method so any class implementation bears the responsibility of checking the input and ultimately declaring "Hey, I'm the one for this array!". A bit cheesy but you get how it works. Additionally, the actual sorting logic (sort method) is implemented inside each algorithm class.

Here's how this looks like for the BubbleSort class:

public class BubbleSort implements ISortingAlgorithm {

    @Override
    public int[] sort(int[] arrToSort) {
        System.out.println("Sorted " + arrToSort.length+ " items by bubble sort!");
        // Implement quick sort

        return arrToSort;
    }

    @Override
    public boolean canSort(int[] arrToSort) {
        return arrToSort.length <= 100;
    }
}

The sort method will then iterate over the array of algorithms. Then, the first one to return true when their canSort method is called will be the algorithm used to sort the input array.

That's quite a bit already, right? Well, let's look at something more exciting.

The Complicated

The problem with The Okay approach is that the sorting algorithms are tightly coupled with the executing class. All of them are explicitly instantiated inside the sort method. In terms of good OOP design, it's not recommended to have very tight coupling between classes.

So in this approach, we'll use the Chain of Responsibility design pattern. In this pattern, there's a set of receivers with which the input will pass through. In a few points, here's how this pattern works:

1. Once a receiver receives the input, the receiver will evaluate the input.
2. If the receiver determines that the input is compatible with it, the receiver will proceed with the actual processing.
3. If the input is not compatible with the receiver, the current receiver will just pass the input to the next available receiver.

For this article, the "receivers" are the sorting algorithm classes. I've now modified them to extend the SortingAlgorithm class:

public abstract class SortingAlgorithm {
    private SortingAlgorithm NextAlgo = null;

    public SortingAlgorithm() {
    }

    public SortingAlgorithm(SortingAlgorithm NextAlgo) {
        this.NextAlgo = NextAlgo;
    }

    protected abstract boolean canSort(int[] arrToSort);

    protected abstract int[] sortInternal(int[] arrToSort);

    public int[] sort(int[] arrToSort) {
        if (this.canSort(arrToSort)) {
            return this.sortInternal(arrToSort);
        } else if (this.NextAlgo != null) {
            return this.NextAlgo.sort(arrToSort);
        } else {
            return arrToSort;
        }
    }
}

As seen above, the SortingAlgorithm class optionally receives the NextAlgo. This is the next algorithm in the chain and it will be called upon if the current algorithm cannot process the input. For simplicity, if there's no available NextAlgo, the sort method will just return the unprocessed input.

Now, let's look at the actual execution using this approach:

var fiftyArray = Helpers.generateArray(50);
var hundredFiftyArray = Helpers.generateArray(150);

var quickSort = new QuickSort();
var bubbleSort = new BubbleSort(quickSort);

var sortChain = new SortingChain(bubbleSort);

sortChain.sort(fiftyArray); // bubble sort
sortChain.sort(hundredFiftyArray); // quick sort

In the above execution code, the sorting algorithms are actually instantiated outside the algorithm selector class SortingChain. Now, if I need to add/remove sorting algorithms , I don't need to touch the SortingChain class.

If you want to step this up further, you can also use Dependency Injection to dynamically load the sorting algorithms. Additionally, there are other design patterns aside from Chain of Responsibility that can be used to achieve the same thing.

The End

For your reference, all the code for this post can be found here.

Anyway, there's most likely lots of approaches to implementing an Algorithm Selector. Feel free to share them by commenting on this post.

I hoped you enjoyed exploring these with me. I'll be posting more in this series (covering other programming languages too!) so make sure to keep an eye!

This post is part of a series that explores how flexible programming languages and frameworks can get. We all know that with any given task, there are several approaches available to achieve it. Let's look at this in action!

In this post, we will look at the different approaches in implementing one of the basics in JavaScript: declaring functions. There's probably more than 3 ways to declare functions in JavaScript, it's a fairly flexible language, but, I carefully selected three unique ones that better matches the ff. categories: The Usual, The Okay, and The Complicated.

The Usual

function multiplyNumbers(a, b) {
   return a * b;
}

We all know about this one. This is simply following the very basic function declaration syntax. Easy to understand and very straightforward. I don' think I need to explain this further. Let's step it up a bit.

The Okay

(function(win) {
    win.multiplyNumbers = function(a, b) {
        return a * b;
    };
})(window);

Now we're onto something. This approach introduces a new layer of scope. A wrapper anonymous function accepts the window object. Inside the anonymous function, the actual multiplication function is assigned to the multiplyNumbers variable of the window object. Since the inner function is attached to the window object, anyone outside of the anonymous function will still be able to access it by simply using the normal syntax:

multiplyNumbers(5, 6);

One benefit of this approach is that we can limit the scope of certain variables. Here's another example:

(function(win) {
    var PIConst = 3.14;

    win.getCircumference = function(radius) {
        return 2 * PIConst * radius;
    };
})(window);

In this example, a constant variable is introduced to represent the value of PI. Again, the getCircumference function is still accessible to everyone, but no one will have access to the PIConst variable.

Now, let's move to something more exciting.

The Complicated

We've looked at the basic function declaration syntax as well as the anonymous approach. What will happen if we combine both? Let's go crazy!

function getCircumference(radius) {
    var PIConst = 3.14;

    return (function(radius_internal) {
        return 2 * PIConst * radius_internal;
    })(radius);
}

The above approach is pretty much the same as The Okay one. But, instead of an anonymous function wrapping the actual function, I inverted it.

The getCircumference function is not performing the work. It's merely returning an anonymous function that is the one who will do the computation. In terms of the execution, everytime the getCircumference function is called, the internal anonymous function will be executed first. Then, the anonymous function's result will be bubbled out. Looks fun right?

The End

There's most likely lots of approaches to declaring functions in JavaScript. Feel free to share them by responding to this post.

I hoped you enjoyed exploring these different approaches with me. I'll be posting more in this series (covering other programming languages too!) so make sure you keep an eye!

Then one day you wake up and decide that it's time to move on. It's time to go and look for a new job. You submitted your resume to several companies and scoured LinkedIn for interesting job postings. Eventually you got some favorable responses and after a few emails, you're now in line for a couple of interviews.

Depending on the role you're applying for, the questions will primarily be focused on your target role and technology which is most likely closely related to your latest experience. But as developers, we all know that there a category of questions that will almost always be asked regardless of the role you're applying for  — algorithms.

Don't lose them. Let them linger at the back of your minds.

Let's face it, with all the development worked you've done for the past years, did you really have the time to actually implement and use your own sorting algorithm for a live project? Let's say that once in a while you had to implement your own custom sorting algorithm for very special circumstances. How many times did you actually have to do that?

I'm not saying these concepts are useless. What I'm trying to say is that with years of experience and years of translating high-level business requirements into code, there is a high chance that developers get out of touch with these core concepts.

But in reality, as developers, we should always keep these concepts very close to us. In fact, based on my own experience, I often apply these concepts in my daily work. I just don't realize that I'm doing so.

This is why technical interviewers want to ask you about them. They want to know if you're still able to explain the concepts. Ideally, interviewers shouldn't expect you to memorize names. They should be able to extract your understanding of some of these concepts. At least that's how I did it when I became a technical interviewer myself.

But there are lots of them!

Let me reiterate. Interviewers just want to get a glimpse of your understanding of some of these concepts. As you can see, I'm not using the word "all" here. No one should expect something like that from you.

Honestly, if your interviewer seems like he knows all the algorithms in the world, there are 2 possibilities to it. First is either he really practices using all of them in his daily routine (good for him!). Second is he's been doing interviews for quite a while, so he regularly brushes up on them.

Either way, regardless of wherever your interviewer falls in the above two possibilities, their whole strategy will most likely revolve around this: "How comfortable is this candidate when it comes to explaining or discussing algorithms?"

My suggestion is for you to ensure that prior to going to these types of interviews, you brush up on your algorithm knowledge. Pick a few that you can have a comprehensive understanding of. Then, do a high-level review of a couple more.

Which ones should I select?

This next part is based on my experience as an interviewee and of course, as an interviewer. I'll share with you how I choose which algorithms I usually review before going for an interview.

Technical interviewers may ask you to write pseudocode, or even use a specific algorithm to solve a problem on the spot. Based on my experience, the test for algorithm knowledge usually revolves around the ff. categories: Sorting, Path Finding and Text Parsing.

Sorting

I always have Quick Sort ready. Regardless of your choice, the idea is to have a sorting algorithm ready when tackling technical interviews. Sorting-related technical problems are always around the corner. Honestly, with all the out-of-the-box sorting functions we use in our daily lives, studying algorithms under this category is very, very vital. You don't want to be known as "that candidate who just uses functions without understanding how they work".

Path Finding

There are lots of algorithms for path finding out there. I personally review BFS, DFS and A* before any interviews. For BFS and DFS, note that it will be better if you're able to implement them in either a recursive or iterative approach. In other algorithms (like A*), there's a concept of a heuristic. For these, make sure you understand how to identify the correct heuristic for a given problem.

Text Parsing

This can include manipulating strings or implementing your own Regular Expression engine. I personally believe this category is the trickiest among the 3. In fact, with text parsing, you're often required to mix and match other algorithms in your solution.

Finally, practice!

Let me emphasize one thing. Whatever set of algorithms you pick, always practice! It is very important to know the ins and outs of each algorithm. In some cases, you may even be asked to combine or expand existing algorithms to solve particular problems. Other interviewers may even ask you to compare the pros and cons for different algorithms.

Additionally, you can primarily focus on the algorithms you pick based on the categories I mentioned above; but, also ensure that you get a chance to have a high-level understanding of other algorithms as well. Remember, it's your understanding that's being tested and not your memorization skills. It doesn't matter if you can write the pseudocode perfectly. If you're not able to explain it, then that's not going to reflect well for you.

Lastly, if you're asked about an algorithm you don't know anything about. Don't lie. Don't make up an algorithm just based on the name. In this situations, it's better to be honest. Interviewers are trained to dig deeper especially on answers they feel are untrue. The more they dig up, the more you get in trouble. Just say you don't know that specific algorithm. More often than not, your interviewer will ask you about another algorithm or let you pick which one you want to discuss.

Anyway, here's to hoping for a successful next technical interview for you! Cheers!

Cover photo from LinkedIn Sales Solutions on Unsplash