As we migrated NNS-dapp to SvelteKit recently (without routing changes, yet), I compiled the top three to know before launching a SvelteKit dapp on mainnet. Hope it can be useful if you develop an application with the same frontend tech stack .
Why did you move to SvelteKit? To my understanding most of the benefits SvelteKit adds aren’t really usable on the IC.
Are you using the static adapter for building?
We are moving to SvelteKit for various reason:
we want to make some changes in the routing (it’s in progress so let me validate first the idea before sharing some more info ). until today we used a custom router I developed earlier this year which works fine but itsn’t that flexible and works only with a true single page application
we are indeed using the static adapter. long story short, I think that frontend app, when possible, should be optimized to use primarly HTML and less JS. e.g. not use JS to render static HTML. particularly on the IC with the service worker, for performance reason
we also think that using SvelteKit is more community friendly. it’s easier for devs to jump in NNS-dapp if it follows pattern the community could potentially already know as jumping in an app that uses a non-documented custom made routing
Does that make sense to you too?
Oh and beside SvelteKit, we also wanted to move to ViteJS. The dev experience is so much more enjoyable
Makes a lot of sense! I’ve been using Svelte with Vite for recent projects while taking a look at SvelteKit now and then but it never felt worth making the switch as I couldn’t really see any benefit for my usecases.
But I’m interested in learning about your router solution, I just use
svelte-spa-router and didn’t run into any troubles so far .
Looking forward to one of your articles on the matter!
@peterparker Great! I have spent many days trying to make sveltekit work on the IC and then gave up. Would be cool if there is some “starter” template for the others as there is for the standard svelte project.
That’s a good idea and none of the svelte examples in the example repo are SvelteKit currently. Maybe I can put something together, just gonna need a bit of time…
What would be cool @lukevoz just a frontend SvelteKit dapp or should it come with a small “hello world” backend (Rust or Motoko)? with II too?
@peterparker simple motoko Hello world backend would be nice … Not sure if there are some caveats with II too. I am using the Connnect2IC toolkit.
Thanks for the feedback. Then SvelteKit and a simplistic Hello Word backend in Motoko. I might need a bit of time to provide the example but it’s well noted.
@lukevoz last Friday I put together the SvelteKit sample repo we discussed and provided a PR to the examples repo
That is so cool. Thank you. Gonna test it out today/tomorrow and will let you know how it went.
Cool, any tests would be much appreciated!
Note: if you add auth-client to the sample you might need some polyfill that are not set in the template currently (ongoing discussion). Maybe something we can add afterwards.
I’ve managed to get this working in local environment. All went smooth except when running the site via
npm run dev command, I am getting a 500 error when communicating with the backend (calling the greet function):
6:23:41 PM [vite] http proxy error at /api/v2/canister/rrkah-fqaaa-aaaaa-aaaaq-cai/call: Error: connect ECONNREFUSED ::1:8000 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1300:16)
This does not happen when I just access the front end canister via browser directly (without npm run dev). Not sure what the problem could be.
did you run
dfx start and
dfx deploy while trying - i.e. is the local replica still running when you run
npm run dev?
don’t got that issue
Yes the local replica is still running, I am sending a screen too – on left side there is frontend after dfx deploy and on the right side npm run dev with error while the left one is working.
Not sure what could be wrong here.
Thanks for the screenshot!
Did you use dfx
In your screenshot it says “Unable to fetch root key”, that’s the cause of the issue.
In dfx <
v0.12.0 the declarations that were generated used
process.env.NODE_ENV !== 'production' to detect if the root key should be loaded or not. They fixed / improved it in >=
process.env.DFX_NETWORK !== 'ic'
The template used
v0.12.0 to be up-to-date but also because it solves this other issue.
So I hope that’s your issue .
Hmm, but I am using dfx 0.12.0 both dfx.json and
dfx --version say that
Can the node version be a problem? I am using v18.10.0 (npm v8.19.2).
We’ve seen the least problems with node v16, but if you guys can figure out how to do it on v18 as well that would be great!
Well spotted, it’s indeed NodeJS >= v17. Problably these ViteJS issues #5365 and #4794 - the ViteJS proxy does not work anymore.
I have fixed the template, can you sync and give it a try to confirm?
I have removed the proxy and upgraded the template to use the host param of agent-js instead which makes it compatible regardless of the NodeJS version.
Oh yeah, now it works. Thanks a lot for for your time spending on figuring out my errors here
How about the II is it complicated to add? I was looking at the Connect2IC toolkit that Ive been with svelte before and it seems like it would need some rearrangement to work with svelte kit as well.