[HN Gopher] Show HN: Launch React components in your app with no...
___________________________________________________________________
Show HN: Launch React components in your app with no-code
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!
Author : pancomplex
Score : 26 points
Date : 2024-08-06 14:25 UTC (2 days ago)
| recursive wrote:
| How tightly coupled is this to react? Is there any chance to use
| this in a SPA-framework-agnostic way?
| pancomplex wrote:
| Not tightly coupled to React. You can use it with our Vanilla
| JS SDK that works with any Javascript stack
| (https://www.npmjs.com/package/@frigade/js) using the
| `getCollections` function:
| https://docs.frigade.com/v2/sdk/js/frigade#getcollections
| namanyayg wrote:
| It seems like you are targeting non-tech users, is that correct?
|
| While you have created something technically impressive, I'm
| afraid that it looks way too complex for any layman.
| lordofmoria wrote:
| I actually disagree with this - HTML5/jsx is not a bad UI-
| building abstraction even for non-technical people. The things
| that make react complicated are syncing state with the backend,
| routing, etc.
|
| I'd share this with my CEO / CS team - especially with GPT in
| place and live previews, there's no reason why someone can't
| build simple react components into these "slots".
| bdcravens wrote:
| HTML in its basic form is a technical task for many.
| pancomplex wrote:
| Good news is you're not required to write any HTML when
| your engineering counterpart has wired up your component.
| We have a visual editor powered by Tiptap that anyone can
| use
| 98codes wrote:
| You are severely overestimating the average person's ability
| and understanding.
|
| Relevant XKCD: https://xkcd.com/2501/
| pancomplex wrote:
| We're targeting non-tech users who have some engineering
| resources available to wire up the React components. Once wired
| up, any non-tech user can deploy new versions of the same
| component without writing any code themselves (I demo this in
| the YouTube video around here:
| https://youtu.be/qrPip41Ecyg?feature=shared&t=70 ).
| 98codes wrote:
| I can tell that you're trying to make this work, and I very
| much appreciate the effort, but where is the no-code part?
| The YAML is definitely code. HTML & CSS are code. My rule of
| thumb: if you screw up the punctuation and that causes the
| thing to break, that was code.
|
| Second, too much zooming. It was really hard to wrap my brain
| around what was going on when everything was moving around so
| quickly.
| samstave wrote:
| @Dang -- One of the most lovely things about HN is how, when
| suddenly, a lot of same-vein ideas pop up that when seen
| holistically can all be leveraged if you're keenly watching (HN
| Lego as it were...) :-)
|
| @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.
| pancomplex wrote:
| I am not too familiar with Magic Loops, but really there's
| nothing stopping you from building such a pipeline. Frigade
| allows you to use any schema for your content and state
| management.
___________________________________________________________________
(page generated 2024-08-08 23:01 UTC)