Support custom element attributes with checking

[zakjan]

item.ts

import {bindable} from "aurelia-templating";

export class ItemCustomElement {
    @bindable value: string;
}

item.html

<template>
    ${value}
</template>

page.ts

export class PageViewModel {
    value: number;
}

page.html

<template>
    <require from="./item"></require>

    <item title.bind="value" value.bind="value"></item>
</template>

This should throw two errors, the first for missing bindable title attribute in ItemCustomElement, the second for mismatching type of value attribute.

[atsu85]

@MeirionHughes, currently this issue is assigned to 0.11 milestone, but i think that this issue has actually the most impact for this project (mostly for newcomers, but it could have saved some of my time as well last week because of copy-past from camelCaseProperty that should have been converted to kebab-case when used as attribute)

[MeirionHughes]

Unfortunately, the rework stuff is slow going (0.10) as its taken a while to decide how to structure it --I'm favoring chain-of-responsiblity style for the rules that operate on the ast - thus abstracting away the parser entirely.

So... I will take a look at this to see if something can be done asap.

[atsu85]

Am I correct that currently the missing prerequisite for this task is ability to check/resolve references to other files via <require from="..."? So probably a components that would

• detect (or in initial phase just provide) global resources
• scan references to the source files
• register custom element tag names

would be smth in the beginning of the responsiblity chain? Is that smth You have in mind?

[MeirionHughes]

Yeah something like that; basically you pass the file result along and they add extra processed data to the result/ast. not entirely there yet. the idea is to make it generic enough so I can throw any file type at the chain.

However, for now, I could probably to grab the source when <require from='./item'' comes up. see if there the first export has the custom element decorator, define a custom element resource, and finally, attach the resource to the ast. that should allow me to check the bindables at least exist and get the type reflection for both the left and right side.

One thing I need to workout is how to get typescript to determine if one type can be assigned to another.

[atsu85]

I created a checklist (containing two ideas from @zakjan, one from @zakjan and added couple from myself):

• [ ] invalid path references: <require from="./does/not/exist"></require>
• [ ] that attribute are not in camelCase, but in kebab-case format: <item notCorrect.bind="existing"></item> vs <item is-correct.bind="existing"></item> ( subset of next check, but might be easier to implement, so I added it separately )
• [ ] missing bindables <item missing.bind="existing"></item>
• [ ] mismatching type of value <item some-number.bind="someString"></item>
• [ ] If --strictNullCheck is enabled, it could also check if all required bindable attributes are passed, meaning only those explicitly typed with X | undefined or with a default value could be left unassigned.

[zakjan]

Another idea: If --strictNullCheck is enabled, it could also check if all required bindable attributes are passed, meaning only those explicitly typed with X | undefined or with a default value could be left unassigned.

[MeirionHughes]

okay-doky, I've added something basic (bit ugly too). its limited to './foo' having a first class with FooSomeThingCustomElement and the resulting element being foo-some-thing. also if you bind to the DOM parts of the element, it will complain at the moment. Will need a way to figure out how to get the reflection information for the base dom element.

[zakjan]

More ideas:

• value.bind="..." binding syntax should be required, only string attributes should allow passing value with value="..."
• If strictNullChecks is enabled, only nullable attributes (@bindable value: ... | undefined) can be omitted, otherwise they are required.