Forem: Dima Grossman

The Full-Stack Components Customization Pyramid

Dima Grossman — Wed, 18 Sep 2024 12:50:39 +0000

Component Anatomy
The Customization Pyramid
Appearance Prop
Render props
Composition
React Hooks
Conclusion

A while back, I came across a tweet by Colin from Clerk.com stating that "Components are the new API." I couldn't agree more. For years, we've been dedicated to building embeddable components for our customers. The objective is straightforward: How can we create a fully functional component that feels so integrated and seamless that it appears to be built in-house by the host application?

Previously, a common pattern for embedding components using controllable iframes led to inconsistent behavior and, in many cases, was felt disconnected. The rise of the meta frameworks and the serverless motion provided an easier paradigm to embed native to the framework components that are one with the host application.

You've probably encountered numerous examples already: Stripe, Clerk, Liveblocks, Algolia, and others.

Component anatomy

All of the successful components I’ve interacted with showcased the following characteristics:

First-class User Experience (UX): It felt like a dedicated team crafted the component just for my application
Amazing Developer Experience (DX): It was intuitive and easy to get started within minutes
Customizability: It could seamlessly blend into my host application, but still provided a strong opinion
Lightweight bundle size: It was efficient and minimal in size
Common framework: The component was available in the framework I used in my app

Did I miss anything you think is important? Share your observations in the comments section.

In this article, we will focus on component customization and styling. I'll share some lessons we learned while building the new Novu <Inbox /> component and how we approached meeting our customers' needs.

The customization pyramid

Customization and styling exist on a spectrum between more control and less control. Whether you are just starting out and want to get up and running quickly, or you are a Fortune 500 company with a strict design system, a team of designers, and complex requirements, you should always be able to achieve your goals in the least amount of time and still have an amazing developer experience.

Let's explore the customization pyramid concept using Novu’s new <Inbox /> component as an example. By the way, our source code is open-source and publicly available in the Novu GitHub Repository.

Finally, we’ve also made our Figma design asset file publicly available, too.

Appearance Prop

You can think of the appearance prop as a white-labeled internal to the component UI system, that allows styling and modifying different aspects of the component.

A component should be opinionated and render a beautifully crafted UI out of the box. For Novu’s <Inbox /> component, it's as simple as rendering <Inbox /> in your application. Instantly, you get a fully functional UI with a bell icon that opens a popover implementation.

The first thing we might want to do is to make sure that our brand colors and design guidelines are matched within the component. This is where the appearance prop comes into play

<Inbox appereance={{
    variables: {
        primaryColor: 'pink',
        borderRadius: '4px'
    },
    elements: {
        notificationSubject: {
            marginBottom: '5px'
        },
        notificationPrimaryAction__button {
            lineHeight: '18px'
        }
    }
}} />

Variables

These are the variables that apply to all major elements in the UI. Adjusting just a few of these should allow the component to immediately adopt the look and feel of the host application. Variables for typography, colors, and spacing should be included here.

Elements

This section provides more in-depth control over visible elements within the component. At Novu, we namespace components as follows:

notificationSubject
notificationBody
notificationPrimaryAction
notificationPrimaryAction__button
- For sub-elements, we use an underscore notation to namespace repeated components such as buttons and labels.

Customers should be able to choose their preferred styling framework, whether it's Tailwind, CSS Modules, or plain CSS, and it should work seamlessly out of the box.

🌟 Tip: We've added a 🔔 icon to the class name list to help identify the element names. Everything before this emoji can be targeted and styled easily using the elements field.

Render props

In some use cases, styling with CSS alone isn't sufficient. For example, in our world, customers might want to render their own custom notification item components, enrich them with live data, or reuse existing UI elements as part of the notification flow.

Here's how this can look:

<Inbox renderNotification={(notification) => <CustomersCustomItem />} />

This approach provides significantly more control over the look, feel, and behavior of the notifications while still abstracting away the complexities of layouts, real-time updates, fetching, and notification settings.

Composition

While your components should be opinionated, you should not limit your customers to achieving their end goal of implementation. In some cases, you cannot predict the UX pattern they want to use that fits the specifics of their business.

There is a huge gap that sits between a “headless” mode, where you have to build everything from scratch, and the one-liner component that abstracts away pretty much all the internals. Compostable sub-components should bridge this gap, by breaking the one-liner into multiple components that can be re-organized to match different UX patterns.

To facilitate this, your components should be composable. Break down the component structure into independent elements, each focusing on a single goal. In our example:

