Add: Explain how to run a function inside an inline script after the dom is loaded

[paolotiu]

When using an is:inline or define:vars on a script it becomes inlined in the served code 1:1. So, when someone wants to target an element further down the html (ex. document.querySelector("#footer")), they might be inclined to use defer or async since that's what is taught in vanilla sites. It won't work though since the defer or async attributes don't actually apply.

I think we should add in the docs how to achieve this behavior using document.addEventListener("DOMContentLoaded, fn)

Willing to make a pr btw

[sarah11918]

Thanks for this comment @paolotiu, and for being willing to make a PR! Would you be willing to just type in here what you would PR, so we can take a look at it, and think about where (on which page, in which section) it might actually best go?

[sarah11918]

Hi @paolotiu - just following up here: are you still willing to give an example here of what you would PR, and where you think it would go in the docs?

[paolotiu]

Hi @sarah11918! Sorry for the late reply. Here's a draft of what I would write.

is:inline doesn't get processed by the astro compiler, so it will load as is where it is placed. This means some dom contents may not have loaded when the script runs. If you want to target dom nodes, it is recommended to use document.addEventListener("DOMContentLoaded, fn) . This waits for the whole dom to load before the script runs.

Note: defer and async attributes currently do not affect the script, so using document.addEventListener("DOMContentLoaded, fn) is the only way to target dom nodes below the script.

[Jutanium]

I'm not sure that documenting how to use DOMContentLoaded (and its alternatives) fit within Astro docs (but might be a great addition to a future restructuring where we have room for guides or recipes). Trying to access elements too early is really an HTML/JS concern, and an involved one to explain thoroughly!

As for defer and async - these do not work on inline script tags in normal HTML, either, as far as I know. That said, guarding the user from the potential gotcha of using defer or async could be part of the task of documenting is:inline and explaining what it means for the script to be inline. I added a bit of clarification in #1568.

Thanks for bringing this to our attention!

[paolotiu]

Agree! I think clarifying is:inline would be a better since its in the scope of Astro. Thanks for the work dan!