Sign up
react

Building a React Notification System: What You Need to Know

Allie Dyer Bluemel

Last updated on

You’ve been tasked with implementing a notification system into your product. There are two options: you (and your team) can build a system yourselves, or you can implement a free or paid third-party tool. Before deciding, you need to know the goals of the system (is it driving objectives and key results?), as well as how it might grow based on performance. If notifications aren’t your core business, the decision to custom-build a notification solution can have long-lasting implications.

Know what goes into building a React notification system before you commit to any solution, and weigh the buy-versus-build options. For the purposes of this article, we’ll be focusing on the frontend implementation.

Here’s what we’ll go over in this guide:

  • The expenses of a custom React notification system
  • The benefits of a third-party solution
  • Integrating MagicBell into your React frontend

The expenses of a custom React notification system

Before you commit to a marathon notification project, you need to know exactly what you’re getting into, how notifications can snowball, and the hidden costs. There are tools available to help you build a custom React notification system, but the reality is many might not offer exactly what you need or cause you to find secondary and tertiary solutions to implement.

For example, browser support for the various APIs differs greatly, so, in the case of reaching all your users (Safari 👀), you might need multiple custom solutions.

Push API vs. Notifications API

Even if we break down a notification system into just one type — desktop push notifications — there are still some fundamental choices to be made. You can push notifications to your users if they’re on your web app, or you can push them to your users even if your web app isn’t loaded. But these two types of notifications don’t have the same support and require different implementations.

Notifications API: The Notifications API lets you send out notifications to those who have your web app loaded, regardless of whether it’s focused. Not only should you get permission from users before you start sending them messages, but you also need to be careful about how you go about it.

Browsers have started blocking web apps from requesting permission in a spam-like manner, as well as those who continue to request even after a user has denied permission. This API is pretty straightforward: user has web app open, request permission, send notifications.

Push API: The Push API is probably very exciting to marketers and strategists alike. With it, after receiving permission, you can send notifications to users even if your web app isn’t loaded. This allows you to send marketing, sales, and promotional content whenever you want.

Unlike mobile push, which is universally accepted as a way of life at this point, web push, in the same manner, is not. The support for this type of web push is low, meaning it’s only effective if your customers happen to be using the various browsers and devices that support it.

Safari is only partially supported with the Notifications API and not supported at all by the Push API. A custom solution that needs to target Safari users will require a secondary custom solution that integrates Apple’s own method.

A growing Notification system

There’s more to a fully-fledged React notification system than just desktop push messages. While a request for such a system might start small with one type of notification, the success of that implementation can (and will likely) expand into requests for other types of notification implementations. A full notification system would likely include most or all of the following notification types:

  • Web push
  • Mobile push
  • SMS
  • Email

As we’ve mentioned, a custom solution for web push will need multiple solutions to reach all browser and device users. Mobile push will require a separate solution as well. Both systems will need to be permission-based, with service workers and a server handling the sending of notifications. You’ll also have to make sure that when a user revokes permission, it can be handled by the system.

SMS and email notifications require you to collect personally identifiable information (PII), mainly a phone number or email address. This means you have to make sure your system is compliant with privacy acts like GDPR and CCPA.

Before implementation, if stakeholders have the data and insights about how certain notification types will benefit the product and the users, then you’re in a good situation. Another (and more likely) scenario could be that one type of notification will be requested, and based on the success or failure of that implementation, it will go through iterations or expansion.

Hidden costs

Sometimes custom solutions are necessary, but with that comes all the hidden costs that need to be considered. With developers only spending around 32% of their time actually writing code, undertaking a custom-built React notification system (that will likely grow) is a large step.

With your time already split between various tasks, there are some specific hidden costs with notification systems to take into account.

We’ve already mentioned that notifications are supported differently on some devices and browsers, so separate custom implementations will need to be worked out to get the coverage you need.

After a React notification system is built, you’ll likely also be required to set up A/B tests for content, timing, and other variables. These tests will ensure you’re sending the right messaging at the right time to the right users. All of that A/B testing data needs to get stored properly (ideally, a single source of truth) to make sure it’s easily readable by data teams. That’s a lot to take on.

Takeaway

While there can be benefits to building a custom solution, like full control over the design and implementation, a homespun solution is probably more trouble than it’s worth. Unless your core business is notifications, building and maintaining a notification system in-house is a large commitment for a development team.

The benefits of a third-party solution

Using a third-party tool for your notifications gets bug fixes, browser compatibility, and a large portion of maintenance tasks off your plate. As the notification system needs to grow with the product, expansion is easier and less stressful.

Beyond the basics

Beyond permission requests and a message, third-party tools offer out-of-the-box features you can implement as stakeholders make requests and the system expands. You don’t need to build your own React notification system to have a successful notification implementation. Notification tools quite obviously make notifications their business, and in addition to multiple features, they take a lot of the testing and maintenance of the core system off your plate.

Types of notifications: As we’ve already mentioned, a notification system can expand to include more than web or mobile push. Email and SMS notifications can be added to the equation, requiring completely different implementations and compliance checks. Third-party notification tools will have tiers or add-ons for expansion into different notification types as your system grows.

Segmentation: Segmenting users allows for targeted and customized messages. Groupings based on language, location, and habits allow you to notify those who will benefit the most. By targeting specific users with specific notifications, you can add value to the user experience. Building custom segmenting tools on top of your custom notification solutions is a headache.

