New headless mode feature #105

[reisfmb]

Summary:

My approach was to implement a lib "metadata" that abstracts the logic on the page processor.

That lib is then used on the page processor, without changing the logic previously defined.

This same lib is also used in a new "metadata" service, which purpose is to provide an endpoint that mimics the logic on the page processor having in mind the headless approach, i.e, returns a json in which the frontend can consume and inject the proper metadata:

Finally, to avoid hydration errors, a new "headless mode" checkbox config was set. If set to false (default value), then the app will work in the same way as it was. If set to true, then page processor will do nothing and the "metadata" service will be available:

[reisfmb]

Points for improvements:

• Improve name of this function. Suggestions?
• Both getMetaData and getTitle depends on site, siteContent and siteConfig, which are returned from the get function. Since both are executed on the same scope on the page processor, we can improve it making both getMetaData and getTitle functions accept site, siteContent and siteConfig as props, and only run the current get function once.

[reisfmb]

Here is an example of the usage of the app on headless mode in site-enonic-next

[alansemenov]

Improve name of this function. Suggestions?

getContentAndSite or getContentProps

Both getMetaData and getTitle depends on site, siteContent and siteConfig, which are returned from the get function. Since both are executed on the same scope on the page processor, we can improve it making both getMetaData and getTitle functions accept site, siteContent and siteConfig as props, and only run the current get function once.

Yes, we should do that.

I would also stay clear of one-character variable names, unless it's a simple counter.

const g = get(contentPath);

Should be something like

const contentAndSite = getContentAndSite(contentPath);

[reisfmb]

@alansemenov

Implemented those improvements + helpful console warnings in case of service failing to retrieve data.

Tested the usage of the app on site market locally, with headless mode enabled and disabled and it seems to be working just fine!

If approved, I think we're good to go with a release.

[poi33]

The frontend should disable page processing. As we do in the nextxp proxy: enonic/lib-nextxp@fc72d37

[reisfmb]

Why?

[poi33]

You usually don't want the backend to modify your frontend html. (Currently headless often only does this inside xp/content studio rendering and not live)
The extension of this app is made to access the data for the frontend.

I guess it boils down to if you want to disable this on every app or one global place for all headless to disable. I think the fontend should deal with it.

[sigdestad]

I did not read through all the details here, but I'm confident we should not have checkbox called "headless mode". Basically, the preview can prevent injections from this app by setting the "post processing = false" in the response object.

At least if SEO metafields makes uses this feature to inject markup