Decoupling from Craft.js After Layout #261
Replies: 1 comment
-
It depends on your use case, but what you describe is more or less the correct approach. The easiest thing to do is to just grab the static markup and use it however you want. You can grab the innerHTML, write your own renderer, or simply pass the entire Editor context to:
If you want to do something more sophisticated and dynamically generate the components outside of Craft, you have all the data you need (props, component resolver, etc. -- you don't really need to create and maintain two separate components either). There's some more information in this issue that you might find useful. Good luck. |
Beta Was this translation helpful? Give feedback.
-
I just discovered this project a couple of days ago. It looks super-cool and seems to provide some really neat patterns out-of-the-box. Additionally, I started working through the getting started guide (there seem to be some bugs in there and I also hit a snag where it's telling me my Elements don't have an
id
property, even though they definitely do, but that's not what this is about).In my head I'm imagining a page builder that lets you choose a data object, bind properties from that object to properties of user components, and lay out some kind of image/page. From what I've seen and read so far, this seems like something that's very possible with craft.js and some elbow grease. I'm curious about what happens after you lay everything out. It seems like the user components must be built in such a way that they always expect to be rendering inside of the Craft.js framework.
Has there been any thinking around what it might look like to use Craft.js to lay everything out and set the properties, but when it's done, be able to render the content (non-editable, of course) without Craft.js? I realize that the bundle size for Craft.js is only somewhere in the 40-ish kB range, but the environment in which I'd be rendering the final content must keep it's bundle size as small as possible for compliance reasons.
In thinking through this scenario, I can imagine a world where you implement each component twice—a Craft-able version that's coupled to Craft.js and a "vanilla" version that's not. Then you could use Craft.js to lay everything out, export the component hierarchy/properties and then re-hydrate the vanilla components with that data without Craft.js.
This probably sounds crazy, but I'm curious to hear others thoughts on the matter.
P.S.
As I said, I just discovered this project a couple of days ago, so I know very little about its internals. Maybe it's possible to provide some of the Craft-related features (like
Element
) as some kind of prop or runtime-modifiable hook/function so that instead of putting an<Element>
directly into a user component, you could callmakeElement(...)
or something. In a Craft-able environment that would return an<Element>
with children and such. But, in the non-Craft environment, maybe it does something like return a<>
fragment. I'm sure this is way oversimplified and I have no intention of suggesting that the project maintainers make a change like this just because I'm thinking of a weird use case.Beta Was this translation helpful? Give feedback.
All reactions