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.