posva
Passing `server: false` should change the type
Currently only lazy: true sets the return type of data to possibly undefined but server: false should also do it
Currently we use loaders (0.7) in SPA app, it would very annoying if suddenly all those page loaders became possibly undefined inside pages, one of the reasons I chose this library was because of that. I don't think we would need to be server: false, in pure SPA app, so thats interesting disconnect of modes. Would that effect us?
On side note would be there a way to check if the loader used in current page has loader exported as an mitigation? Of cours e using useLoader inside router guards and such would not be safe, but in pages and components it should (?) Not sure if types could be matched with that.
@posva am I correct in thinking that after https://github.com/posva/unplugin-vue-router/pull/506 types will have undefined value even on non lazy non server loaders?
That would be major DX regression, from our own use I don't see cases where I would want loader to be on a page and somehow be with undefined data. If error occurs I want page to show error, but not to handle it in every page * loader used.
I understand that with allowed errors you could make loader be with undefined data, but how common is that use case? To support it, we are sacrificing DX similar to Sveltekit loaders, Remix loaders and Solid start.
This gives me an idea. Maybe errors should not be active locally by default. It still needs some research, types can become too complex too. I see having local error support like a bigger improvement rather than a possibly undefined value that can be guarded with a v-if. It wasn’t a major dx regression by any means so I’m curious to see actual examples where this undefined value aggravate things that much
For simple cases sure you can use v-if but what should be shown in v-else part, sorry your data was not loaded, but navigation was a success? You can kinda make guard layout for that annoying, but manageable.
Script part is trickier. Imagine you have data which is derrived from other data
const { data } = usePageData()
const complexState = computed(() => {
const object = data.value
if (!object) {
// What should happen here? Returning undefined also makes any downstream code need if checks.
}
...
})
Of course example is very basic, but I hope it can illustrate my point. The problem multiplies by the amount of loaders you use. 3 loaders 3 separate checks everywhere.
The main selling point of using page loaders for me was that when page is rendered I know data is there, I do not want to do extra checks. If data fails I want to treat it as navigation error. Other frameworks, treat it the same.
You can still cast your data for these scenarios. I find it more rare and less inconvenient. Other loaders implementation lack the granularity that’s why they don’t have undefined That being said, it should be doable type wise to have multiple function overrides. I still have a few tests not passing so I’m not 100% sure