<Bell />
<Notifications />
<Preferences />
<Inbox />

Each element can be rendered as a standalone component and combined to create various layouts, still abstracting away complexity.

React Hooks

When customers have strict design and UX requirements, using React Hooks are invaluable. However, resorting to a headless approach like this sometimes indicates a failure to provide adequate styling and composition options, or potentially a framework-specific SDK. To better understand the reasoning, we engage with customers who choose this route to understand if their use case can benefit others.

The React Hooks headless SDK allows customers to build any UI they want, managing the look and feel, state, interactions, and layout themselves.

Here's an example:

import { Novu } from "@novu/js";

const novu = new Novu({
    subscriberId: "SUBSCRIBER_ID",
    applicationIdentifier: "APPLICATION_IDENTIFIER",
});

const notifications = await novu.notifications.list({
    limit: 30,
});

novu.on("notifications.notification_received", (data) => {
    console.log("new notification =>", data);
});

The headless SDK provides no UI but offers a straightforward set of wrappers around your component's most common API and server actions.

Conclusion

Thinking from the perspective of your users and setting up the right architecture in the beginning will go a long way. Invest the time debating DX, show this to your users, and try to understand the main friction points in their adoption. Lastly, think of your customization strategy in layers to allow your customers to start fast and not block them if they have more specific styling and UX requirements.

I’m curious to see where the future of “Components are the new API” will take us as a team, and I'm looking forward to learning from our amazing community.

Finally, I’d be remiss if I didn’t tell you to take a look at our result. Here, you’ll find a fully functional <Inbox /> playground we styled to mimic popular apps (Notion and Reddit), and then you can also experiment by customizing your own.

Dima GrossmanFollow

Musician, Baker, and Maker. Creator of Novu - The open-source notification infrastructure for engineers.

A stage for our open-source contributors

Dima Grossman — Wed, 08 Jun 2022 14:06:20 +0000

When we first showed the world Novu (an open-source notification infrastructure) we were amazed by the incredible adoption by our community members and how the project was shaped by the dozen of individual contributors from around the world.

Over the past 6 months, more than 2,000 commits were made by more than 50 different contributors who sparked incredible ideas and helped with almost any aspect of Novu.co

In the last couple of weeks, we thought of a way for us to showcase these incredible individuals who are bringing Novu to life.

Excited to share with you the Novu Community Heroes program to highlight our contributors and showcase their work to the world.

We created a unique page for every single contributor highlighting their:

Latest pull request and contributions
Their public GitHub profile bio
Social Media Link
Contribution Badges

You can find the link here:

https://novu.co/contributors/

We encourage every open-source library to promote its contributors in every possible way. This project was not easy to make as we needed a way to automate all our contributor's actions.

So we have created this public repository if you are curios on have it was implemented:

https://github.com/novuhq/contributors

We have been using Orbit.love and GitHub to sync our contributor's work, and grant them badged and medals once a PR was approved.

How to earn a Novu Contributor Badge?

Head over to our Novu's issue page, find an issue that you might want to help with and get a PR ready (need any help? you can reach us on Discord).

The future of Novu Contributors Project

It's only the beginning of the project. We have an excellent roadmap of more things we want to feature, such as

Discord Contributions
Github Discussions
Github Issues
Content creators

Do you think about something specific we should add? Happy to hear it in the comments

Our open-source project got funded!

Dima Grossman — Wed, 11 May 2022 14:02:14 +0000

Hi Community, We have exciting news to share!

@combarnea and I open-sourced the Novu project (check our GitHub Page) because we both felt the pain of building a notification infrastructure from scratch. I have written about the inception of the idea and you can read it here: Building the first open-source notification infrastructure.

Thanks to the incredible interest of this fantastic community, our Github project became trending and grew from 200 stars to 2.2K stars, and today has more than 3,500 stars.
We can’t thank the community enough.

What is Novu?

Novu is the first open-source notifications infrastructure for developers.
It solves developers the pain of building from scratch and maintaining their notification systems.
That can be an in-app notification center (like you might know from platforms like Facebook) to transactional messages sent over multiple delivery channels.
Our goal is to solve a large number of use-cases from digest engine, to advanced workflows management including user preferences, timezone awareness, and more.

And the best part is - We are building this with the incredible help and involvement of the open-source community. Together.

Lately, we have raised a $6.6m round. This means we can go and build this project full-time. A dream comes true. It will also enable us to grow it and become the de-facto solution for developers when thinking about notifications and product-based communication.

