This enables non-technical teammates to launch native, prebuilt components directly in the product UI without involving engineering. We also provide the ability to update content (i.e. CMS), track user progress/state and target components to specific users from our admin panel.

The new feature, called Collections (https://frigade.com/blog/collections), works by embedding a channel directly in code — think of it as a <div /> that can spawn an inline React component – or on the floating z-index level. For instance, a channel for UI cards that sits directly in your dashboard or floating experiences like surveys and popups. Collections can be styled using your own design system to feel native and blend in with the rest of your application.

Collections also have air traffic controls (ATC) like cool-offs, limits, and priorities. You can think of it as an intelligent queue of React components in one “slot”. The ATC engine will automatically determine what order and when to show them. The rules can be useful to keep the user experience from getting spammy as your team launches more experiences at the same time. For instance, you can set it up so you only show one announcement modal per day max, or spread out in-app nudges to upgrade over a few weeks time.

We were surprised by how hard it was to build this. The main challenges were: In order for the engine to respect the cool-offs and limits, we had to dig deep into the React rendering lifecycle to prevent the same component from rendering twice. This can happen when the same component is used in multiple Collections across the DOM tree. This is tough because a component can adhoc show up at any given time without notice due to the nature of dynamic web applications. We solved this by building a centralized client-side registry that keeps track of the DOM tree.

Air traffic control is decided server side, and we knew we didn’t want to keep a web socket open indefinitely to render a simple component. So, we had to come up with a performant scheme that allowed the ATC logic tree to be transferred on initial render so the client-side can determine when each component should get rendered. For the first release, we offer a library of pre-built React components that can be easily launched in your web application. We’ll soon be adding the ability to launch any custom React components as well.

We built this server-driven UI approach because we believe it provides teams an option that balances quality and speed. It’s also how companies like Uber, Pinterest and Rippling build and launch these in-app experiences internally, as well.

Compared to some of the existing no-code tools in the space, we believe this approach offers more control and flexibility. We like the idea that product and engineering can define the boundaries and designs of what non-technical teammates can launch in production. Especially when compared to similar tools where content can be injected any which way with WYSIWYG editors on top of an otherwise carefully crafted web application.

What do you think about this approach? Have you built these kinds of flows in-house before or used one of the injection-based no-code tools? I’d love to hear any feedback or ideas on the launch. And feel free to play around with Collections yourself for free at frigade.com!