Render static resources

[kptdobe]

Static resources (css, client side js...) are not rendered anymore. The temporary trick is not working anymore. See https://github.com/adobe/petridish/blob/master/src/HelixServer.js#L106-L115

[kptdobe]

There are 2 types of static ressources that should be rendered:

• web resources (JS, CSS, images, icons, fonts...) coming from the code repo
• assets (like images, a pdf file...) coming from the content repo via

In both cases, Petridish must fetch the content from the proper repo and deliver it with the proper content type.

In helpx, we have a sample of each:

• a css file and an image referenced by the code
• some images referenced by the content like https://github.com/Adobe-Marketing-Cloud/reactor-user-docs/blob/master/.gitbook/assets/loop.png being referenced in https://github.com/Adobe-Marketing-Cloud/reactor-user-docs/tree/master/getting-started

[tripodsan]

• webresources will probably be bundled via webpack/parcel and then deployed somehow :-)
• images in content would need to be streamed directly from the edge server

[kptdobe]

webresources will probably be bundled via webpack/parcel and then deployed somehow :-)

We only need to think that if as a developer I store the files under ./src/static but they get magically deployed under /dist something magic, either I know how to target those files in my htl (should I put /dist or /static or /src/static...?) or the path get re-written for me or I get an ${it.staticResourcesPath} helper to prepend to all my references.

images in content would need to be streamed directly from the edge server

In development, I think I need them to come from the git content repo because that's where they live for the moment. In production, different story certainly.

[trieloff]

Images in content:

• in production they get mapped based on the file extension, i.e. png, jpg, gif, all go to the Fastly image service, backed by GitHub
• in development, I'd keep the mapping, but skip the optimization

Web Resources

• let's define a base path that can get mapped to the "static asset pre-packagaging and delivery function" - I'm fine with /dist, /libs, but not /cq.clientlibs
• it.staticResourcesPath is a great candidate for the context variable in pipeline
• in code, let's keep the base path configurable, but we can start with /src/client

[tripodsan]

ideally the delivery layer exactly knows where the find the resources based on the URL so that it doesn't need to issue multiple requests to find them. even for development, if an image is in the content or an image is in code; how should the server distinguish?

one possibility is to prefix all content resources with /content (haha). and to prefix code resources with /lib. eg:

<script src="/lib/main.js" />
...
<img src="/content/logo.png" />

CSS with images:

src/styles/main.css:

fancy {
   background-image: url('fancy.png'); // will reference 'src/styles/fancy.png
}

when the bundler/packager processes the css above, it will create some sort of bundle.js which then is placed in ./dist/client and would beed to be deployed as well to the CDN. for testing in development, it should probably be available as well. so maybe via a /lib -> /dist/client resolution.

[trieloff]

I don't think we can force all content into /content, but having a /libs, etc. directory for "static" resources should be fine.

In your CSS with images example, we can have the (another instance) packager run with hlx up. In the simplest scenario, it would just copy files into /dist and we deliver it from there (I don't like the magic of having the filesystem dist becoming an HTTP libs btw.)

In production, we would want to have things like content-hashed path names, so that we can get better client-side cache efficiency.

"Deploying to CDN" then means deploying to a service that the CDN can call (and that has reasonable caching semantics)

[tripodsan]

Implemented the following behaviour:

• if the extension is .html or .md the server does the normal script processing
• if the path starts with /dist/ the resource will be streamed from ${distDir}/
• otherwise it tries to stream the resource from the content repository.

The default for the ${distDir} is .hlx/dist.

what's missing now is support from helix-cli. see adobe/helix-cli#49