-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: remove Svelte Query #217
Comments
I'd say moving JS to the server for the gain of satisfying non JS users of the site is not worth it, considering the issue you mentioned. Content shift should be solveable by preloading the data, which you can instantly render. Thought these are small problems that can be looked separately after removing Svelte Query, as indeed, it is probably useful for larger use case scenarios |
If you mean "load the data during build time", that causes it to go out of date quickly. If we try to fix this by updating it with client-side JS, we fetch the data twice and cause layout shifts if it renders differently. |
Preloading the data means, to load the data before displaying the site. In the example of the contributors page, the data of the contributors could be loaded before the page is accessed. The data is present instantly. This comes at the potential cost of making the request in vain, so instead you can block rendering before the data is loaded on page access. This will have the same effect as doing it on the server, as the server would have to prepare the data and thus block rendering. Thought, we are talking about very minor topics right now. |
Okay but where is it loaded? Are you talking about loading it client-side, eg on hover, or on the server? |
Since this is a static page, I mean on the client side, eg on hover. But content shift is a miniscule problem as it can be prevented easily as is with client side rendering. Removing Svelte Query is more of a refactor |
As discussed on Discord, the use of Svelte Query is problematic. It doesn't even do much other than wrap some functions.
We should move these to load functions. These run on the server, letting us provide data to non-JS users and prevent layout shifts.
The only problem is that we currently build statically, and if we move to using the CF Pages adapter we start running into the 100k daily worker limit. It has still yet to be investigated if we can only run the worker on some pages.
The text was updated successfully, but these errors were encountered: