Skip to content

RFC: usePreloaderInfo #338

@maiieul

Description

@maiieul

Discussed in #311

Originally posted by maiieul October 6, 2025

What is it about?

A hook that exposes real time preloader information, such as activeUserEventPreloadsCount, activePreloadsLength, etc.

What's the motivation for this proposal?

Problems you are trying to solve:

  • Even for Qwik, the UX/UI can feel janky on very slow networks. While preloading is ongoing, if the user clicks on something, there can be long delays (e.g. 2-4s for components up to 10-20s for navigations on 3G throttling) and no visual feedback is given to the user to tell them that things are being downloaded.

Goals you are trying to achieve:

It should be possible to do one without the other.


Proposed Solution / Feature

What do you propose?

A usePreloaderInfo hook provided by Qwik core.

Potential implementations

1. General info is achievable today

POC: QwikDev/qwik#8035
screen recording: https://github.com/user-attachments/assets/e4e47802-5f07-49dd-b5c8-91ba271b3e1b

The problem is it's not tied to a component and visible tasks are also counted as "activeUserEventPreloads":

  • the fallbackToMpa implementation is cleaner
  • there can only be a general spinner for when the network is too slow.

Note: it should be possible to differentiate visibleTasks QRLs from the rest, by assigning a probability of 0.98 to visibleTasks for example.

2. Granular info - ability to provide custom loading UIs with a activelyPreloadingBundlesCount tied to the component

For this we would need a way to know which QRLs correspond to which component.

This should be achievable through the qwikLoader.

The challenge with this would be that the custom loading UI would have to be preloaded first (maybe inlined or through ssrPreloads).

Code examples

  const { activeUserEventPreloadsCount, activePreloadsLength } = usePreloaderInfo();

or

  const { activelyPreloadingBundlesCount } = usePreloaderInfo();

Links / References

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFC-SeenDiscussed by the core team[STAGE-1.5] looking for championAdd this label after a proposal was discussed but is missing someone to implement it[STAGE-2] incomplete implementationRemove this label when implementation is complete[STAGE-2] not fully covered by tests yetRemove this label when tests are verified to cover the implementation[STAGE-2] unresolved discussions leftRemove this label when all critical discussions are resolved on the issue[STAGE-3] docs changes not added yetRemove this label when the necessary documentation for the feature / change is added[STAGE-3] missing 2 reviews for RFC PRsRemove this label when at least 2 core team members reviewed and approved the RFC implementation

    Type

    No type

    Projects

    Status

    In Progress (STAGE 2)

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions