What are the advantages of routify vs. window.location.href?

[burggraf]

I'm very new to Svelte (but loving the simplicity and speed of it so far). Can you tell me, though, what the advantages are of using routify vs. standard html routing for something like [..fallback].svelte?

<script lang="ts">
  import { goto } from "@roxi/routify";
  $goto("/");
</script>

vs.

<script lang="ts">
window.location.href="/";
</script>

[Tommertom]

Hi there

Thx for trying this out

a window.location.href will trigger a full page reload where as a router command won't

In this case (fallback) it might not be a big issue, because someone entered a wrong URL.

Or you programmatically triggered a wrong route - in that case, it also does not matter - we need to debug then :)

So long story short, maybe this works for you. But personally I wouldn't touch it this way because it triggers a full reload which might cause some other side-effects I don't want.

[burggraf]

Gotcha. This repo rocks. I'm creating some Supabase-specific stuff that I hope to break into a separate npm lib that can be easily added in: https://github.com/burggraf/svelte-ionic-supabase-sidemenu. Once I get further along I'll host a demo app with the extensions.

[Tommertom]

Thx - I will be glad to hear how things have worked out for you.

[Tommertom]

I think this can be closed now - although having open issues is mostly a healthy sign ;)

[burggraf]

I'm using this repo as a base for a fairly large project now, and it's going very well. Are you upgrading to the latest SvelteKit release, and if so, when? And will there a big upgrade curve?

Note, I used https://github.com/Tommertom/svelte-ionic-sidemenu-demo as the base for my project, and it doesn't seem to have been updated yet?

[Tommertom]

Hi there

Thx for using the code and happy to hear more feedback

As to the starters like sidemenu, I do not intend to upgrade them anymore now I released an NPM library.

The main demo is now upgraded to kit which was initially a bit of a curve - but in hindsight now it is easy.

• Configuring Kit to run as SPA requiring two actions instead of one (see README on the NPM and/or main demo)
• Migrating the routes using the migration tool by Kit was a breeze. Routify's routes were easily migrated and only manually had to change the layout files etc
• Slugs like [tab].svelte needed a bit of discovery as the Kit architecture requires a separate .ts/js file to handle this
• goto and other helpers - I just needed to import the equivalent from Kit

I am not sure how much you will benefit from moving to Kit. The bundle is likely not smaller nor the performance hugely better (?). You are building a bit more tech debt with Routify 3 - especially as it seems to be stuck in beta for a while. But if you are comfortable with the Routify API, keep it like this!

Irrespective of Kit/non-Kit there is the upgrade stuff on Vite and the VitePWA. That has changed a bit but not hugely.

So in short - I don't think you should upgrade now, just because Kit arrived in rc. New versions are still quite developing - and while the code might be ok, the examples and documentation seems lagging a bit.

As to the roadmap, there are few things I am aspiring to include, but not planned - tree shakable components, IonBackButton and better IonPage animations being big ones

Please let me know more how you experienced using IonicSvelte. Love to improve on the code and the docs

Regards Tom

[burggraf]

Thanks for this -- I appreciate this POV, basically "if it's working no need to upgrade now." And it's working extremely well, as I said. Just let me know where you'd like me to supply feedback and I'll be happy to post my findings as I go. Thanks for this product!!!

[Tommertom]

Hi @burggraf - bit off topic from this issue, but have you implemented form handling and if so, which libraries did you use to do the validation and error reporting to user?

I am trying yup for schema and validation. But not yet found a suitable form lib that uses yup to validate ionic forms

[burggraf]

I haven't implemented any form handling -- I usually do most of that by hand anyway, sorry.