UIs for non-devs: UIs and dashboards are an incredibly useful tool. UIs give stakeholders and non-devs ways to make updates and changes, and dashboards can give insights into data. With these features, you won’t have to update notification copy, parse data, or relay as much info to the data team. Not having to build these UIs and dashboards internally will be a huge time-saver.

Customization Options

Third-party tools understand that branding is important, so customization options will exist to match your brand style. Whether you’re starting with toast notifications or implementing a full notification solution, you’ll have options to try out, ensuring you can match your brand and strategy.

Brand matching: Fonts, colors, and icons can be integrated into third-party tools, ensuring your brand’s style isn’t lost in the notification process.

Custom animations: Toast and certain browser notifications leave a lot of room for customization and animations, including their badges. Third-party libraries will often have options to override the default CSS they’ve provided, opening up the possibilities for complete customization.

React-toastify playground with fun style and animations

Takeaway

On a surface level, notifications might not seem like a large ask. But they can become feature-complex depending on the growth strategy. Once a notification system is implemented, it needs to be monitored and maintained, possibly creating a disturbance in your development cycles. Using a third-party tool mitigates the responsibility of maintaining a full notification system.

Integrate MagicBell into your React frontend

We’re going to skip over the back-end integration and focus on how to implement a MagicBell notification inbox into your React frontend. The notification inbox can be implemented in a few ways, in a few short steps, with customizable options.

The default NotificationInbox spans the entire width of the page when opened (note: you can control the height through properties).

import MagicBell, { NotificationInbox } from '@magicbell/magicbell-react';

export default function NotificationDemo() {
 return (
   <MagicBell apiKey={MAGICBELL_API_KEY} userEmail="john@example.com">
     {(props) => <NotificationInbox height={400} {...props} />}
   </MagicBell>
 )
}

App.jsx

The FloatingNotificationInbox is a tooltip with the ability to control the width and height through properties.

import MagicBell, { FloatingNotificationInbox } from '@magicbell/magicbell-react';

export default function FloatingInboxDemo() {
 return (
   <MagicBell apiKey={MAGICBELL_API_KEY} userEmail="john@example.com">
     {(props) => <FloatingNotificationInbox width={500} height={400} {...props} />}
   </MagicBell>
 )
}

App.jsx

The MagicBellProvider component allows for a custom implementation of a notification inbox. This creates a MagicBellContext and keeps notifications updated in real time through a connection to magicbell.com.

import { MagicBellProvider } from '@magicbell/magicbell-react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
import HomePage from './HomePage';
import NotificationsPage from './NotificationsPage';

export default function App() {
 return (
   <MagicBellProvider
     apiKey={MAGICBELL_API_KEY}
     userEmail="john@example.com"
     theme={{ icon: { borderColor: 'white' } }}
   >
     <Router>
       <Menu />
       <Switch>
         <Route exact path="/" component={HomePage} />
         <Route exact path="/notifications" component={NotificationsPage} />
       </Switch>
     </Router>
   </MagicBellProvider>
 );
}

App.jsx

import { useNotifications, NotificationList } from '@magicbell/magicbell-react';
import FullWidthNotification from './FullWidthNotification';

export default function NotificationsPage() {
 const notifications = useNotifications();

 return (
   <div className="p-20">
     <h1 className="text-3xl mb-8">
       {notifications.total} Notifications
     </h1>
     <NotificationList notifications={notifications} />
   </div>
 );
}

NotificationsPage.jsx

See a full demo of a custom NotificationList implementation on CodeSandbox.

Custom themes

The notification object has default properties for the following that you can override by building out custom themes:

  • icon
  • header
  • footer
  • unseenBadge
  • container
  • notification
  • unread
  • unseen

A custom theme can be built to override various CSS properties like backgroundColor, textColor, textAlign, fontSize, borderRadius, and more.

import MagicBell, { FloatingNotificationInbox } from '@magicbell/magicbell-react';

export default function FloatingNotificationDemo() {
 const customTheme = {
   icon: {
     width: '40px',
     borderColor: '#8b0000',
   },
   header: {
     fontSize: '18px',
     backgroundColor: '#8b0000',
   },
   footer: {
     backgroundColor: '#8b0000',
   },
   container: {
     backgroundColor: '#f2f3f4',
   },
   notification: {
     default: {
       backgroundColor: 'rgba(139, 0, 0, 0.5)',
       textColor: '#36454f',
       fontSize: '16px',
     },
   },
 };
 
 return (
   <MagicBell theme={customTheme} apiKey={MAGICBELL_API_KEY} userEmail="john@example.com">
     {(props) => (
       <FloatingNotificationInbox height={400} {...props} />
     )}
   </MagicBell>
 )
}

See a full demo of the FloatingNotificationInbox implementation on CodeSandbox.

Takeaway

It’s easy to request an API key and try out the React SDK in your own app or in a sandbox online!

Easily implemented, ready to grow notifications with MagicBell

MagicBell provides a fast and easy way to implement a solution for your React notification system needs. Visit the docs to see how to integrate MagicBell into your back end and frontend. Our notification inbox can be implemented with various API wrappers and libraries that have been created.

Your notification system with MagicBell can grow with the product, with options for in-app, web push, mobile push, email, and SMS. Sign up and get instant access to your API key here.

Related articles: