Clicking on a link multiple times results in the load function being executed over and over again

[aradalvand]

Describe the bug

If a link is clicked on multiple times in quick succession, the load function of the corresponding page will be executed again and again. This behavior can be undesirable, it is at best wasteful (especially apparent when fetch requests are being made in the load function), and at worst the cause of obscure bugs.

Why don't you "throttle" navigation attempts (to the same page)? Such that any subsequent attempts (while the page still hasn't finished loading) won't cause a re-execution of the load function, etc? I was expecting SvelteKit to behave this way already.

Reproduction

• Clone https://github.com/aradalvand/sveltekit-load-running-multiple-times
• Run npm i and npm run dev
• Once the app is open in the browser, open the console.
• Click on the Go to foo link at the top of the page multiple times.
• Notice how the load function of the foo page is run each time, leading to potentially multiple requests being sent:

Logs

No response

System Info

System:
    OS: Linux 5.15 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
    Memory: 1.79 GB / 3.77 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 16.15.1 - /usr/bin/node
    Yarn: 1.22.15 - /usr/bin/yarn
    npm: 8.11.0 - /usr/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.72 
    @sveltejs/kit: next => 1.0.0-next.480 
    svelte: ^3.44.0 => 3.50.1 
    vite: ^3.1.0 => 3.1.0

Severity

serious, but I can work around it

Additional Information

No response

[benmccann]

Isn't that also the native browser behavior?

[aradalvand]

@benmccann Well, this behavior makes more sense in the context of native browser page loads because there's no client-side state that can potentially be affected by multiple load requests; while that's not the case when we're talking about client-side routing.

Moreover, I don't really see any good reason for the client-side router to follow the native behavior in this particular instance; whereas on the other hand there are good reasons for the 'throttling' behavior I described above. From a commonsense standpoint, it seems more reasonable as well, to me at least. The client-side router should look to minimize and remedy the shortcomings of native browser behavior whenever it makes sense, as opposed to always following it religiously, IMO; and this is one of those cases where there's an opportunity to actually improve upon the default browser behavior. Plus, the context here is different enough that the browser behavior need not strictly dictate what SvelteKit ought to do.

I'd say there should at least be a configuration option for this if you think both behaviors can be undesirable/desirable under different circumstances, although I can't think of any cons for the approach I'm proposing.

Feel free to correct me if I'm missing something.

[Rich-Harris]

If a request were to hang, it feels more desirable to restart it when the link is re-clicked than to join the existing (already-failed-but-doesn't-know-it-yet) request, no? I don't think there's a good way to distinguish between impatient link-mashing and hanging requests, so it feels like the current behaviour is probably preferable.