maybe it’s too early to ask that kind of question but as in our company we use Aurelia in 4+ applications, where each application has more than 400 elements, I wanted to check what kind of migration we’ll have to do when upgrading to vNext - or how much work it will be …
I downloaded the webpack-ts example from the aurelia-vnext repo and tried to create an additional element like I used to do it in vCurrent:
created a new class and added the @autoinject decorator => there is no autoinject. Is this decorator gone?
removed @autoinject and added @customElement, like it’s done in app.ts. Than added a require tag to app.html. Run “npm run watch”, browser opened the page and my element is ignored. Will the require tag not work anymore in vNext?
Although vNext is still in pre-alpha it would be great if someone could create a small example using two elements and some kind of service using as less code a necessary (I like convention over configuration) With the current example I’m a little bit lost.
Btw I really like the way of creating views and view-models in the current version. Most of the time I only needed the two things mentioned above (@autoinject and require-tag).
Thanks for your help and great work!
Best regards!
Hi @stefan, appreciate you trying things out and providing feedback
It is never too early to ask questions. It is a little too early to start trying to migrate vCurrent apps, however. To address your concerns:
This is temporary. We do not have @autoinject in vNext at the moment because of uncertainties around the decorator specs, which is causing the TypeScript team to delay a feature that we would like to utilize for a new (cleaner) type registration API for DI.
Since TypeScript is waiting for the spec to mature, we are too. At least, to the extent where it does not unnecessarily delay a vNext beta. We are simply deferring this feature to the last possible moment in the hopes to avoid having to re-do the whole thing.
Furthermore, @autoinject would only apply in JIT scenario. In AOT you would not need a decorator at all.
The <require> tag is also simply not yet implemented. For JIT this would be handled by requirejs and a template pre-parser, for AOT this would be statically analyzed and registered in a more runtime-efficient manner beforehand.
So @autoinject and <require> (and most other core APIs) not going anywhere. You definitely do not have to worry about breaking changes of that magnitude. It’s just that some things which are runtime features in vCurrent are going to live in a different piece of the infrastructure in vNext.
As for the conventions, they are staying the same and there will be cleaner alternatives as well. There’s a good chance that you’ll find yourself mostly deleting unnecessary boilerplate when migrating to vNext and not so much changing stuff. vNext will be smarter in many ways.
In the case of JIT (when you dynamically want to load resources during runtime) the conventions are probably going to move to loader plugins such as requirejs. For AOT, well, AOT will statically analyze the application and make the appropriate modifications in order to completely remove the need for such loader plugins (to keep the runtime bundle smaller and faster).
Regarding examples, we are still very heavily focused on working on the core and therefore haven’t been able to spend much time on examples yet. We will, though, when we feel things are starting to get ready for experimenting by early adopters
If you would like and if your employer allows this, some code samples would be very welcome though. I am always on the outlook for kitchen sink repositories to find out how the community is using vCurrent so we can focus our efforts on eliminating breaking changes for parts where we know the community uses them. It wouldn’t be feasible to do this for the entire API surface of vCurrent, and I’m sure this wouldn’t be necessary either (I doubt every nook and cranny is being used).
So the more information we have on how the community uses vCurrent, the easier we can make the migration path.
Of course feel free to keep reaching out if you have any other questions
thank you very much for your detailed answer! I really appreciate you take the time to do this because I see you doing a lot of coding in vNext
Sure, I would be happy to help you by providing kitchen sink code. Is there a paper or something where I can read what and how you want it?
We made an element supporting the DevExtreme toolset in a way DevExpress did in AngularV1 (as I prefer the way of putting the configuration in the viewModel, where I can reuse it, instead of increasing the view code). This element uses some features not that well documented in vCurrent (BindingEngine, TemplatingEngine, …). If I put this in a small example would this help you or is this to much, as it’s more than 10 lines of code?
Another question: you mentioned JIT and AOT in your answer. I know what these two abbreviation mean but what do they mean in case of Aurelia or to be more specific: what is the most important difference?
Oh, and one more: in the some tests in the git repo I saw some special “bindings?” like :disabled or @click. Will you introduce “magic” symbols like AngularV2+?
@stefan No problem! And thank you for following up
There is no paper, it’s actually a very open-ended ask. What you are saying about DevExtreme / BindingEngine / TemplatingEngine is precisely the kind of thing that I’m looking for and would definitely be helpful. No such thing as “too much”! Just a standalone repository that succeeds at installing and running would be great. No need to spend much effort in trying to simplify it. Raw and even messy is completely fine
AOT, first and foremost, would not be included in your app bundle. It will contain the TypeScript compiler and an HTML parser to pre-compile your app at build time, then perform static analysis of your templates, decorators, and feeds that into the JIT to perform the JIT compilation process “ahead of time”. The result is that, if you use AOT:
The JIT package does not need to be included in your app bundle (making it quite a bit smaller)
The JIT process does not need to be run during your app startup (which cuts down significantly on app startup time)
AOT can see your entire project including the uncompiled TypeScript and thus has far more contextual information available to it. This allows for more intelligent decisions and conventions since we can use transformers to add helper code to your bundled app.
You could certainly combine the two as well, using AOT to optimize the static parts of your apps to improve startup performance and still including JIT for doing some dynamic stuff at runtime. (speaking of startup performance, we’ve already clocked vNext as starting more than 5x faster than vCurrent in various cases with JIT, and AOT will speed this up even more)
“magic symbols”: not in a million years Look, some people start to find the property.bind, property.trigger syntax to become a bit verbose over time, especially when there’s lots of them. And there have also been various requests to make it easier to implement custom syntax.
So I introduced the @attributePattern decorator that allows you to specify your own custom “pattern” (comparable to registering a route) to allow people to define their own custom / shorthand syntax with a few lines of code if they want to. The :disabled and @click are shorthands employed by Vue which a lot of people seem to like, so we added those as an example for folks who are familiar with the syntax of other frameworks.
I’m not going to dig into the pattern syntax just yet as it might change, but to give you an idea, here is the full code to allow the template compiler to recognize those 2 shorthands:
// @foo - shorthand for 'foo.trigger'
@attributePattern({ pattern: '@PART', symbols: '@' })
export class AtPrefixedTriggerAttributePattern {
public ['@PART'](rawName: string, rawValue: string, parts: string[]): AttrSyntax {
return new AttrSyntax(rawName, rawValue, parts[0], 'trigger');
}
}
// :foo- shorthand for 'foo.bind'
@attributePattern({ pattern: ':PART', symbols: ':' });
export class ColonPrefixedBindAttributePattern {
public [':PART'](rawName: string, rawValue: string, parts: string[]): AttrSyntax {
return new AttrSyntax(rawName, rawValue, parts[0], 'bind');
}
}
// in your app:
container.register(
AtPrefixedTriggerAttributePattern,
ColonPrefixedBindAttributePattern
);
And done. You have now taught the template compiler how to recognize these two shorthands. One thing we are hoping to accomplish here is to improve interoperability with other frameworks as well. We already had this capability in vCurrent but I don’t think anyone in the community ever managed to utilize it. Now it’s only a few lines of code to let Aurelia parse Knockout or Angular bindings, and actually something end users might be able to utilize
(fun fact: Aurelia’s own dot-separated syntax is also fully implemented with these decorators)
wow, thanks for the explanation. When I read this I’m really happy we have choosen Aurelia instead of Angular about two years ago. In Aurelia almost everything works as you expect and you don’t have to deal with strange namings, strange syntax (like [/*#) and a lot of configuration.
I’ll prepare the repo and come back to you when it’s done.
That is great! And thank you for not adding Angular styled snytax. That’s one of the many things I dislike about Angular or any other framework for that matter. Aurelia has really done a GREAT JOB at keeping unobtrusive and I’m so glad @EisenbergEffect pushed for that in Aurelia. We now have 6 plus enterprise apps built with Aurelia and haven’t looked back since introducing it to our team 3 years ago.
please feel free to use whatever you want from my part. Probably it’s better to start with this repository https://github.com/stenet/au-dx-builder, as I’ve changed quite a lot and now it’s up to the developer to choose the syntax for every specific case:
@deap82 The short answer is that you indeed don’t need to worry.
Enhance is mission critical in some applications that rely solely on it, and we’re fully aware of this. Also, due to the nature of these applications (often legacy and highly time-constrained), we realize it’s especially important to keep migration efforts here to an absolute minimum.
The main thing about enhance is that the html is compiled in-place, instead of being “eaten” by the template compiler. This allows the framework to play nicely with CMSes, legacy applications, etc, leaving existing structures and event handlers and such in place.
While it’s not yet implemented in v2 (as are several other important things), we definitely plan to do so. As far as I can tell even the API will stay largely the same.
That said, there is a lot of API surface in v1 and we are trying to reduce the api surface while providing more/better features with a smaller, more coherent set of APIs (even for low level stuff) that makes it easier to learn and master the framework.
Feedback from the community regarding which APIs are actively used will help us ease the migration path with a “compat” package that exposes some of v2’s API in a v1-compatible way. For us, it will mostly boil down to adding some extra classes and functions with the original method names mapped to the new APIs.
With the current example I’m a little bit lost.
