Get rid of the register helper for directives

[jgoux]

Hello,
I want to thank you for this awesome project. I'm switching to es6 and it's really helpful to have all the examples. :)

I'd like to avoid the register helper and use directly angular functions (directive, factory, controller...).
It works well for the controller, but not so well for the directives (the "final boss" :P).

Do you think it's possible to create a Directive base class which hold a factory method to create child classes (including the compile/link method tricks) ? If so, could you provide an example of such a class ?

So you could do :

class myCustomComponent extends Directive {
constructor(inject1, inject2) {}
customMethod1(){}
}

OR

extends directly the "angular" object to make the switch invisible ?

Thanks again. :D

[michaelbromley]

Hi,

Glad you found it useful. I came across something similar to what you describe in an article about using TypeScript classes for directives: http://aholmes.azurewebsites.net/writing-angularjs-directives-as-typescript-classes/

I've not tested this out, and I imagine it would take a bit of fiddling with to get right (for me at least). As you say, the basic idea would be to make a base class with a static Factory() method which would encapsulate all the magic that is currently happening in the register.directive() method. It's an interesting idea though, and something I'll probably explore when I have more time.

As for extending the angular object, do you mean by patching the module.directive() method with custom code? I'm not sure what the advantage of that would be over using an explicit helper layer like the register.js example.

[jgoux]

@michaelbromley I think I'll go with the angular.directive patch, just to make angular "ES6 compatible".
The main advantage I see is that there is no overhead for migrating a project on it, it's the same public API.
I'll post a feedback here if you want if I make something. :P

[michaelbromley]

Ah okay I get the logic behind that. Yeah, I'd be interested to see what you come up with!

[schmod]

On a related note... it might be nice to fork register.js into its own project.

It would be nice to put it in a place where it can be used by other projects, and get updates (as new best practices emerge).

[michaelbromley]

@schmod Thanks for the input. It's unlikely that I will do that, but others are free to. The reason is that I only intended this to be an exploration of possible patterns and I don't want to suggest that this is the solution for Angular/es6 that people should start using in production. Making a repo for register.js I feel may mislead people into thinking they should start bower-ing it into their production apps, which might possibly lead to trouble down the line.

[bisubus]

I would say that patching angular.... methods would be a solid decision. Except that it won't work for hacky extensions (e.g. ocLazyLoad) and the code that relies on the services behind those methods, I see no other cons. I've had to successfully manage it on my own in most transparent way, at the cost of patching $injector.