The objective I’m trying to achieve using builder as a component in a platform-agnostic ads/marketing funnel service. I.e whatever website the client is using, I can hop in there, add the routes nessecary to support the funnel (or page if SPA approach), drop the builder template inside the page(s) and content renders as a pure web component (not complicating tracking with iframes) or html/css/js if encapsulation is not needed and essentially achieve the goal of quickly bootstrapping a funnel on their website rather than having a seperate set (or single) landing page(s) hosted on an external “marketing/landing page mini site”, that routes awkwardly back to their main website on CTA engagement or header/footer links if any.
The hope is that with these ready-made set of templates/funnels I can easily inject them in given client site while not adding to much complexity to analytics tracking, some event listener configuration may be needed when using web component encapulsation, or otherwise no complexity at all when I don’t need encapsulation via the html/css/js option.
While I could use webflow for the same effect for a template repo, not having the encapsulation option of ready-made webcomponents created from a simple editor when needed steers me towards using builder.io, but not if iframes are required.
As I’ve gone about testing this I’ve encountered a few challenges to adapting builder for this use case.
I noticed with dynamic rendering using either html/js/css or web component embed is it uses an iframe within the tree structure where it is actually instantiating builder content in the main container, which introduces the analytics tracking complexity I want to avoid. I recognize even without an iframe (encapsulated as a pure web component) there’s still some annoyance interfacing with the shaow dom via an event listener but this is still infinitely perferrable than having to deal with exposing iframe usage data as if its a natural part of the website integrating with the on-site analytics container/google ads etc.
So my first question is why dynamic rendering for the web component or html/css/js option does the container project the content through an iframe rather than serializing the jsx payload into the web component without an iframe which seems like the way it’s intended to render as shown in the static rendering snippet? I still have to test static rendering as I would be okay with dropping the exported code in a html/css block and updating it as needed if it means I can avoid having to use an iframe.
The second question starts with the unexpected observation in which I noticed templates are not shareable across spaces under the same organization. This again greatly challenges the value proposition as far as content reuse, but I guess if there is still a decent workaround to this in form of say exporting the html/css/js for a template in a given space and reimporting it into another space via the “import from website” content is possible, or something better, is of great interest to me. I still lose the value of a centralized highly available/easily searchable repo of highly quality templates/funnels across clients (is there a plugin that supports sharing templates across spaces?).
Hope I made sense!
Thanks