DEV Community: François Roget

How to conditionally render React UI based on user permissions

François Roget — Fri, 15 Sep 2023 12:07:23 +0000

Web Applications become more and more complex thanks to the power and capabilities of modern browsers. With bigger and broader applications rises the need of authentication and segmentation of users.

In fact, different users have different rights on the application, allowing them to perform different actions according to their profile/role.

In this article we will learn how to organise the permissions and how to display part of your application based on the permissions given to the current user.

TL;DR;

If you are more of the show-me-the-code type of developer, you can find the final code here: https://github.com/francois-roget/permission-provider-demo

This is not security!

I would like to stress that this mechanism is not intended to prevent unauthorised requests to the server. It is more of a user experience improvement.

We have to keep in mind that any Javascript code running on the browser is present and completely readable by the end user. Hiding a button or a screen with this technique will not prevent anybody to look at the code and discover the API endpoints or the internal logic of the application.

All calls made to the API should be checked, on the server side, for user’s permissions before taking any action.

How to organise your permissions

The more naïve/tempting way to deal with user permission is to check, for example, if the current user is “admin”. Based on this, different parts of the application would be allowed or not.

Doing this will quickly block you as new requests will certainly arrive to change what a (non-)admin user can see or to create another type of user that can do more than a simple user but less than an admin.

The best way to deal with permissions is to create one permission per granular action that would be allowed or restricted in the application. For example, you can define separated permissions for:

Viewing a list of elements (element.list)
Adding an element (element.add)
Modifying an element (element.edit)
Removing an element (element.delete)

The idea would be then to aggregate those permissions into roles where you define what users assigned to that role can do. For example, creating a role “admin” with all the permissions would be a good starting point. You could then create a role “viewer” with only element.list as permissions and a role “contributor” with element.list and element.add.

Simple Use Case

Let’s image a simple CRUD use case where the logged user has different actions available according to their roles:

The Viewer role can only list the items
The Contributor role can list items and add new ones
The Administrator role can do all actions (list items, add an item and delete an item)

Minimal Viable Product

Now let’s see the minimal code that we need to implement in order to have the required features.
First of all we will use the React’s Context API. This api allows the developer to create a Context that is composed of 2 elements:

A Provider that will hold the data
A Consumer that will consume the data provided by the Provider

In this case, the data passed between the provider and the consumer is a method allowing the consumer to know if a particular permission is granted to the current user.



import React from 'react';
import {Permission} from "../Types";
type PermissionContextType = {
    isAllowedTo: (permission: Permission) => boolean;
}
// Default behaviour for the Permission Provider Context
// i.e. if for whatever reason the consumer is used outside of a
provider
// The permission will not be granted if no provider says otherwise
const defaultBehaviour: PermissionContextType = {
    isAllowedTo: () => false
}
// Create the context
const PermissionContext = React.createContext<PermissionContextType>(defaultBehaviour);
export default PermissionContext;

Next we should implement the PermissionProvider that will hold the logic of checking the user permission. This PermissionProvider will receive the user’s permissions as a prop and provide the implementation of the method isAllowedTo.



import React from 'react';
import {Permission} from "../Types";
import PermissionContext from "./PermissionContext";

type Props = {
    permissions: Permission[]
}
// This provider is intended to be surrounding the whole
application.
// It should receive the users permissions as parameter
const PermissionProvider: React.FunctionComponent<Props> = ({permissions, children}) => {
    // Creates a method that returns whether the requested
permission is available in the list of permissions
    // passed as parameter
    const isAllowedTo = (permission: Permission) =>
permissions.includes(permission);
    // This component will render its children wrapped around a
PermissionContext's provider whose
    // value is set to the method defined above
    return <PermissionContext.Provider value={{isAllowedTo}}
>{children}</PermissionContext.Provider>;
};
export default PermissionProvider;

The last component we need is a consumer to use inside our application at every place we need to conditionally render part of the UI.



import React, {useContext} from 'react';
import PermissionContext from "./PermissionContext"; import {Permission} from "../Types";
type Props = {
    to: Permission;
};

// This component is meant to be used everywhere a restriction based
on user permission is needed
const Restricted: React.FunctionComponent<Props> = ({to, children}) => {
    // We "connect" to the provider thanks to the PermissionContext
const {isAllowedTo} = useContext(PermissionContext);
    // If the user has that permission, render the children
    if(isAllowedTo(to)){
        return <>{children}</>;
}
    // Otherwise, do not render anything
    return null;
};
export default Restricted;

Using these components, we can surround our application with the PermissionProvider, then use the Restricted component.