With our new funding, Novu recruited many of our contributors to work full-time on Novu and is now working on creating the best OSS notification infrastructure.

So what happened since the funding?

We have released our admin control panel for managing notifications (npx novu init) yay!.
We have created a new website, updated with all the new features.
We started to work closely with contributors and fund projects.
We have sponsored events.
Released our multi-environment support
Released our In-app notification center as an Iframe or as a React component
Released more providers and providers dashboard
Added New team collaboration and invites
Released a new monitor and observability page
Created an awesome registration flow using a CLI :)
All in open source!!!

The future?

Support every possible notification channel: Direct, Push and others.
Create an intelligent workflow for automating your notifications channels.
Add digest capabilities to make end-user life so much easier
Have a new user preference control within our in-app and as a system
Many more to come
Still all in open source!! :)

If you haven’t checked Novu yet, feel free to go to our Github page
https://github.com/novuhq/novu

Happy if you can write to me about what you lack in Novu so I can add it to our ideas list.
Thank you. We couldn’t do it without you!

Why we have built our main website in Gatsby + Strapi instead of WordPress.

Dima Grossman — Sun, 08 May 2022 08:46:36 +0000

Today WordPress is one of the most reliable CRMs in the world.
I dare to say that this is one of the things that keeps PHP alive.
And for a good reason, with website builders such as Elementor and Divi, Product Marketer jobs become accessible in a drag and drop environment.

So why Gatsby?

We can say that it's mainly for SSG and speed, but that's not the case.
You can have amazing pre-render plugins to achieve almost the same results.

We are building the 1st open-source notifications infrastructure at https://github.com/novuhq/novu .
Our product is built by the community, and there is no really a product without our community support.
It means it should be fully available for the community to fork, contribute and use.

This is why at Novu, we build everything public, you can find our website and backend source here:
https://github.com/novuhq/website
https://github.com/novuhq/cms

But digging deeper, you can find some other important notes, for example:

WordPress suffers from migrations. You won't find websites with both stage and production environments easily implemented.
Our main application UI is built with React. So it's a lot easier for contributors to dive into the codebase without learning a new framework or language.
CI/CD is a lot easier, just a few clicks away with Gatsby.
We can run asynchronous code without using a hacky ubuntu cron jobs.
We can use our Novu libraries directly with our website.
We can query our database data easily with GraphQL. For example, have you tried to query wp_posts?

Do you think we have made the right choice?
Should we have gone with WordPress anyway?
Should we have gone with Next.js or Remix?
Let me know what you think.

Adding dark/light mode specific images to your GitHub readme page

Dima Grossman — Thu, 28 Apr 2022 15:07:47 +0000

Recently we finished designing a new logo for our open-source project Novu and discovered in the GitHub docs that you can specify an image for light and dark modes separately using the: #gh-dark-mode-only on the .md src source suffix.

Here is an example:

