We are using designsystem, where the different basic elements (buttons, text areas,…) are generated with their look&feel and can be exported as ReactJS components.
We need to find the best way integrate our designsystem with Enonic XP, and we have thought about the following scenario. Think about an article:
Editors would create articles in Enonic XP
Text and images from the article would be delivered via headless to a frontend app hosted on Enonic Cloud
That frontend app would import the ReactJS components from designsystem and bundle all together with the headless content into an article with appropiate layout and look & feel. This app would be hosted in Enonic Cloud.
Questions
Can you think of a better option to do that?
Can Enonic components (parts, mixins, macros,…) be delivered in headless mode?
Can JS and HTML be delivered in headless mode from Enonic to the frontend app?
On step 1 - since the designsystem is not in Enonic XP, how could we make it WYSWYG?
Will the app be a part of another page, or will it be a standalone app?
Why are you assuming the designsystem will not be in XP?
Could you give an example of how the react components will affect the article (beyond the CSS that is)
Here are some preliminary answers:
XP can be used to deliver pre-rendered content (html) by accessing its url. This requires rendering to be setup in XP naturally. However, there is currently no out-of-the-box serverside react lib for XP.
We are working on a project for serverside react - called react4XP. The plan is to support dynamic handover to clientside with hydration, after rendering the initial markup on the server.
You can easily define templates to preview your content using serverside rendering (without React) or by using client side React + headless content.
You can access “raw” headless data from XP using the Guillotine project (graphQL).
You can also customise XP to deliver the data in your desired format with a custom endpoint.
In regards to the accessing page components “headlessly”. The data defining the components are also available in headless mode. Accessing these data will be simplified in our upcoming release of Guillotine, where the page structure can be accessed as a simple JSON document, rather than the current structure.
Each component (within a page) can also be rendered directly as html if you know it’s URL.
XP can also serve the application’s Javascript, which would only be natural if you are delivering the app from XP anyway…
To follow up on art, today our system separates page data and browser rendering. The CMS delivers a page containing a data structure, and a front side react application rendering the web page using our “Designsystem”. So yes, it’s a web app.
The Designsystem is reused for other interactive web pages as well, not delivered by our CMS. A goal on our part would be to not have to recreate in html for the CMS what the Designsystem already delivers thorugh Reacy.
Our solution today has a couple of draw backs.
First, there is no server side rendering, making search engine indexing troublesome, and the time from page request to content shown to long.
Second, the application is restarted on every page. It would be a much more responsive page, we think, if the web app only needed to pull the data structure from the server for each new page. Of course, the url would have to be updated as well, making sure direct access to each page is still possible.
What we are exploring is the best way to integrate our existing React based Designsystem with our new Enonic installation. Of course, the final user experience is more important than not having to write and maintain some additional html files.
Thanks for the details.
From how I understand this, you are aiming to build a website, that “feels” more like an application. I.e. minimal full reloads etc. Still, you need to handle every URL request properly.
Even if this can be implemented, there are many special cases to consider.
You will need to implement delivery of the app from any page in the CMS (should be easy)
You will need to implement page templates logic in the front end, as well as pages.
To make this work with the XP page editor will likely require a LOT of special handling.
Finally, as you mention, user experience might not be that great after all, without serverside rendering and lagging initialization.
Until an out-of-the-box and best practice package for serverside react on XP is available. I would recommend using traditional server-rendered markup for most parts of your site, and focus on using client-side rendering only for the interactive parts of your site, i.e. forms, calculators, banners etc.
All in all, this will be more cost effective, work properly with the page editor, provide the best SEO, and finally provide the best User experience IMHO.
Until there is an “out-of-the-box” approach for Right now, I would