Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reload collateral resources #2057

Open
tripodsan opened this issue Aug 31, 2022 · 7 comments
Open

reload collateral resources #2057

tripodsan opened this issue Aug 31, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@tripodsan
Copy link
Contributor

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

@tripodsan tripodsan added the enhancement New feature or request label Aug 31, 2022
@rofe
Copy link
Contributor

rofe commented Sep 2, 2022

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?

@tripodsan
Copy link
Contributor Author

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.

@rofe
Copy link
Contributor

rofe commented Sep 7, 2022

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?

@tripodsan
Copy link
Contributor Author

tripodsan commented Sep 7, 2022

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" />

@rofe
Copy link
Contributor

rofe commented Sep 7, 2022

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?

@davidnuescheler
Copy link
Contributor

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.

@davidnuescheler
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants