Hey HN! I've built a way to launch simple, stateful React components like promotions, banners, and announcements in your web app through reusable in-app UI channels. Here's a demo of how it works:
https://youtu.be/qrPip41Ecyg. The docs are here:
https://docs.frigade.com/v2/platform/collections.
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!
@pancomplex -- Love it.
What I am pinging above about is that I was posting yesterday in response to "Structured outputs" from OpenAI [0] -- and then Magic Loops founder chimed in.
This seems Perfect! for what I was describing in that comment thread:
So with Frigate, I can have non-code-non-tech inputs into an app, such as you state, by linking the FlowID and load a Magic-Loop Snippets, and have micro-prompt widgets in a react app/dash that can poll and include whatever data is important. (wait until txtai libs are used in these Frigates)
So, imaging that you want a flow that has a component where you take a MagicLoop to poll for a particular thing, then include that ML (smart AI crons jobs) - and embedd them into the flow, and have it hit the page - so you get multiple layers of abstraction, with a deeper level of tools that can provide some really interesting ways users can add functions to their app based on Frigate...
---
Does this make sense? (dopamine is plentiful this AM)
https://news.ycombinator.com/item?id=41173223#41176823
---
I really like this - and I am working on something that can fully use this - I just don't have time till later in the weekend to attempt to integrate - but this is a functionality that I really do need - and if I can integrate it in the way I hope to -- ill show it to you.