<PermissionProvider permissions={currentUser.permissions}> ...
    <Restricted to="list.elements">
        <ElementList elements={elements} addElement={addElement}
removeElement={removeElement}/>
    </Restricted>
</PermissionProvider>
<div className="container">
    <table className="table table-sm table-hover">
        <thead className="thead-light">
        <tr>
            <th scope="col">Name</th>
<th scope="col">Price</th>
            <th scope="col">Currency</th>
            <th scope="col" className="text-right">
                <Restricted to='add.element'>
                    <button className="btn btn-primary btn-sm"
onClick={addRandomElement}>
                        <i className="bi-plus-circle"/>
                    </button>
                </Restricted>
</th> </tr>
        </thead>
        <tbody>
        {elements.map(e => (
            <tr key={e.name}>
                <td>{e.name}</td>
                <td>{e.price}</td>
                <td>{e.currency}</td>
                <td className="text-right">
                    <Restricted to='delete.element'>
                        <button className="btn btn-danger btn-sm"
onClick={() => removeElement(e)}>
                            <i className="bi bi-trash"/>
                        </button>
                    </Restricted>
</td> </tr>
))}
        </tbody>
    </table>
</div>

This allows displaying the action button only to the users having the right permission.

Enhancements

Fallback renderer

In order to provide more flexibility to the developers and UI designers, it would be great to have the possibility to display an alternative UI in case the user does not have a particular permission. For this, a fallback property will be added to the Restriction component.



import React, {useContext} from 'react';
import PermissionContext from "./PermissionContext"; import {Permission} from "../Types";
type Props = {
    to: Permission;
    fallback?: JSX.Element | string;
};
// This component is meant to be used everywhere a restriction based
on user permission is needed
const Restricted: React.FunctionComponent<Props> = ({to, fallback, children}) => {
    // We "connect" to the provider thanks to the PermissionContext
const {isAllowedTo} = useContext(PermissionContext);
    // If the user has that permission, render the children
    if(isAllowedTo(to)){
        return <>{children}</>;
}
    // Otherwise, render the fallback
    return <>{fallback}</>;
};

export default Restricted;

Custom hook

Creating a custom hook will allow the usage of the permission in more complex situations. This can be useful when we need to have a custom logic (not only rendering) based on the user’s permission.



import {useContext} from 'react';
import PermissionContext from "./PermissionContext"; import {Permission} from "../Types";
const usePermission = (permission: Permission) => { const {isAllowedTo} = useContext(PermissionContext); return isAllowedTo(permission);
}
export default usePermission;
This custom hook can now be used in the Restricted component.
import React from 'react';
import {Permission} from "../Types";
import usePermission from "./usePermission";
type Props = {
    to: Permission;
    fallback?: JSX.Element | string;
};
// This component is meant to be used everywhere a restriction based
on user permission is needed
const Restricted: React.FunctionComponent<Props> = ({to, fallback, children}) => {
    // We "connect" to the provider thanks to the permission hook
9
const allowed = usePermission(to);
    // If the user has that permission, render the children
    if(allowed){
        return <>{children}</>;
}
    // Otherwise, render the fallback
    return <>{fallback}</>;
};
export default Restricted;

Going Further

Now let’s consider a more complex (real-world) use case where the users have a lot of permissions and that those permissions cannot be fetched at login time, or the permissions can only be fetched by domain area.
In such cases, the fetching and checking of the permission is asynchronous. This delay has to be taken into account at provider and at consumer levels.

In order to make it asynchronous, we need to update the provider to return a Promise from the isAllowedTo method. In the case of async permission fetching, the PermissionProvider now receives an “async method to get a permission” instead of a “list of permissions”.

At the same time, the requested permissions can be cached at PermissionProvider level in order to speed up the UI.



// This provider is intended to be surrounding the whole
application.
// It should receive a method to fetch permissions as parameter
const PermissionProvider: React.FunctionComponent<Props> = ({fetchPermission, children}) => {
const cache: PermissionCache = {};
// Creates a method that returns whether the requested
permission is granted to the current user
    const isAllowedTo = async (permission: Permission):
Promise<boolean> => {
        if(Object.keys(cache).includes(permission)){
            return cache[permission];
        }
        const isAllowed = await fetchPermission(permission);
        cache[permission] = isAllowed;
        return isAllowed;
};
    // This component will render its children wrapped around
    // a PermissionContext's provider whose
    // value is set to the method defined above
    return <PermissionContext.Provider value={{isAllowedTo}}
>{children}</PermissionContext.Provider>;
};

