#How to use <script> in a synchronous way?

21 messages · Page 1 of 1 (latest)

tawny pelican
#

If I have an Astro component and it has the following:

<script>
  import from 'core-js/stable';
</script>

I need this to be synchronous and NOT load any child components until core-js is imported. How do I go about this?

hollow knollBOT
#

Hi @tawny pelican. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Hmm, I don't know enough to give you a confident answer yet. The provided extracts do not contain specific information on how to make an import synchronous in Astro or how to delay the loading of child components until a certain module is imported.

However, Astro does support the use of JavaScript imports in your components, and it automatically handles the bundling and optimization of these scripts. You can use the <script hoist> tag to include JavaScript files in your Astro template, and Astro will include the JavaScript file in your final build.

<script hoist>
 import './some-external-script.js';
</script>

Astro will bundle this external script with the rest of your client-side JavaScript, and load it in the type="module" script context.

For more detailed information, you may want to refer to the Astro Documentation (https://docs.astro.build).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@tawny pelican kapa.ai is still learning and improving, please let us how it did by reacting below

tawny pelican
#

@hollow knoll we're seeing this error in Sentry: G.at is not a function which tells me that our core-js polyfill is not loading in time before our code makes use of Array.at()

hollow knollBOT
#

Let me check the knowledge base for you. One moment! :books:

#

Based on the provided extracts, it seems like you're encountering an issue where a polyfill from core-js isn't loading before your code runs. This could be due to the asynchronous nature of JavaScript imports, which might cause your code to execute before the polyfill has been fully loaded.

Astro doesn't provide specific guidance on handling this situation in the provided extracts. However, it does mention that the renderer automatically handles adding appropriate polyfills for support in browsers that don’t have Declarative Shadow DOM. The polyfill is about 1.5kB. If the browser does support Declarative Shadow DOM then less than 250 bytes are loaded (to feature detect support) source (https://docs.astro.build/en/guides/integrations-guide/lit#polyfills--hydration).

For more specific guidance on how to ensure that your polyfills load before your code executes, you may want to refer to the Astro Documentation (https://docs.astro.build) or the documentation for core-js.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@tawny pelican kapa.ai is still learning and improving, please let us how it did by reacting below

tawny pelican
#

@hollow knoll isn't Astro's <script> default behavior supposed to bundle the code? loading it shouldn't be an issue?

hollow knollBOT
#

Let me check the knowledge base for you. One moment! :books:

#

Yes, you're correct. By default, Astro processes, optimizes, and bundles any <script> tags it encounters in your components. This includes handling any imports, allowing you to import local files or Node modules. The processed script is then injected into your page’s <head> with type="module". This behavior is designed to optimize loading times and improve the user experience (source (https://docs.astro.build/en/guides/client-side-scripts#script-bundling)).

However, there are some exceptions to this behavior. For instance, if you add any attribute other than src to a <script> tag, or if the script is written in a JSX expression, Astro will treat the tag as if it had an is:inline directive. This means the script will be rendered into the HTML exactly as written, and local imports will not be resolved (source (https://docs.astro.build/en/guides/client-side-scripts)).

If you want to avoid bundling the script, you can use the is:inline directive. This will render the script into the HTML exactly as written, but local imports will not be resolved and will not work (source (https://docs.astro.build/en/reference/directives-reference#isinline)).

In your case, if you're importing core-js in a <script> tag without any other attributes, Astro should be bundling the script and handling the import as expected. If you're still encountering issues, it might be worth checking if there are any other attributes on the <script> tag that could be affecting Astro's default behavior.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@tawny pelican kapa.ai is still learning and improving, please let us how it did by reacting below

elfin canyon
#

been the default for a long time

#

you would mark the script is:inline to opt out

#

and that would make it execute synchronously (render-blocking)

#

although npm packages are only usable in hoisted/bundled scripts

tawny pelican
#

yeah.. I figured. just curious why I'm seeing G.at is not a function in our errors

#

it's impossible for .at() to not be polyfilled

#

I figured it was a race condition..but.. again, not possible if the core-js code is bundled

#

if I open BrowserStack, fire up Safari 13, go to our site, and type [].at, it does return a func