outer-scope properties are not supported in static type checking

[4nderss]

I found that when using and trying to access inherited properties, it will give you an invalid warning.

Case:

List.ts

autoinject()
export class List {
public items: any[];
constructor(public router: Router) {}

//code to fill items
}

List.html

 <compose repeat.for="item of items" containerless model.bind="item.data" view-model="./${item.type}-details"></compose>

xxx-details.html

<a href="router.generate("itemDetails", new { id : item.id }"> Go to details </a>

In our scenario we use compose to render a specific view for a specific type. Compose then exposes every property from the view it is rendered in.

How would we stop getting warnings for theese type of scenarios? Where the router property can't be found.

[MeirionHughes]

What is the error? Presumably its in xxx-details.html?

[4nderss]

Yes, cannot find xx in type xx

[MeirionHughes]

The linter works per html file; so that xxx-details.html template will need a router property defined somewhere in its view-model too. There is no way for me to know what is defined in a parent scope (where you do the containerless compose) during linting because everything is done via reflection.

[4nderss]

ok, so I just have to ignore the warning? Can I ignore certain files?

[MeirionHughes]

Yeah; I'll need to add a way for people to either ignore certain files or add property overrides.

to confirm aurelia supports this; https://gist.run/?id=c3d618546a0fef10a266109465eed94c

I'll be honest though, this is a terrible design; those xxx-details.html are not self-contained and will break if they are used in a context that is missing router or any other outer-context field.

[MeirionHughes]

Literally no way to fix this as is. I'll open something for ignoring files.

One thing you can do, however, is to define the field again in each template, but don't set it. i.e.

xx-details.ts

export class XXDetails{
  router; /* defined in outer-scope */
}

that would be the minimum required for the linter to know the field existed, without it having any effect on run-time. because it would be undefined, the run-time would still fall back to the outer-scope variable. From a design point of view, it probably would be very useful for you to explicitly do this so anyone reading your code will know where its coming from.

[4nderss]

Ok I will have a look on ways to solve this.

Thanks