Asymmetry in the APIs between @transient and use.transient()

Framework Knowledge
1

Shouldn’t the following be equivalent?

@transient(‘TestModel’)
export class TestModel {
    constructor() {}
}

and

...
aurelia.use.transient(‘TestModel’, TestModel);
...

so that invoking directly on the Container would produce a TestModel instance:

...
this.model = this.container.invoke(‘TestModel’);
...

What’s interesting is that the former doesn’t register with the Container anything that’s invokable. The latter does.

I assumed that the decorator-based version was identical to explicit registration at the Aurelia configuration site.

There’s a reason I’m working here directly with the Container, and using string-based keys.

Did I misunderstand something?

1 Like
2

I don’t know the direct answer, my thought would be:

  • The decorator forces it to be set statically at compile time and is part of the metadata for the compiled object and therefore isn’t needed in the DI container since it will always be transient.
  • The other is more dynamic and now needs to be tracked since its set at runtime?
1 Like
3

You know, to your first bullet, I thought that too. So I switched to an explicit @singleton decorator. But that produced no change. I also did the following:

...
this.model = this.container.get('TestModel');
...

just to see what comes back. Whether I decorate the class with @transient(‘TestModel’) or @singleton(‘TestModel’), in the both cases #get returns ‘TestModel’–nothing invokable.

Explicit registration, however, returns the TestModel ctor regardless of whether I explicitly register a transient or a singleton, which is what I would expect.

Almost makes me wonder if @transient and @singleton are doing anything at all. Perhaps it’s a timing issue, or maybe a misunderstanding as to what the decorators are actually doing.

1 Like
4

Over my head on this one.
I did search around a bit and found this topic dealing with testing and using the @transient decorator on the class.
Not sure if its pertinent or not.

1 Like
5

Good find…and thanks for putting it forward!

I just gave it a cursory glance and it looks relevant. The workaround for now appears to be explicit registration, which is fine even if a little inconvenient.

But I’m going to dive deeper into this. What #get is returning against the Container is puzzling.

1 Like