feature request: allow resource precompiling

[jantimon]

the @adobe/htlengine supports two ways to include content into a template:

data-sly-call

The directive data-sly-use is executed during compile time and uses the @adobe/htlengine templateLoader to include the html file.
During runtime it executes the template:

<sly 
  data-sly-use.teaserItem="project/components/content/articleTeaser/teaserItem.html"
  data-sly-call="${primaryLinkTmpl.teaserItem @ someData=something}"
/>

data-sly-resource

The directive data-sly-resource is executed only during runtime and therefore we are not able precompile the template in project/components/content/articleTeaser/teaserItem although it is already known.

<sly 
  data-sly-resource="${'teaserItem' @ resourceType='project/components/content/articleTeaser/teaserItem'}"
/>

will be compiled to: const var_resourceContent1 = yield $.slyResource("teaserItem", {"resourceType": "project/components/content/articleTeaser/teaserItem", });

Would it be possible to add a feature similar to the defaultModuleGenerator which allows custom precompiling for data-sly-use also for data-sly-resource?

The main motivation behind this feature request is the goal to run data-sly-resource inside a browser without the need of a running server to render the resource template.

Right now the compiler accepts a moduleMap with the argument called mods:

const parseResult = await this._parse(source, baseDir, mods);

One idea how we might achieve add is new feature would be to rename mods to meta and allow a substructure like this

meta = {
   mods: { /* all previous module mappings */ },
   resources: { /* resource values */ },
}

That way we could add a preprocessor api for the resources and allow modifications during compile time:

compiler
  .withResourceLoader(function(resource) {
     console.log(resource); // -> {"resourceType": "project/components/content/articleTeaser/teaserItem"}
     return JSON.stringify(resource);
  })

[tripodsan]

The problem is that the resource that is included depends on dynamic variables. your example is an edge case, where you know the resource type before hand, but most often, the resource type is based on the content, like in the accordion component:

https://github.com/adobe/aem-core-wcm-components/blob/2053e43ac0143da3b16de25414a07e9a962fcede/content/src/content/jcr_root/apps/core/wcm/components/accordion/v1/accordion/accordion.html#L39

I think it would be possible to create a list of resource calls during compilation, so that you can detect the ones that have static component type reference, and precompile and pre-render those components.

but the actual resource include still needs to happen during runtime. but your resource resolver can then fallback to the pre-rendered ones.

---

The main motivation behind this feature request is the goal to run data-sly-resource inside a browser without the need of a running server to render the resource template.

Storybookjs/aem makes this happen by configuring all possible components. Also, the story itself provides the content, so the resource resolver can be purely client side:

https://github.com/storybookjs/aem/blob/master/app/aem/src/client/preview/helpers/ResourceResolver.ts

---

ps: As a side note: in AEM, the resource include could also be served by a JSP or servlet, as it depends on the component resolution....

[jantimon]

hey @tripodsan

thanks for explaining the dynamic resource loading - as you already assumed I had only the static case in mind.

I think it would be possible to create a list of resource calls during compilation, so that you can detect the ones that have static component type reference, and precompile and pre-render those components.

Although it would work only for static cases it would still be really awesome to reduce the amount of wiring efforts and to reduce maintenance efforts.
Especially for nested resources loading inside resources and templates.

The approach in AEM Storybook is probably the best possible way to solve dynamic resource loading and/or to work as fallback 👍

Thanks also for bringing up jsp and servlet cases - for me these cases are not relevant but obviously it is important to keep them in mind.

ps: regarding the accordion - I know this is the correct way to handle it in AEM (and that's totally fine) but modern template languages handle those cases slightly differently by providing the html directly into components as described in adobe/htl-spec#67