Building React Primitives to Power In-App Messaging

Hi, everyone. I'm Chris. I'm speaking today about building React primitives to power in-app messaging. I'm the CTO at Nock.

Just a quick introduction to what Nock is in case you haven't seen our videos outside. We help product teams power user-centric cross-channel notification experiences. Think about things like sending emails, push, SMS, Slack, all those kind of good things. But we also power in-app experiences as well for things like notification feeds. I'm sure a bunch of you in this room and beyond have actually used Vercel. One fun fact about Nock is we power all of Vercel's in-app and emails. So if you've ever failed a build on Vercel, those notifications come via Nock. This is a really good example of the kind of in-app experience that you can currently build with the Nock platform, which is basically we power all of the backend, the real-time service, and then we give a React library and a bunch of hooks so that you can actually build your own UI on top of it.

But today, what I want to talk to you about is how we've been extending the abilities of our in-app messaging way past actually just doing those kind of notification feeds. So what we're doing today is actually bringing the ability so that you can power any kind of in-app messaging, whether that be, you know, maybe it's a modal or a banner or like a toast that pops up to your users. And all of that is mapped to components that you own and that you introduce into your codebase. And Nock powers the data layer when we're doing that, and you actually get the benefit of our real-time in-app infrastructure that currently handles millions of users across billions of API requests. So lots of scale.

But what I want to talk about today is a bit about how we actually approach the SDK updates for introducing these changes. So we actually set out with some design principles about how we would introduce this. So we really wanted to make sure that we are optimizing for flexibility around use cases. So thinking about customers who are using these pre-built out-of-the-box components, but also people who are coming and building custom components on top of what we're providing, all the way through to Shocker for this room, people who are using other Vue frameworks that aren't React. And maybe they need to bind in and do something inside of Vue or Svelte or something else like that.

And we also wanted to make sure that everything is super customizable. So if you're using our out-of-the-box components just as they come, you can override all of the styling and bring your own kind of design system and set of styles to it. And then lastly, we wanted this kind of shallow learning curve, so making it really easy for folks to get started with the components that we provide. So it's the minimal amount of changes within your code base to get up and running with these pre-built out-of-the-box components.

So here's a bit about how we approached our design. So this slide is not a stack, but if you kind of imagine it as a bit more of a stack, this makes more sense. At the bottom, we have our low-lying SDK, which is our client SDK. That is a low-level wrapper that actually exposes plain JavaScript classes and then manages all of the kind of business logic associated with in-app messaging. When should that message show? Who should it show to? Marking it as read, things like that. That's backed by a store that we actually use TANstack Store for, which is fantastic because it gives us this kind of cross-Vue platform ability to bind into these state updates. Really, really neat.

Then, next, we actually expose a set of hooks that make use of that low-level client. That's what our React libraries can consume. Those hooks make everything nicely reactified, makes it really easy to bind to that state store so you can receive these updates. Then, finally, at the top of the stack is a set of out-of-the-box components that we provide. Those are built on top of Radex UI, the primitives that it provides. Make sure that we have a nice set of accessible components out of the gate. Then, we also deliver these kind of smart and dumb components. The smart component binds to our hooks, provides all the functionality. These dumb components are more of the view layer whereby folks can come in and maybe you want to use our modal, but you want to override the way that the button works or some other facet of the modal, and you can do so. Then, everything inside of here, you can actually update the CSS variables or the classes can be overridden. It's really easy to kind of match it to whatever styling that you have within your product.

Cool. Here's a little look at what our pre-built React components look like. We provide a banner, a modal, a card, this notification feed as well.

All of this comes out-of-the-box. It all supports light mode and dark mode as well. This is a really good example of, you know, you just want to get started really easily. You want to show your users a modal when something happens, or maybe you've got a new product announcement that you want to showcase to a subset of your users, something more like that.

Here's what this looks like in the actual code that we're able to produce. What you can see here is we have a couple of providers that we're injecting into our application. Then, we're adding our banner component. All of that just works right now. So, when the user receives a banner as a message, a banner will just display in their application with no additional code for them to write. So, really easy, and again, this is all in your code base.

If you contrast that to the tools that exist already, most of those tools are sending down HTML over the wire that's kind of been injected into your view layer. With this approach, you're actually owning the components that are rendered to make sure that your team can think about performance and optimizations and things like that. And then, if you want to build a custom component, so, think about something that we don't offer out of the box, or something more bespoke to your product's needs, this is a kind of example of the minimal set of code you need to do so.

Here, you can see we're using our hook. The hook basically makes sure that we're fetching all the data, dealing with real-time updates, everything of that nature. And then, what we can even do here is actually type the contents of the message as well. And on the Noc side, we provide a schema that can change over time so that your team can make sure that there's a strong guarantee between this component and the data that's actually coming from the server as well. Cool. So, that's a really brief overview of what we're doing with in-app messaging. Thank you very much. You can see more at noc.app, or we're over on the booth if you want to talk about more than just in-app messaging and notifications in general as well. Cool. Thank you.