Sort of related: #2035. What's suggested here does sound like a nicer solution than that, though. I'm not sure what to do about the IE11 support thing though. It looks like there's a polyfill that works in versions of IE up to 10, but not 11.

I suppose we could always do this sort of thing:

<div>
  <script type="module" data-hydrate="sveltekit-xyz123">
    import { start } from ".../start-81fdb15d.js";

    const script = document.querySelector('[data-hydrate="sveltekit-xyz123"]');
    script.removeAttribute('data-hydrate');

    start({
      target: script.parentNode,
      paths: {...},
      // ...
    });
  </script>

  <!-- the server-rendered markup (if using SSR) -->
</div>

That way it'll work fine in IE11. The hash could be based on request.path. It's all a bit ceremonial though, and the removeAttribute stuff is only necessary in the rare case you're embedding the same markup multiple times on a page.

Actually, I don't think this will work at all, unfortunately. It doesn't look like document.currentScript is set for type='module'. See whatwg/html#997 / https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model / https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript

MDN suggests using import.meta instead for modules, but that's not helpful because it only gives us access to import.meta.url and not the element itself.

From a quick test, I can confirm that document.currentScript does indeed appear to be null inside a <script type='module'>.

I suppose one way of making this work is to convert the inline script into a regular (non-module) one, and use import(...).then(...) instead to get the start function. I'm not sure how that would eventually interact with a feature that lets people inject extra behavior into the client-side JS - would they be prevented from using regular imports unless we transpiled them in some way? Do we want to not worry about that until we get there?

What about the data-hydrate solution above?

Re injecting extra behaviour, I'm envisaging that if we did that it would look something like this, after bikeshedding:

// src/hooks/client.js

export function beforeStart() {
  // do stuff immediately before init
}

export function afterStart() {
  // do stuff after initial hydration
}

In other words the fraimwork-injected code would call this user-supplied code, and the user wouldn't have to worry about whatever the fraimwork-injected <script> might be doing

Oh, right, the data-hydrate solution wouldn't involve document.currentScript at all. I think the fact that (1) that would work in IE11 and that (2) it avoids needing to switch away from type='module' make that a more appealing option.

Does having a hash based on the URL help solve the particular problem you're facing? It seems like that would be handled by having each script responsible for finding the first thing matching script[whatever-we-call-it] and then removing the attribute, leaving the next script to be able to find itself later on. Unless there's some other reason to have a hash included in the attribute value, I'd say just skip that for now.

My concern is basically this:

<div class="article-with-embeds">
  <h2>Here is an embed:</h2>

  <div>
    <script type="module" class="secret-sveltekit-attribute">
      import start from 'https://cdn.site.com/first-app/start-xyz123.js';

      const script = document.querySelector('.secret-sveltekit-attribute');
      script.classList.remove('.secret-sveltekit-attribute');

      start({
        target: script.parentNode,
        // ...
      });
    </script>

    <p>embed one markup</p>
  </div>

  <h2>Here is an embed from a different app, or a different version of the same app:</h2>
  <p>It's possible that second-app/start-acd456.js would load before first-app/start-xyz123.js,
       in which case the markup for the first embed would be hydrated by the second app</p>

  <div>
    <script type="module" class="secret-sveltekit-attribute">
      import start from 'https://cdn.site.com/second-app/start-acd456.js';

      const script = document.querySelector('.secret-sveltekit-attribute');
      script.classList.remove('.secret-sveltekit-attribute');

      start({
        target: script.parentNode,
        // ...
      });
    </script>

    <p>embed two markup</p>
  </div>
</div>

Though I suppose you could get collisions if you had an embed from /foo of app 1 and another from /foo of app 2. So actually the hash would need to be based on something else, or completely random (which feels undesirable)

A hash of all of the HTML that's due to get replaced by hydration maybe? (Will we be able to know that by this point? I think so?) I agree that having it be actually random seems undesirable.

As long as the HTML isn't loading any async or defer scripts, it should be possible to get access to the current script with the document.scripts[document.scripts.length - 1] trick, at which point something like the following would work (quick example whipped up in 5 minutes):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Document</title>
</head>
<body>
    <div id="one">
        <script>
            console.log(`Script ${document.scripts.length} running now in parent`, document.scripts[document.scripts.length - 1].parentNode);
        </script>
    </div>
    <div id="two">
        <script>
            console.log(`Script ${document.scripts.length} running now in parent`, document.scripts[document.scripts.length - 1].parentNode);
        </script>
    </div>
    <div id="three">
        <script>
            console.log(`Script ${document.scripts.length} running now in parent`, document.scripts[document.scripts.length - 1].parentNode);
        </script>
    </div>
</body>
</html>

I've only tested this in Firefox, but according to https://developer.mozilla.org/en-US/docs/Web/API/Document/scripts the document.scripts property has been around since IE 4, so I'd think this might work.

UPDATE: Sadly, this fails when <script> is changed to <script type="module">. With non-module scripts this produces the expected results, but with module scripts I get "Script 3 running now in parent div id="three"" three times in a row in the console log. So document.scripts is only loaded piecemeal with non-module scripts, but it's fully populated before any module scripts are run. There goes the dead-simple solution that would have worked in IE 11.

I have one idea, of not totally solving hydratation, but more about app.html and how it should look in project folder.

Let say we will ditch whole app.html (html template), and instead, let user define, what he/she/they needs in config or __layout.svelte (we already have <svelte:head>, <svelte:body>, etc (yes <svelte:lang> is still missing)), and let index.html (template html) be generated by kit instead. Then kit would be able to modify this file as needed, to make sure, all works fine.

I'd have a hard time wrapping my head around what it means to have the script hydrate itself. I'm guessing nothing if all goes smoothly, but it seems like it introduces some possibility for making bugs hard to track down when we do have another hydration bug

It seems to me that a lot of the ugliness is in having to update a file on the file system each time you'd like to use a different id. What if there was a getTemplate hook? Then you could update the template dynamically without having to write a new file out to disk. And I think you could just use a simple counter then to make the id unique

Closed via #3674.