helix-cli reload collateral resources

Is your feature request related to a problem? Please describe. when developing on collateral resources, like the nav or the footer, reloading (re-previewing) their content is not ideal. one has to click preview in the word/google doc, which then opens a new page etc.

the reload button of the sidekick in the developer mode is great, but it should be extendable to included content (also content fragments).

Describe the solution you'd like

the cli should record which resources belong to the currently developed page and somehow tell the sidekick.
the sidekick should offer a drop-down button for all content to be reloaded

/cc @rofe

Aug 31 '22 06:08 tripodsan

I don't think this problem is limited to development only, it is also very much present when working on the content in preview. So I'm not sure the CLI is the right place to solve for it...

Maybe a better solution would be to add a wrapper for fetch to scripts.js, which we would then consequently use (and advertise) for fetching same-site content. This would allow us to record dependendies into e.g. window.hlx.dependencies which the sidekick could use to publish them all.

Wdyt?

Sep 02 '22 10:09 rofe

This would allow us to record dependendies into e.g. window.hlx.dependencies which the sidekick could use to publish them all.

yes. this is even a better solution - as long we use a javascript proxy for fetch, and not swizzle its methods. this could later also be used by the sidekick to offer edit buttons for collateral documents / fragments.

Sep 02 '22 11:09 tripodsan

I just realized that with manifest v3, the sidekick extension will no longer have access to window globals, so we'll have to persist the dependencies in the DOM, e.g.

in the fetch wrapper:

const docData = document.documentElement.dataset;
const deps = docData.dependencies && docData.dependencies.split(',) || [];
deps.push('/footer');
docData.dependencies = deps;

resulting in something like

<html data-dependencies="/nav,/footer">

which the sidekick can retrieve in the publish action:

const deps = document.documentElement.dataset.dependencies?.split(',);

wdyt?

Sep 07 '22 13:09 rofe

so we'll have to persist the dependencies in the DOM

good idea, but I wouldn't add it to the <hmtl> element. maybe to the header or adding a <meta> tag? eg:

<meta name="dependency" content="/nav.html" />

or via Link element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link

maybe using a non-standard:

<link rel="fragment" href="/nav.html" />

Sep 07 '22 15:09 tripodsan

Why not as data attribute on the <html> element? It's about dependencies of this document 😄

If we want to add it as a separate element to the <head>, I'd use the <link rel="fragment"> you proposed (or <link rel="dependency">?)

@davidnuescheler wdyt?

Sep 07 '22 19:09 rofe

yeah, i agree that this is not primarily a dev problem as devs normally figure out what needs to happen to reload the respective pieces.

i think there is a more general issue with cache handling in browsers with fetching .plain.html and somehow it would be great to be able to detect a reload (or a hard reload) in the helix lib and circumvent browser cache somehow on fetch... i am not sure what the solution should be, but maybe we isolate a project where this is a frequent / common issue, and prototype something.

Sep 07 '22 19:09 davidnuescheler

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigation/type interesting...

Sep 07 '22 19:09 davidnuescheler