Typescript inferred types for child components that has done type checking

[Lilja]

That title is a mouthful, let me explain it better.

Imagine that you have a store with a random state:

export const useFoo = defineStore('fooStore', () => {
  const username = ref(undefined as string | undefined);
  return { username };
});

And inside App.vue

<Child v-if="typeof username !== 'undefined'" />

And Child.vue

<script setup lang="ts">
const foo = useFoo();
const { username } = storeToRefs(foo);
</script>

Now, if I want to do anything meaningful inside Child.vue I always need to add the same check for undefined. This type information is lost.

const onClick = () => {
    username.value // undefined | string
    if (typeof username === 'undefined') {
        // This will never happen(as long as that if-statement in app.vue exists)
       // It's only here for compile time checks.
        return;
    }
    username.value // string
}

It's a bummer that I need to add this check just to make typescript happy when I know for a fact that typeof username === "string".
How are you solving not having to do redundant type checking everything over and over?

I suppose you can use props. But doesn't feel scalable to do so when there could be a lot of sub components between Child and App.

[guypassy]

The issue doesn't stem from Pinia here, rather from the fact that because you have this code in the Child component, there is nothing to indicate to typescript that the value is populated. You could just as well use this component elsewhere and not have that check.
If you are truly certain that the component won't be used elsewhere and the username will therefore always be populated, a simpler way to appease typescript would be to use the ! to mark it as definitely having a value => username.value!.

[posva]

This is indeed just how TypeScript works and how it ensures correctness.

BTW you should write ref<string>() instead or ref<string | undefined>() if you prefer. Also you can just do !username instead of typeof username === 'undefined'

[Lilja]

After reflecting a bit on this. I feel like it's missed the point a bit of the question. I appreciate both of you taking the time to answer the question!

Let's say you are creating an gaming application like Steam. 99.9% of the app is locked behind a login screen, so you can't really use the application without a login.
Since stores require a default state, it makes sense for a username to be undefined or null. Making the property in the store to be string | null. This makes sense for the login screen, but does not make sense at all for the rest of the app. Imagine all the places it could display a username, imagine how many places it would need to "defend" against null checks when in reality it's never null just because we put null as our initial value in our store.
I don't think a 99.9% of the time username being non-null justifies the type system thinking it's string | null.

I don't see how using props instead of putting it in a store solves anything either. You are just getting a lot of code repetition instead.

I agree that is less of a typescript issue, but rather an architectural issue. Perhaps one day there is a better pattern or framework to deal with this.