Hey! What's up? Svelte for Sitecore JSS has been chugging along and I've been implementing some bug fixes as I've been getting ready to speak about the work I did integrating Svelte with Sitecore JSS at Symposium.
My talk itself is titled "Integrating a client framework with Sitecore JSS" and covers some of the challenges you'll face along the way if you choose to do a custom framework integration of your own (you should, it's fun!) There will be plenty of Svelte examples and I'll talk about some of the reasons why I love Svelte.

My talk is scheduled for 11:35am on Wednesday, November 6th in Swan 10. Hope to see you there!
What's new with Svelte for Sitecore JSS?
Well, quite a few things! Explore the full closed issue list here.
package.json Commands for SSR
start:ssr
and start:connected:ssr
have arrived. They've already saved me a ton of time. I noticed a few people asking for these in the Sitecore Slack #jss channel recently and I thought it would be really useful for implementing client-side hydration. The downside is that my development server.js
is a little more complicated now... Now you can test SSR in disconnected and connected modes though, hopefully letting you quickly track down issues faster without having to deploy to Sitecore or some other location.
This will also allow you to host a little instance of your application in SSR mode without a proxy.
Server-Side Rendering Hydration
Hydration was more involved then I was expecting. Hydration involves connecting your client-side application to markup that has been Server-Side rendered. I had many problems that needed to be solved here.
First, my bundle paths were wrong. As you know, when you deploy your application to Sitecore, your files end up in /dist/appname
. I didn't really have a great way of passing in that appname
, whatever it may be, to my index.html
file though. I decided to ultimately convert my index.html
into index.svelte
, which would allow you to build it by itself and pass in props that I could source from my package.json
file.
You'll now find a generate-index.js
file in the repository. I suspect this will change some in the future but it's a solution that works for now. I like that it sources from the package.json
so if you ever changed the application name, your bundle paths will update automatically.
Besides this, main.js
was adjusted to read in JSS_START
which is injected by our SSR renderView
function and will now pass in that data to our app through props. You can check out that code here.
Placeholder Enhancements
There were a few issues involving placeholders. First of all, if you used a random placeholder name and the placeholder wasn't in the layout service data, it'd throw an error!
Also if a component could not be resolved inside of a placeholder, it would just skip it entirely. Now we inject a missing placeholder component in it's place.
My Placeholder
component did not support renderEach
and renderEmpty
before. If you look at the React Styleguide Reuse component, you'll see why. Basically, I can't pass dynamic markup like that in Svelte like React does. My workaround was to allow you to pass components in renderEachComponent
and emptyComponent
and you can use a <slot />
inside those to render each placeholder component inside of it. Doing it this way forces you to create a new file with this wrapper component in it, but I think that's a good thing? Ultimately the end result is the same. Here's an example of a wrapper component.
Bye axios, it was fun
Removed axios - We already have a fetch
polyfill so we don't really need axios. dataFetcher
has been rewritten to just use fetch
. If we didn't already have this polyfill for apollo
then I would have just kept axios. I may throw a PR at the JSS GitHub to see if it might make sense for this change to be added to the other sample apps because all of the samples have a fetch
polyfill already.
SSR Error Handling
Error Handling during SSR: If Server-Side rendering threw an error while it was rendering, the error was not caught before. I added some error handling and now pass this error back through the renderView
callback function if it occurs so it can be handled gracefully.
DateField renderComponent
There's this use case in the React styleguide where it lets you pass in a render
function to the DateField... I approached this the same way I did the Placeholder
changes and added a renderComponent
prop that allows one of these rendering components to get passed in. This renderComponent
will receive one prop for now, named date
.
Conclusion
So those were the highlights of what changed since the last release. You can still spin up a Svelte for Sitecore JSS instance with one command (if you already have the JSS CLI):
jss create sveltetest svelte --r erzr/jss-svelte
Hopefully these bug fixes bring this project closer to feature parity with the official client frameworks. I have some other Svelte related things to share, but you'll have to attend my talk to find out what they are.
After Symposium I'll be looking into adding Sitecore Forms support and building out some more official documentation. Maybe some unit test and integration tests? Maybe.