I just finished create a new package called npdev:svelte-loadable! This is based on a base of an excellent package which already existed called svelte-loadable, and retains much of that packages API, but adds an easier to optimize way to register loadables, and SSR/hydration support. If you are new to loadables (react-loadable or svelte-loadable), the package works a lot like npdev:react-loadable, and can be used to split code by components.
Documentation is non-existent, but check out my Meteor Svelte Starter repo (the App.svelte module in particular) for an example setting it up!
There are a few things left to complete:
Documentation! There is none.
Tests - there are none!
There are a few configuration error scenarios which will likely fail in ugly ways right now - needs better guardrails. Part of that is rearranging some of how the loading works (it’s noted with a TODO).
A babel plugin! react-loadable and npdev:react-loadable each have babel plugin to reduce the amount of configuration boilerplate which much be entered to make SSR and hydration work. (Update: I have a babel plugin, but it doesn’t get applied to the code compiled by svelte - not sure how to fix that)
(One thing left to complete in my starter is some data hydration solution. I don’t have anything for that, so the content on the “About” page will flash of loading after the page loads - but you can see in the source that the loadable SRR support is working. You can see that hydration support is working on the homepage, which is flash free).
Perhaps it’s useful to have some intro in your starter kit of the various pieces used and other useful info/references pertaining to Svelte, so it can be the go-to for Meteor/Svelte integration.
That’s where I’m headed. I basically wanted to get it so that it has everything my react starter has, which is basically, offline first data, code splitting with dynamic imports (loadable), and SSR which works with all those parts. The last part is completing the offline first data component. I’d like to port npdev:collections (which probably should have been called npdev:react-collections), but that may be a big lift for something I’m not actively using yet. After that it’s really all about cleaning it up and documentation.
This is awesome, I looked at the code yesterday and it looks very clean and really pleasant to work with, it brings some of the old Meteor magic back
I think what would be really nice to see is an example repo of Meteor pub/sub integrated with svelte reactive view (perhaps a simple checklist, similar to what we’ve with react/blaze) I think it’ll really drive the point home.
Another thing, there was this issue around the growing bundle size due to code duplication and apparently it was solved with sapper, I’ve not looked closely at their solution but I’m wondering how does the Meteor/Svelte integration handle this?
Lastly, it might useful to get in touch with Svelte author (Rich Harris), he might be interested in spreading the word about Meteor/Svelte integration.
I’m hoping someone will grab my starter and have at it! I think all it’s missing is a fast render package (anyone know an up to date one?).
The only thing left on svelte-loadable is adding a Babel plugin to reduce some of the manual boilerplate requirements (to automatically add the resolve function to registered loaders).
For the super code problem, I think that’s a question for whoever maintains svelte:compiler (meteor-svelte). I assume the Meteor bundler is handling that correctly.
Wow, meteor/staringatlights:fast-render worked perfectly the first time. Thanks!
I still think there is room for improvement, but this will definitely work as an easy solution.
Room for improvement - fast-render works by polyfilling the Meteor.subscribe method on the server, and capturing data from there. This makes logical sense, since that’s exactly how data fetching works client side. But, if I understand how it works correctly, it’s either running the query twice on the server for each query, on each request, or it’s running the query in subscribe, setting up mergebox, then drawing the second query from there (but then does it re-use that on the client, or set up the mergebox a second on client subscribe - if it does reuse, that would actually be very efficient, if it does not, it’s very inefficient).
A simpler solution (and maybe faster/more scalable, if my assumptions are correct) would be to ignore Meteor.subscribe, and just capture the actual query the one time. That’s basically how npdev:collections does it.
Anyone familiar with how fast-render actually works?
Several times I have tried to understand it and have failed!
A simpler solution (and maybe faster/more scalable, if my assumptions are correct) would be to ignore Meteor.subscribe , and just capture the actual query the one time.
This was my thought, too, but it also handles the the current user by establishing a context (I think based on the connection). This allows things like this.userId and Meteor.user() to work safely. I have seen other solutions that try to simply monkey patch things like Meteor.user(), but they run into problems where a user from one call pollutes the next.
It also does some magic on the client to hydrate everything, waiting to enable the subscription until all data has been loaded into minimongo, which handles the .ready() handle nicely for you.
In my starter, the about us page is actually set up reactively - it shouldn’t be too hard for someone to take those bones and make something like a todo app.
Keep up the good work! 
