More general repeat.for for FileList and other specialized collections

[m-gallesio]

🙋 Feature Request

I have noticed repeat.for does not work for several specialized collections, like for example FileList.

This applies to both Aurelia 1

https://github.com/aurelia/templating-resources/blob/master/src/repeat-strategy-locator.ts#L31-L40

and Aurelia 2:

https://github.com/aurelia/aurelia/blob/0937b6308a7fdf77d27ff75c1e82bfd78913f9bd/packages/runtime-html/src/resources/template-controllers/repeat.ts#L749-L760

🤔 Expected Behavior

Since for...of works for FileList I expected the equivalent and equally structured Aurelia construct to work.

😯 Current Behavior

Repeating does not work since a strategy is not explicitly defined for FileList.

💁 Possible Solution

In Aurelia 1 I guess it would be possible for consumers to configure extra repeater strategies. This seems harder to impossible to do in Aurelia 2 due to how the code is structured (at least in the snippet I found).

Explicitly defining a strategy for every possible typed collection does not seem viable. Moreover, according to MDN these kinds of specialized collections are getting rarer.

Maybe some kind of duck-typed check (e.g. whether the object has a length or size property, whether it is iterable, ...) could be more appropriate.

Ultimately, note that this missing functionality can be substituted by simply iterating over indexes:

<ul>
    <li repeat.for="i of files.length">
        ${files[i].name}
    </li>
</ul>

[bigopon]

There' 2 aspects of a repeater around its data: observation & iteration (view-creation).

In v1, iteration is done within the strategies. In v2, because we don't think anyone would be writing a strategies to handle all things repeat related, we merge the iteration into the repeat. Maybe we can open a way to teach the repeater how to iterate and observe a "collection", rather than fixing it. Doing it like this could enable folks to have custom iterable supported easier too.

cc @fkleuver @Sayan751

[Sayan751]

@bigopon That's a great idea! What about registering the "iterator" for a type using the metadata? We can try to generalize this, and store the iterator information always in the metadata, even for the currently supported types. That way, users can also register an iterator for their iterable types. We might need to decide on the contract/interface of such iterators.

[Sayan751]

@bigopon It seems like a duplicate of #851. Can one of these 2 issues be closed?