At the same time, the consumer should await for the promise to complete. The question is “what should it display while the permission is fetched?”. The consumer can either render nothing or a loading component passed as parameter.



type Props = {

    to: Permission;

    fallback?: JSX.Element | string;

    loadingComponent?: JSX.Element | string;

};

// This component is meant to be used everywhere a restriction based

on user permission is needed

const Restricted: React.FunctionComponent<Props> = ({to, fallback, loadingComponent, children}) => {

    // We "connect" to the provider thanks to the PermissionContext

const [loading, allowed] = usePermission(to);

    if(loading){

        return <>{loadingComponent}</>;

}

    // If the user has that permission, render the children

    if(allowed){

        return <>{children}</>;

}

    // Otherwise, render the fallback

    return <>{fallback}</>;

};

That’s It Folks

I really hope this article will help you design more user friendly user interfaces. You can find all the code here: https://github.com/francois-roget/permission- provider-demo (take a look at the tags for the different stages).

Accelerate your prototypes development by using a monorepo

François Roget — Fri, 15 Sep 2023 11:41:09 +0000

Introduction

The other day, I needed to create a new application architecture integrating different pieces of code that should run together. The resulting system should be composed of server-side/backend componenents connecting to client side/frontend components.

I wanted to prototype the solution to make sure that the different components that I imagined would work together. I also wanted to make sure that there would not be any major problem/incompatibility that would prevent the foreseen solution to work. I was building a proof of concept.

Developer experience

All the components of the solution being new, I needed to build them at the same time, going back and forth between them to make sure that they would communicate properly with each other.

As we know, one of the key element of effective development is to have a rapid feedback loop. It means that, the time between writing code and seeing the result of said code should be as small as possible.

This is generally achieved by having development environment running the code and watching any change to the source code in order to re-launch it as soon as possible. Tools like Webpack's devServer, parcel, nodemon, jest (for tests), etc. are generally used for that.

In the case of my proof of concept being composed of different components that all need this rapid feedback loop, I was looking for a way to have that benefit for all the solution's components together as easily as possible.

It became obvious that if I wanted to work on different parts of the solution at the same time and have them running an talking to each other, the easiest way was to have them all in the same source repository.

Monorepo

This is where I came across the concept of monorepo (I know it exists since a long time but I never tried it before).

In a nutshell, a monorepo aims at maintaining differents projects consituting a common solution inside a single git repository. The different components will be threated together from a development point of view and this setup will ease the development life cycle.

By convention, the different running components will be stored inside an apps folder while any other shared code/library will be stored inside the packages folder.

There are solutions to help the developer managing the monorepo. some are built in package managers like npm or yarn (with the notion of workspace) but there are also some tools dedicated to monorepos handeling.

NPM Workspaces

The Node Package Manager (NPM) has builtin capabilities to nest multiple projects inside a parent project. It is called NPM workspaces.

NPM workspaces is a feature that allows developers to manage multiple related applications or packages within a single workspace. It simplifies dependency management and code sharing between packages and improves development efficiency and code quality. With NPM workspaces, developers define a set of related packages in a package.json file and manage them as a group within a single workspace.

This allows packages to be developed and tested independently, while also sharing dependencies and being managed as a group. By simplifying dependency management and code sharing, NPM workspaces can help improve development efficiency and code quality.

Turborepo

For this particular POC, I used TurboRepo. Turborepo reuses the power of npm workspaces and bring new features:

Incremental builds
Turborepo will cache the result of a build (also work with test results) to avoid doing twice the same job. If the source hasn't changed, the output should be the same, so it is cached
Content-aware hashing
To determine what has changed, turborepo does not rely on file modification date but rather on file content hash. This means that if you reverted your change to the previous state, the build result is still valid
Parallel execution
Uses all possible CPU cores to speed up every possible process
Remote caching
By centralising the build results in a shared cache, your teammates and CI/CD pipeline can leverage the builds done locally. I did not tried this feature.
Zero runtime overhead
Once your assets are build, there is not trace of turborepo in the resulting artefact nor in the sourcemaps.

Conclusion

Using a monorepo, and especially with the help of Turborepo, allowed me to have a very responsive develoment envrionment: I could be working on any part of the general solution and, as soon I hit save on a file, the related project gets reloaded automatically and I could see the result right away.

This setup not only allowed me to work on different applications but it also enabled sharing common code in libraries used by different applications, helping me keeping code clean and DRY.

The powed of Turborepo made this whole process even faster by relying on caching. When I start working, it does not take multiple minutes rebuilding all projects. It rather loads the build done last time from the cache.