Entire Assets Folder Shown in Chrome Dev Tools/ All Svelte components and Svelte source code available in Dev Tools

[Mali-2]

Hello!

First off, thanks for such a cool library. I love svelte, and learning Phoenix with svelte so far is an awesome experience.
I have a question regarding the assets folder. I can see that the entire assets folder is being sent to the client-side, making all components and source code within available to the user. I know that in SvelteKit, the components are lazy loaded and sent when needed, so i assumed this would be the case here.

Am I missing something here, or is this just a limitation of combing phoenix with svelte? Is there a way to only send the components when the user navigates to a specific live_view and/or page?

Thanks again for creating such a cool hybrid of a framework. Any info would be greatly appreciated : )

Liam.

[woutdp]

Hi @Mali-2 thanks for the interest :)

At the moment all Svelte files are included inside the singular js bundle that's being generated. By default, Phoenix with Esbuild doesn't do code splitting. It just includes one big js bundle. Sveltekit does use code splitting which is what you're referring to I believe. The entrypoint for the bundle in Phoenix is the app.js file and you'll notice the line:

import * as SvelteComponents from "../svelte/**/*"

This dynamically includes all Svelte files in the svelte/ directory.

I'm not sure how hard it is to add code splitting to a phoenix project with Esbuild. From the documentation it seems esbuild doesn't really support it fully. An alternative would be to use Vite with Phoenix and use route based code splitting but hooking that up with Phoenix routes... seems pretty hard.

So it's indeed a limitation of combining phoenix with Svelte.

An alternative approach you could take is manually generating multiple js bundles with esbuild, and then manually including those bundles on specific pages. This will take some time and manual effort though.

Maybe also look into this: https://elixirforum.com/t/page-specific-javascript-with-liveview-and-esbuild-phoenix-1-6-0/42359/12

This topic looks pretty hairy though

[woutdp]

Those 2 features sound like they belong in live_svelte, definitely throw up some code somewhere whenever you have the time, I'd be happy to merge it :)

Contributions are always welcome, if you have any ideas/features you'd want to add but unsure if it belongs in the package let me know!

[cvkmohan]

Thanks @woutdp for pointing this out. A very nice writeup @NotM32. Now, this Vite setup makes svelte work inside Phoenix. The two advantages I find in live_svelte is 1. Rendering svelte components inside Function/Live Components of Phoenix. 2. Passing Events from LiveView to Svelte and vice-versa. How does this vite setup handle those 2 issues?

[woutdp]

Haven't tested out the Vite setup so not sure. The Vite setup is not officially supported atm so can't really help with this

[cvkmohan]

Thanks for the response @woutdp. My question is more for @NotM32. If it is plain JS integration - a lot of advantages of combining the two get lost. Why Vite in the first place? Mainly to get chunking and delegating entire bundling and tailwind setups. With the current setup, if it is a reasonable size application, the initial JS load will be quite heavy. So...

[christophertrudel]

especially since esbuild is the default in new Phoenix projects. Until that changes I'd want to stick to Phoenix defaults as much as possible.

I personally agree. I have played around myself with chunking with the current ESBuild setup up of LiveSvelte and have a working flow end to end via defining all the .svelte files as entryPoints. I did run into a couple hiccups on my journey:

1. Using async/await within the SvelteHook mounted method can mean a delay for the hydration of the actual component. This means that any phoenix bindings(ex: phx-click) within the component can be bound on the SSR component before it is hydrated. This would can cause an error or undesired behaviours if there is user interaction during the delay. Not common with a great internet connection but very possible under a slower conditions. I solved this with disabling any phoenix bindings during SSR rendering and then re-enabling during hydration(works like charm).
2. Now that we have many files instead of just app.js, we have choices to make. Mostly around how to retain hashes for browser caching. Normally mix phx.digest handles this for us out of the box however for this to work we either need to use the p sigil or make use of the cache_manifest.json to look up the hashed file names. In both cases we need add functionality to component.ex. For example

P Sigil



Using cache_manifest.json

Either approach can make use of preloading within the HEEx template. Which mean we get parallel loading instead of waiting for app.js to to fully load before fetching the needed svelte components for the page.



The second approach could be similar to cache_manifest.json but instead hashing the files during the esbuild and using it's output to do the look up. https://esbuild.github.io/api/#metafile
The drawback here would be a utility func exposed from LiveSvelte to be able to get the hashed file name if we wanted to make use of preloading the script.

Here is an example of the output running locally with hashed files preloaded, gzipped.

Would love to hear your thoughts and know if your interested in this approach. I can put some time into drafting a PR if so. By the way great work in the library.

Cheers

[christophertrudel]

For my use case, it was quite handy to extend the mix setup starter live_svelte is using, but just add a '--vite' option. I have this feature, and a couple other things that could fit well in this ecosystem. I'll put this code up later this week, just so it's out there.

@NotM32 Curious, did you ever get a chance to publish? Very interested in taking a look.

[zhangzhen]

@NotM32 I'm curious too and waiting for you to publish this fork.

[sarat1669]

@NotM32 it would be great if you can share a starter kit with these changes.