![Logo Dark](https://image-link.png#gh-dark-mode-only)
![Logo Light](https://image-link.png#gh-light-mode-only)

Only a single image will be shown depending on the user theme preference. Let's see it in action:

Light Mode

Dark Mode

Centering the image

It's common that you want to center a smaller image to the center of the screen. Luckily we can use the align="center" property on the supported div tag.


<div align="center">

  ![Logo Dark](https://user-images.githubusercontent.com/8872447/165779319-34962ccc-3149-466c-b1da-97fd93254520.png#gh-dark-mode-only)

</div>

<div align="center">

  ![Logo Light](https://user-images.githubusercontent.com/8872447/165779274-22a190da-3284-487e-bd1e-14983df12cbb.png#gh-light-mode-only)

</div>

The new lines after the starting and before closing of the div are important, otherwise the image won't be rendered.

I think the new theme matched logo looks great and it's another touch of detail that makes your GitHub personal or open-source project readme standout.

Post your results in the comments!

How we reduced our nodejs monorepo build time by 70%

Dima Grossman — Mon, 10 Jan 2022 16:13:26 +0000

At Novu, we use a monorepo to manage our 24 libraries and apps. There are many debates over whether you should use a monorepo or a poly-repo. For us, visibility, code sharing, standardization, easier refactoring, and a few other reasons were the critical factors for choosing this approach for our open-source notification infrastructure project.

TLDR;

We migrated from yarn workspaces & lerna to PNPM and nx.dev

The bigger, the slower

With all the advantages, there are a few drawbacks to using monorepos. We noticed a particular drawback when scaling the number of packages and amount of code in each one: The time it takes to bootstrap the project and then build any packages within. So a typical GitHub action for a service would run anywhere between 11 to 30 minutes. And that's for each time a PR was created or a code was pushed to remote.

More than that, installing a package locally with yarn install could take around 5 minutes to install and build all the dependencies.

This amount of time spent bootstrapping and building reduced the developer experience and wasted collectively so much talented people's time. Being an open-source project with a growing number of contributors, this was unacceptable.

Debugging the slowest tasks

Inspecting a typical 12 minutes GitHub action, it was clear that two specific steps took almost 70-80% of the overall time:

yarn install - takes 5-6 minutes
yarn build:{package} - could take from 3-6 minutes to build the selected package and its dependencies.

Migrating from yarn workspaces to PNPM

PNPM is a fast, disk space-efficient package manager(as stated on their website), and from some of the benchmarks, there was a massive improvement in install time against yarn workspaces.

Moving from yarn install that took around 6 minutes, the migration to pnpm was effortless: Just adding a pnpm-workspace.yaml to the project's root and running pnpm install, that's all. The symlinks and dependencies for each package we're efficiently installed, in... wait for it... just 1.5 minutes! And that's without any cache at all! After PNPM caches the majority of the dependencies, it takes less than 40 seconds to build and install the dependencies from the cached store.

Reducing ~4 minutes from the bootstrap time for every CI run and locally for first-time contributors is a HUGE win. But wait, we can do even better.

From Lerna to NX.dev

After seeing the Turborepo demo by vercel, I was intrigued by their distributed caching mechanism. With such a mechanism, we can reuse the already built packages by other maintainers and download the dist assets instead of rebuilding them each time.

turborepo vs nx.dev?
After brief research, we decided to go with nx.dev for multiple reasons:

Maturity - nx was in the market for a while now, and they have a pretty big community around them.
Performance - Seeing some of the benchmarks nx looks like a faster build system overall.

Our community member nishit-g took over the open GitHub issue and quickly after we had a PR open, the results astonished us: 30 seconds the building step! (Instead of the previous 3-6 minutes building a specific set of packages).

After implementing the nx.cloud for distributed caching, the entire 24 packages take less than 5 seconds when fully cached building. But even without being fully cached due to the intelligent parallelism nx performs and builds our target package in less than 30 seconds.

Summary

Reducing our build times from 12+ minutes to around 3 minutes significantly impacts the developer experience of our maintainers. It also reduces the feedback loop from creating a PR to running our test suite to merging the feature.

HUGE Kudos to nishit-g for migrating us from Lerna to NX. Check him out on his Twitter as well!

You can check the final configuration on our GitHub repository.

You can now add projects to personal lists on GitHub

Dima Grossman — Tue, 16 Nov 2021 07:24:08 +0000

Wondered on the GitHub IOS mobile app to check on some of my projects and stumbled upon the ability to add projects to lists. You can choose one of the predefined lists: "My stack", "Inspiration" and "Check Later". After selecting one you can also create custom lists of your choice.

This is similar to other products like Pinterest, Behance or instagram that allow you to bookmark interesting projects and organize them into lists.

Not sure yet how the lists will be represented later on, but a good guess will be that they will be listed on your profile page and you can mark some lists as private. Even following some peoples lists could be a great feature as-well :)

My first list entry was Notifire because that's where i've seen it first 😅

What projects are you going to add first and to what lists?

How we got 2,000 stars in 4 days from a dev.to post

Dima Grossman — Thu, 04 Nov 2021 09:59:51 +0000

After years of struggling when building a notification infrastructure for different projects I was involved with. My partner and I finally decided to open-source most of the work and bring it back to the community instead of building it all over again closed-source.

I've not even imagined the amount of traction the repository got in the last couple of days. How did happen you ask?

When first releasing the library we only introduced a node.js library to unify all the notification channels into a single API. Send emails, SMS, and other mediums with the same code. Need to change SES to SendGrid? No problem. Just a single line of code.

This got some traction, but nothing impressive so far.

Next comes, building and restructuring our major infrastructure blocks in preparation for a big open-source release. With a bigger picture including An Embeddable Notification Center widget, monitoring for delivered notifications and channels, an admin panel to manage notifications channels and content, and other cool features, basically, everything you need for a Notifications Infrastructure.

Before jumping to code, I decided to compose a quick blog post outlining the proposed features to the community and to hear their thoughts about this. At this point, I was not even sure somebody else had this issue before.

One day after publishing to dev.to we've noticed thousands of people visiting the post from the dev.to analytics dashboard. Further investigation showed that a lot of people came from Google. Turned out that we have been selected for the Google Discover timeline 🤯

The next day GitHub trending picked the project and it's just exploded from there:

We've been trending on GitHub for 4 consecutive days 🤯
More than 50 people joined our discord
10 new amazing contributors created PR's and contributed back
2,100 Total stars as of posting this post

What's Next?

We are working hard on releasing the next huge release of notifire to the community with all the amazing features we discussed in the post as a Docker-based environment for easy implementation.

If you're interested in any of this check us out at: https://github.com/notifirehq/notifire

The original dev.to post: https://dev.to/scopsy/building-the-first-open-source-notification-infrastructure-5h9k

I want to say thank you to all the amazing contributors I had the luck to meet in the last past days check them out!

Building the first open-source notification infrastructure

Dima Grossman — Thu, 28 Oct 2021 12:34:22 +0000

Hi Community!
Looking forward to hear your thoughts about this.

Novu was started out of pain me and @combarnea felt when developing products that required product based notifications. We've built the infrastructure so many times that we decided to take it out to the world. That's when Novu was born. We took the multi-channel notifications and provided a unified set of API's to generate notification content and simplify delivery across multiple channels.

It's more than just sending an email or push

(Part of slacks notification system)

From our past experience, we know that a wholesome notification infrastructure requires more than a unified API. We believe that building a solid notification infrastructure is something that is accessible not only to fortune 500 companies but to every developer out there.

Notificaiton infrastructure foundations

Smart Notification Engine

Using a stateful API instead of local config files can provide further functionality like:

Run time changes without redeploying your code.
Digest mechanism that allows to aggregate multiple events/messages to a single email or in-app notification for the customer. For example, a user received an email a minute ago, we don't want to send him the next one immediately and wait if further messages are planning to arrive.
User preferences - With the ever-growing number of channels, an end-user can get notifications can create a lot of noise. Notification preferences are an expected thing from most users this day. A stateful API can manage all the complexities of it out of the box.
Priority management - Not all notifications created equally, while password reset email must be delivered in real-time. Repeatable and frequent notifications can be throttled or scheduled to a later time.
Timezone awareness - Send a specific set of notifications only in the user wake hours.
Monitoring and webhook integrations to all the delivery providers.
Analyze sending patterns and debug deliverability across multiple channels

In-app notification center

An embeddable widget that is easy to integrate and customize.
Real-time update using a socket.
User preference widget to control the channels and motivation groups he would love to receive.
The ability of the user to Snooze, mute and hide notifications easily.

We would love that everyone can have the best notification infrastructure possible without investing thousands of hours on it again and again. By the community. For the community.

Next steps

We are working on porting parts of the closed source platform we developed over the years to OSS. This includes an out-of-the-box API for managing notifications, an embeddable notifications widget, activity monitoring and more.

Star or follow us on twitter to get notified when we release the first API version, embeddable widget and admin panel to the world.

What are your thoughts about the need for such a system? Have you built something similar with your team? What would expect to see there?

Feel free to comment here or at our Github page https://github.com/novuhq/novu/

Open-source multi-channel notification management library

Dima Grossman — Tue, 05 Oct 2021 18:50:59 +0000

After years of writing a multichannel notification management systems from scratch for every project i've been involved with. Me and my partner in crime Tomer Barnea decided to solve this thing once and for all and created the opensource library called Notifire.

Are main goal is to abstract the heavy lifting of managing notifications in code, provide a single API to work with all communication providers (Email, SMS, InApp, Push).

And later help with: Timezone awareness, priority, channel selection, templating, subscription management, in app widgets and etc...

Would to hear your thoughts about the API and library. Any help will be appreciated.

Our GitHub Page: GitHub

Excited to release my first side project on ProductHunt

Dima Grossman — Wed, 30 Oct 2019 10:56:46 +0000

Hi guys,

I've created releasly with a couple of friends in the office. This is a free tool to get notifications on new open-source releases and awesome-list links.

Come see us on producthunt and let us know what you think

https://www.producthunt.com/posts/releasly

Webpack released v5.0 beta

Dima Grossman — Fri, 11 Oct 2019 14:21:42 +0000

Webpack just announced v5.0 Beta. Check out the full release note