Each Block Typing Issue

[JAD3N]

I'm trying to iterate over a properties values by using {#each...}, and I have two typings (this is a TypeScript project) in my Svelte component.

<script lang="ts">
    import Transition from './Transition/Transition.svelte';

    type Options = { text: string, value?: string }[];
    type OptionsGroup = Options[];

    export let options: Options | OptionsGroup = [];
</script>

{#each options as option}
    <div>example</div>
{/each}

I would expect the type of option in the each statement to be Options | OptionsGroup but VS Code is giving me an error saying:

Argument of type 'Options | OptionsGroup' is not assignable to parameter of type 'ArrayLike<{ text: string; value?: string; }>'.

I'm unsure of what exactly is going wrong as the build and dev tasks are working fine with no errors at all, it only seems to be an issue with VS Code.

System:

• OS: Manjaro (Linux)
• IDE: VSCode
• Plugin/Package: Svelte for VSCode

[dkzlv]

I also found a strange bug with {#each}.

Smallest repro possible:

<script lang="ts">
  let data: { name: string } | null = null,
    someArr = [1, 2, 3];
</script>

{#if data}
  <!-- Works fine -->
  {data.name}
  {#each someArr as _}
    <!-- Highlights an error! -->
    {data.name}
  {/each}
{/if}

Mac, VS Code, running the latest plugin. I have a gut feeling it is somewhat connected to this issue.

[dummdidumm]

@dkzlv that's #619

[dummdidumm]

I fear this is not possible to fix on our side, it seems it's a TypeScript issue. You would get the same error when you do this:

function each<T>(
    array: ArrayLike<T>, // or T[], doesnt matter for the error
    callbackfn: (value: T, index: number) => any
): any{ /* doesnt matter */ };

each(options, a => a); // The same TS error

that each function is basically what is used to type-check the each-block. I did not find a way to silence the error without losing type safety.

[jasonlyu123]

You can do this instead. I think I have this typescript error before and got it works by trying some random combination lol

<script lang="ts">
  type Option = { text: string, value?: string };
  type OptionsGroup = Option[];

  export let options: Array<Option | OptionsGroup> = [];
</script>

{#each options as option}
  <div>example</div>
{/each}

Edit:
Noted these two types are not the same, but you probably don't care about the difference most of the time. If you do care, you probably need to write some custom type guard to cast it.

[JAD3N]

Thank you for the clarification, I've amended my typings as recommend and that has pretty much solved it.

[ITenthusiasm]

that each function is basically what is used to type-check the each-block. I did not find a way to silence the error without losing type safety.

@dummdidumm I'm running into this same issue. Does Svelte use an ES array method (eg. map) to determine the type? Or does it define its own type? I think that would clarify whether this is a bug in Svelte's language tools or an issue in TS.

I agree with @jasonlyu123 that the two TS types are not the same, so I prefer not to have to do Array<T | U>. From the code, I'm imagining this is coming from the use case of a custom select component, with the code being oversimplified to drill into the specific problem. My code looks (almost) the exact same as JAD3N's when it comes to this use case, with similar types and type names.

In such a use case, the consumers of the component will pass in some kind of options prop. But Array<T | U> suggests to consumers that mixed arrays are supported by the component when in fact they are not.

---

Alternatively, is there some way to type cast within the HTML portion of a Svelte component?

[dummdidumm]

This is a TypeScript issue and there is nothing we can do about it: https://www.typescriptlang.org/play?#code/PQKhCgAIUgVALAlgZ0iyBXZBTAJpAIwE9IAbAQwDsBzDc67AWgBcB7V01AM1YCdIAxNnIBjeFBDBwubCIq9skLhkojmiVpUgB9bcgBu2Us2zNk2gIzbhYgDywAfAAookN+V69yRAFyQAgp7eADKIANbY9g4ANK5uIuSkpASiYVyUfk76iRjYfrDRaJQyAB5+lBgAtgTYvACUkAC8DpBUROB1fm0A3ODgzEQADooA8oPqmqiNkADekCYlzH7IzLyINIXZpLkA-Mur69SQAL4A2gC6vQPDkGMTlMgA4rysGINNt+MaDxe9pKaQVhfSZ+O7fVAAH0+9yeLzeH1+fWAwDgAGVILUXrxUPBathwLoDEYTGZLNZRPAnECYYVFM0MXVekA

You can't type case in HTML currently, but you could write a function that does nothing but casting.

[ITenthusiasm]

Much sad. 😔 I'll open an issue on the TS repo. Thanks!

[ITenthusiasm]

@dummdidumm Okay in the meantime, though, hear me out:

// TS v4.4.4

/** This is used by language-tools for #each */
declare function __sveltets_1_each<T>(
  array: T[],
  callbackfn: (value: T, index: number) => any
): any;

/** This is a potential fix for `language-tools`'s #each */
declare function __sveltets_2_each<T>(
  array: T,
  callbackfn: (value: T extends ArrayLike<infer U> ? U : never, index: number) => any
): any;

type Option = { text: string, value?: string };

const options: string[] | Option[] = ["1", "2", "3"];
const options2: string[] | Option[] = [{text: "1", value: "2"}];
let optionsX: string[] | Option[] = [];


// TS errors here
__sveltets_1_each(optionsX, e => e);

// No TS Errors here
__sveltets_2_each(options, e => e); // arg type = string[]
__sveltets_2_each(options2, e => e); // arg type = Object[]
__sveltets_2_each(optionsX, e => e); // arg type = string[] | Object[]

Here, the approach is changed. Instead of T being assumed to be the inner type, T is assumed to be the Array. (Only arrays are supposed to be passed in anyway.) This array type is immediately assigned to the first argument. And the second argument unpacks the array to discover the true inner type. This approach requires no updates to the TS repo, and it immediately resolves this bug.

Thoughts? Would this fit in to how the rest of this repo uses language-tools?

[ITenthusiasm]

If we absolutely want the ArrayLike in the mix, then we should be able to get away with enforcing T extends ArrayLike<any>.

Here's a TS Playground link.

I'm not sure if ArrayLike or Array/[] is the preference. But both are definitely options. Here's an alternative using just an Array constraint:

declare function __sveltets_2_each<T extends any[]>(
  array: T,
  callbackfn: (value: T extends (infer U)[] ? U : never, index: number) => any
): any;

You get the exact same (good) pass/fail cases in the playground link with this approach.

Edit: Linking this part of the TS docs to show that this isn't a hack. 😅 So we can use this approach legitimately.

[ITenthusiasm]

@dummdidumm @jasonlyu123 Any thoughts on this solution? If it doesn't work, I can accept that, move on, and try to open a TS issue. But from the code I've added, this does seem actionable, does it not?

If so, could we re-open this issue?

[ITenthusiasm]

Awesome! @JAD3N if you ever want to go back to the previous syntax you were using, it's doable now. It's working for me on VS Code. 👌🏾