Feature Toggle/Flag Design in React.js and Node.js
Tags: react, javascript, typescript, node
Published: 2020-10-25 10:45:39

---
title: Feature Toggle/Flag Design in React.js and Node.js
published: true
date: 2020-05-14 07:29:45 UTC
tags: react,javascript,typescript,nodejs
canonical_url: 
---

#### A use case for implementing FTDD in a Full Stack JS application

![](https://cdn-images-1.medium.com/max/780/1*IKzlzsK0xdyvf0QXmXz81g.jpeg)<figcaption>source of idea: <a href="https://dzone.com/articles/a-new-way-to-beta-test">DevOps Zone</a></figcaption>

[FTDD (Feature/Flag toggle driven design)](https://www.martinfowler.com/articles/feature-toggles.html) is a design pattern that helps teams to deliver new functionality to users rapidly but safely. Basically, it show/ hide features depends on the users role/ group/ whatever distinguishes the features set.   
This pattern is the foundation basis of A/B testing.

> For instance, with this ability, you may upload a feature to production in the Beginning of the development, hide it from anyone but you, keep working.  
> when you feel good enough about the feature, you may reveal it to the QA team only, and when they approve, you may reveal the feature to whoever else you want.

#### **_Motivation and struggling_**

Before we dive into the code, let me share with you what motivated me to write this article.  
In [Castor](https://www.3dcastor.com/), the company I work for, we are aiming for a full CI/CD.   
As a small [seed stage startup](https://startupxplore.com/en/blog/types-startup-investing/), with large scale system, its not an easy task. So we are always trying to find new ways and approaches for reaching this goal.

Few months back, I participated a **very** interesting lecture delivered by [Igal Steklov](https://medium.com/u/c5c145af7ccf) about FTDD.   
That was my very first experience with this pattern, and I swore to myself that I’ll implement this in my company.

It occurred to me that this design may benefit all our departments for a more optimized deployment. From the Development by deploying with less fear of major bugs, to the Product and the QA, by checking their new features in the production environment, prior to exposing them to the customers, and of-course, the managers technological mind set.

When I started to dive deep in the community for implementation approaches, I found myself with too many question marks. I found a lot of built in packages, small or big, free or not, but with a learning curve and code adjustments.  
In addition, I found many tutorials and documentation about the design algorithm, but without enough code and architecture references, especially not in my stack.  
And in the end, I realized that it would be much faster to build it by myself, without third party packages.

That’s why I decided to build it on my own, and share with all of you what I came up with.  
My simple ask for you guys, is to have your feedback on my architecture design and code, please feel more than welcome to share with me your inputs, as we will ever be in a learning curve :)

In this article I will show my solution for implementing it in my React app.  
In addition, I will show the implementation in the server side (Node), and the DB structure.

### CODE !!

The code order will be according to the development order, but you may jump wherever you want:

1. DB
2. Node
3. React

#### DB Structure

So the first thing I've done is creating my tables in the DB. i’m working with MySQL DB, and I created 3 relevant tables for this:

1. _`feature.sql`_

![](https://cdn-images-1.medium.com/max/626/1*Hr00Eqeunq6SMt-s-Y-VMw.png)<figcaption><strong>feature.sql</strong>. every new feature gets his name, ON/OFF toggle property, description and `componentId` for future use.</figcaption>

2. _`role.sql`_

![](https://cdn-images-1.medium.com/max/383/1*Vxe0Tr_sBmlHAb-mJx-yOA.png)<figcaption><strong>role.sql</strong>. list of roles to give for a user or for a group of users</figcaption>

3. _`role_feature.sql`_

![](https://cdn-images-1.medium.com/max/442/1*7iigl2pymnZ_U20SG7rqxQ.png)<figcaption><strong>role_feature.sql</strong>. assign features to roles and set the’re toggle (ON/OFF)</figcaption>

With this 3 tables I can specify features for different users.

> Example: lets say user ‘x’ is an `enterprise` (role id: 7) user.  
> We can see in `role_feature` table that this role has 2 features assigned to him, with specific properties- `feature1` (feature id: 1), and `feature2` (feature id: 2). Each feature has different toggle property (`on` field). One is `on` and the other is `off`.  
> So, eventually, user ‘x’ should see the _`feature1`_ feature but shouldn’t see _`feature2` feature._

#### Node

The server side is responsible of 2 things:

1. Arranging the list of features with there toggle properties, for the user.
2. Block `off` features controllers

Lets see how I managed to arrange those features:

{% gist https://gist.github.com/mkantz84/076ce9e2d7f836101a9c2e9bd799423b %}

The above code shows the arrangement of features for the user.  
The method returns an array of features, some of the are `on`, some of them `off`.  
This list will be sent to the client side, and will be used here, for the controller blocking.

{% gist https://gist.github.com/mkantz84/a8feea1d1861f341a4951ada19ea6e55 %}

{% gist https://gist.github.com/mkantz84/9d76a3afd9e08bcc3196a6013bba1ced %}

{% gist https://gist.github.com/mkantz84/fcb9037cf71d977327c38a77fc8ec5f5 %}

These logic above shows the blockage of the controllers.

`policies.js` is responsible for every logic you want to add prior to the controller. For example, checking user authentication.  
I added there a feature validation, `isFeatureOpenPolicy`, which checks if the feature that relates to the controller is `on` or `off`.  
If it is `on`, continue regularly (`next()`).  
If it is `off`, return forbidden response.

#### React (+ Redux)

_You may play with the features and see the code of the client side, in this_ [_codesandbox_](https://codesandbox.io/s/ftdd-react-g7jyf)_:_

{% codesandbox ftdd-react-g7jyf %}

In the client side of the application I used a very simple methodology by using [HOC (Higher Order Component)](https://reactjs.org/docs/higher-order-components.html).  
This methodology allowed me to toggle features very easily by adding HOC to component.

> To make it work we create a component for every feature.  
> Its not must, and I will show how I toggled features that are not a component and/or in other component or service

First, we need to store the list of `features` that we got from the server.  
I work with [Redux state management](https://redux.js.org/), so the right place for me to store was the `user` `reducer` (that’s where I store all the initial user state)

_OK,_ _lets see the HOC:_

{% gist https://gist.github.com/mkantz84/709f218503a9e1496284589ab3558cf0 %}

This HOC is very simple:  
It gets 2 arguments: `WrappedComponent`, which is the component that wrapped with the HOC, and `featureComponentId`, which is the feature id of the component.  
It checks if this feature is `on` or `off`.  
If it is `on`, it returns the `WrappedComponent`, like nothing happened.  
If it is `off`, it returns nothing (`<div/>`), so the user wont see that component.

> The HOC is connected to the `user` `reducer`

_`isFeatureOn:`_

{% gist https://gist.github.com/mkantz84/a16912d8599603f5a86dc8ae685dcf2f %}

Very similar to the server side, `isFeatureOn` method is checking whether the feature we’re looking for is `on` / `off` / doesn’t exist.  
What interesting here is the imported `redux` `store`. By that, we don’t need to pass `features` to the method, only the relevant `featureId`, which is much easier.  
We can default `features` argument with the user `features` from the `user` `reducer`, just like that: `store.getState().user.features`.

_Now we can finally see a feature component:_

{% gist https://gist.github.com/mkantz84/831324fd72d0dc427d23758a27c6174b %}

The interesting stuff here is where we `export` the component.  
That’s where we wrap our component with the HOC, and use FTTD!

Now for those of you who remember that I promised to show a non feature component case. _here it is:_

{% gist https://gist.github.com/mkantz84/f5fdd7562862c81709ae56472a80c861 %}

Very simple, just use the `isFeatureOn` method wherever you want.

> The next and following article will be on how I created the admin panel for the toggles management

That was my way of using FTDD in my full stack app. I hope some off you out there would find it useful somehow.