What tutorials do you want to see for Aurelia 2?

Speaking of migrations from Aurelia 1 (which is definitely an important topic), is there any chance to see a jspm → dumber guide for really old (pre-cli) projects?

2 Likes

Hi Dwayne,

I’d love to see some samples of integrating Aurelia with a library like Microsoft’s MSAL or oidc-client-js to implement Authentication from External Identity Providers.

(I know this part is a bit off topic, but I’d love to see Aurelia gain some credibility by being recognized by some of these libraries. IOW, Microsoft has an MSAL library for integrating with Angular, AngularJS and React. This gives credibility a lot of credibility to those platforms. It always bothers me that Aurelia never (hardly ever) seems to show up in things like this. Sorry – just a tangent.)

4 Likes

Many good ideas yet expressed. I would love to see something about the power of composition.

3 Likes

More than anything, I would like to see thorough, complete coverage of the major Aurelia 2 components’ features and their API. I would not like to have to dig into source code, search through google, or locate a catch-all but incomplete cheat sheet hidden in some corner of the documentation.

I find many of the proposed complex use cases, particularly those that are specific to particular business domains, are not compelling because most of the code in those solutions will not be very interesting. The interesting minority of the code would, IMHO, be better located in the context of the relevant Aurelia component(s) and be indexed by the useful functionality they provide, functionality that will be applicable to more just a single business domain.

Perhaps we can teach more in terms of design patterns and fundamental programming alogorithms…

4 Likes

I would like to see a tutorial on how to build composite ui for microservices using Aurelia.
The one where You have a Shell and menu, then you have some modules and the shell picks them up, then compose the menu and sub-menu.

5 Likes

It would be nice if more TypeScript tutorials were available. I see a lot of documentation on components but either the html or the JS is shown, but not together for a full working example.

A single repo with a sample application that covers each of the topics would go a long way. Adding both the TS and JS to support both groups of users would be extremely helpful.

For example, click the </> Code button on Angular powered Bootstrap and both the html and TS code is available.

1 Like

This is a hugely welcomed thread

Native-like animations and screen transitions would be an enormous plus. The ancient AU1 “animator” tutorials are badly outdated.

With the rise of PWAs, clients are expecting native-live touch and feel on web apps.

New (and probably most) developers coming to Aurelia are in the PWA sector. This is an important demographic to target.

An AU2 tutorial easily creating an animated, native-like UX will be a hit.

3 Likes

The documentation actually used to be always Typescript first, but then changed to JS first, for the reason that both languages look very similar in Aurelia. Also, it’s to avoid giving the impression that Aurelia only works TS.

1 Like

Working with Aurelia in a .net app is at the top of my list. Ideally including using Web Pack, TS, Debugging and Authentication. Something similar to what @MaximBalaganskiy did for V1 would be perfect but ideally with Authentication and Debugging.

4 Likes

I went through the cryptocurrency example which was very helpful. However, I would love an explanation of the line @IHttpClient

I looked through the documentation for an explanation about these attributes, and couldn’t find one. Perhaps I missed it, but a lot of the documentation makes use of @XXXX.

export class Api {
    constructor(@IHttpClient private http: IHttpClient) {

    }

It would also be very useful to have a simple setup for writing a test where you need to inject httpClient and store. In au1 I would write

let auContainer = new Container();
let store: Store<IState>;
let sut: MyService;

beforeEach(()=>{
    store = new Store<IState>(initialState);

    auContainer = new Container();
    auContainer.registerInstance(HttpClient, http);
    auContainer.registerInstance(Store, store);

    sut = auContainer.get(MyService);
});
1 Like

This is just an educated guess, because I could not find anything in the docs either, but I think it is an annotation for the dependency injector. normally dependency injection is handled with either a static array named inject or the @inject() annotation.

export class Api {
    public static readonly inject = [IHttpClient];
    
    constructor(private http: IHttpClient) {
}

or

import { inject } from 'aurelia';

@inject(IHttpClient)
export class Api {
    constructor(private http: IHttpClient) {
}

I’m not seeing either one of these in the code in the tutorial. Which is what leads me to believe it is an annotation for the dependency injector to inject the IHttpClient into the class.
more info about dependency injection can be found at Dependency injection (DI) - The Aurelia Docs

1 Like

That would make sense because I noticed that @autoinject no longer exists in au2.

Oh - I just reread the section on DI and see that @inject() replaces @autoinject.

Based on your comments, I guess the @IHttpClient is just an explicit way of indicating that IHttpClient is injected into the ctor - but then if you have @inject()/@autoinject why would you need another way of telling the DI to do the injection?

I tried to start a new project the other day with au2 and gave up after 20 minutes. The “Migrating to Aurelia 2” section in the documents could do with a bit more work I think.

1 Like

I can see some utility in annotating the individual parameters in the constructor, in the situation where the constructor parameters get reordered. The annotation just would get reordered with the parameter. using @inject() class annotation or the static inject array, you would have to remember to also reorder the types passed to the annotation or reorder the types in the static inject array. Which could cause a build error at best or weird runtime behavior at worst.

I tried implementing the V1 contact manager tutorial in V2 not too long ago, most of the concepts seemed fairly stable between V1 and V2. The biggest hurdle I ran into was how different the router is in V2. It is my understanding that there is still a lot working being down on the router, especially in the area of V1 compatibility.
Too your point though, the docs are still very much a work in progress, but they have been improving over time, but as always there is still improvements that can be made.

1 Like

@autoinject and now presumably @inject() automatically picks up the order of the parameters in the ctor (at least in v1).

I think I’m going to wait until it reaches at least beta before trying again :grinning:

1 Like

TL;DR the attribute decorator @IHttpWhatever is to use Interfaces as injectiontokens just like e.g. in C# .net core DI

@autoinject actually did nothing in v1 except add metadata. So you could really have annotated with any other deco and it would have worked with TS due to type inference.

Note The secret of TypeScript’s metadata generation is that any decorator on the class will cause the compiler to include the metadata. You don’t have to use the inject decorator specifically

Now the thing with the leading ctor deco, in your sample @IHttp… is that this also makes it A work in VanillaJS without repying on type hints from TS and allows B to use a different type in TS while maintaining the Injection token/key. This comes in especially handy with Interfaces as Tokens https://docs.aurelia.io/getting-to-know-aurelia/dependency-injection-di#using-interfaces.
So you can register MySuperHttp with the Common interface IHttp… but use your type for typecasting the attribute.

See more info here https://docs.aurelia.io/resources/cheat-sheet#dependency-injection

3 Likes

@autoinject - I had no idea!

Thanks for pointing me to the Cheat Sheet. I see I’m going to have to relearn everything I thought I knew in au1.

Quick question - should the DI registrations all happen in one place? main.ts, app.ts?

In asp.net core I have one centralized method that registers all the interfaces in the DI - this is run at start up.

I also asked a question about the most basic setup for a test. If you could just show me the equivalent in au2 it would help enormously to get me going

let auContainer = new Container();
let store: Store<IState>;
let sut: MyService;

beforeEach(()=>{
    store = new Store<IState>(initialState);

    auContainer = new Container();
    auContainer.registerInstance(HttpClient, http);
    auContainer.registerInstance(Store, store);

    sut = auContainer.get(MyService);
});
1 Like

Here is a sample from the Store Plugin tests in V2 https://github.com/aurelia/aurelia/blob/master/packages/__tests__/store-v1/integration.spec.ts

You’ll notice my tests typically dont make use of setup/teardown methods but instead arrange functions. But it should be easily convertible to your likings

2 Likes

Thanks so much for the sample. Extremely enlightening. I learned a lot from it.

1 Like