docs: expand & clarify FAQ entry on using client-only libraries #10886
Conversation
|
HoldYourWaffle
force-pushed
the
docs--client-only-async-components
branch
from
5c62f9b
to
4614a4c
Compare
In particular mention dynamic imports more explicitly.
…ent-only libraries Perhaps this would be a better fit for https://svelte.dev/docs/svelte#onmount?
Note that using `Promise.resolve()` in the server branch would make TS angry, since it's of type `Promise<void>`.
HoldYourWaffle
force-pushed
the
docs--client-only-async-components
branch
from
4614a4c
to
499e701
Compare
|
@benmccann Conceptually I agree, this feels too "significant" to be tucked away in an FAQ section. I went through several iterations, but so far I haven't found a way to condense this further without being confusing/overwhelming for newcomers. I'm not entirely sure what you mean by your second note. I only added variations of existing examples and one for using a client-only component. If I understand correctly you like the latter, so would you like the existing (more basic) examples to be removed then? |
|
I'm saying there should be no such thing as a client-only component. You've already gone down the wrong path if you fine yourself in such a situation. Rather than demonstrating how to use a broken component, we should instruct people to fix the component. That component should follow this FAQ to use the client-only code only in the browser rather than remaining difficult to import. |
|
Aaaah that makes a lot more sense. What an impact a small typo can make :P However, some components make such heavy use of client-only code that server-rendering them serves no value. The async nature of dynamic imports and various restrictions around things at the top level make it vastly more complicated to implement them in a way that "supports" SSR. These components don't make sense to render on the server, an empty In my case, we were working on a Svelte integration for monaco-editor. Initially we used a basic dynamic import in Making the component client-only and usage explicitly async ended up with much more straightforward code than all the other workarounds I could think of. For bonus points: it's trivial to add a friendly loading spinner with As much as I hate it, I think client-only components are the better/more natural solution in some cases. I fully agree that it's smelly and tedious though, I'd love to hear your suggestions! (For reference: an example project on how to use monaco-editor in SvelteKit solves this by disabling SSR for the whole page, I'd argue that's even worse) |
|
Why delete Today I use <script context='module'>
import boostrap from 'bootstrap?client'
function tooltip(node){
const inst = new bootstrap.Tooltip(node)
}
</script>
<span title='hello' use:tooltip>tooltip</span> |
|
I was wondering the same thing, I feel like @dummdidumm's 6cf7255 condensed a bit too much. What kind of error do you get if you try your example without |
It felt a bit non-standard and so I thought it was better to focus on the things that are built-in to Svelte and Vite. It is a very cool plugin though. Perhaps it could be added to Vite core at some point if people really find it useful. I wouldn't be against adding back a link to it if folks are finding it useful, but I think that having a demonstration of it in the docs is too much. We can just raise awareness of it and people can reference the plugin's docs if they want to use it
That was my commit |
|
Woooops, no idea how I messed up those names... Sorry! I can't test it right now, but top-level |
|
oops, yeah, I should have used |
|
Even if the component's |
|
FAQ help people deal the actual problem easily My old code with browser check before know iso-import, it's has more status need manual manage, that mean more code. <script context='module'>
function tooltip(node){
const p = import('bootstrap').then(()=>{
const inst = new bootstrap.Tooltip(node)
return inst
})
return {
destroy(){
p.then((inst)=>{
inst.dipose()
})
}
}
}
</script>
<span title='hello' use:tooltip>tooltip</span>Svelte take care about devoloper happiness, is that still right? |
|
This is definitely an impractical section of Svelte. sveltejs/svelte#5501 would make the syntax less cumbersome, but then you easily fall into the race-condition trap. @shynome What kind of error do you get if you import |
I don't want to talk more about this, you can do this and I also can work easier than others which don't know about iso-import https://github.com/shynome/sveltekit-without-isoimport error log |
|
Aaaah, The most obvious solution is a guarded ( Sounds like a perfect usecase for @benmccann Any thoughts? |
While helping some beginners with their first Svelte(Kit) project I encountered some major confusion around using client-only libraries with SSR. I have tried to improve this section of the documentation based on that feedback.
Some notes:
onMount?{#await}with a null-ish expression renders fullfiled branch during SSR svelte#9323, so I feel like a comment explaining what's going on is appropriate. I'm not sold on this particular format though, any suggestions?Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.