Quick question.
Is it possible to get an compilation-error when one of our templates binds to a property that does not exists?
We’re currently using Aurelia together with Typescript and really loving the typed aspect of the development when doing refactoring. The problem is that the moment we are switching over to the templates, everything relies on search-and-replace and the developer. We’re also not currently getting any feedback if the type of properties we’re sending between components are of the correct type.
Is there a way to enforce this on build time?
I’ve seen that aurelia has got a new static $view property that can be used to define the view-template inside the class.
Is this also possible without declaring it as static so it can access the current properties of the class-instance or would this not be possible because of aurelia’s binding system?
It’s not a simple question. From what I remember, aurelia vscode extension does have functionality to provide typings for template, but I’m not sure if it helps with refactoring. Would be nice if we could have some help on it.
For creating view strategy out of view model instance, from what I see, I’m not sure if it’s possible. It works with view model definition (class), not really view model instances. Plus it would require constant view compilation as it will no longer be able to cache view factory for a specific class
Sorry about that. It started out as a simple question when I started writing it then snowballed a little.
It’s not a simple question. From what I remember, aurelia vscode extension does have functionality to provide typings for template, but I’m not sure if it helps with refactoring. Would be nice if we could have some help on it.
I’ll look into the vscode extension but it would be very nice to have this feature as part of our ci pipeline.
Ok. I don’t really understand the internals of the framework all that well so the amount of what I could contribute with is pretty sparse atm, but I’ll check if there’s anything I can contribute with.
For creating view strategy out of view model instance, from what I see, I’m not sure if it’s possible. It works with view model definition (class), not really view model instances. Plus it would require constant view compilation as it will no longer be able to cache view factory for a specific class
Ok. Would this still be the case if we were using tagged template literals instead? The compilation could be cached by the array-strings received by the template-function.
I see that one thing that’s working is to import another template library like lit-html and manually rendering the element on each binding update but then a lot of the benefits of using aurelia would be gone, and it would probably not work when nesting components. Maybe the best way to go about it if we want this way of structuring the elements is to create custom-components?
If we are to determine to compile the template based on instance, every time a new instance is created, shouldn’t it be recompiled? For that, I think tagged template is somewhat the same with static view. Maybe plugin for view - view model linking is a proper way to do it.
If we are to determine to compile the template based on instance, every time a new instance is created, shouldn’t it be recompiled? For that, I think tagged template is somewhat the same with static view.
Maybe plugin for view - view model linking is a proper way to do it.
Do you have any examples or some documentation I could look at of how to implement something like this?
Should I implement a new viewstrategy?
It works with constructor, not really the instance. Except for the case where you compose using object instance, but it’s not how normally we create custom element. So in order to have it work with instances, we will have to change few more bits around templating, and I’m not sure what needs to be done yet.
The issue with this is it’s not static, means each instance will get their own template, and piped through process of compilation, albeit similar. It wouldn’t hurt perf normally but if you are in a big repeat, it should be something to keep in mind.