plentico / pico

Svelte-like reactive UI compiler written in Go
2 stars 0 forks source link

Dynamic Components #15

Open jimafisk opened 3 months ago

jimafisk commented 3 months ago

A core concept of Plenti is content-driven components, aka an editor can add/remove/rearrange components on a page simply by editing their content and without having to write any code. A developer/designer can keep the site within their styleguide by establishing a predefined list of components that should be used in each scenario. All of this is powered by the concept of dynamic components.

Most frameworks have this, in Vue I believe it looks like:

<component :is="component"></component>

In Svelte it looks like:

<svelte:component this={component} />

I always thought this ^ implementation in Svelte was unnecessarily complex, since you need to pass a component constructor to this and can't simply pass a path string that points to a component.

In trying to build this compiler / template engine, I like to start from what I want the syntax to be first, then work back to how to write the code to achieve that (forcing the syntax conform to your code can create challenging DX). My initial thought was you could name your component whatever you want and give it a path like:

<Mycomp="./mycomp.html" />

Then I was thinking the shorthand could be:

<="./mycomp.html" />

Thinking upon it more, I feel like we should only support the shorthand option. The Component name is never actually usefully in the first scenario. Component names are only used in statically imported components to tie the instances of their use throughout the dom to their declaration in the fences/script. Since a dynamic component moves the path to the component itself, the name is actually irrelevant. In general, I'd like to opt for one single syntax for achieving things where possible (similar to Go) because I feel like JavaScript's biggest problem is individual flare that everyone throws on everything that yields no creativity in output but obfuscates the underlying codebase. It also makes it much hard to write tooling around tech that does this, when creating Gopack I needed to accounted numerous ways of writing imports, which is frustrating and has no positive gain for anyone in the ecosystem.