Datepicker swappable engines idea

[Foxandxss]

So talking with @robwormald, we brainstormed some ideas so I ended with the idea of:

We have an interface with all the methods that an Engine should have. For example IDatepickerEngine (not sure if the "I" convention is for us, but for the sake of the demo).

Problem with the interface is that you're not actually forcing the users to use it, but more as a convention so it won't blow up. So not that of a big deal.

Then we create a default engine with a sensible name (more on this later) DatepickerEngine using JS raw implementation.

Then the idea is to offer a constant like NGB_DIRECTIVES but for providers called NGB_BINDINGS. There we register all our providers in application bootstrap (like HTTP does). Downside is that if the user don't use it, app won't work, but I think that is a convention in angular 2.

So now, having an interface, default engine and having it registered with the app at bootstrap, our datepicker will use our implementation.

A end user can create his own engine and register it like:

providers: [provide(DatepickerEngine, {useClass: MyCustomDatepickerEngine})]

Then the datepicker in that component (and children) will use that custom engine now. Downside is that you need to import the original DatepickerEngine to swap it. Not a big deal either.

Check this plunker.

Thoughts?

[wesleycho]

Do we need to import the original? Is it not possible to provide an abstract class or interface?

[wesleycho]

Or maybe one idea is to provide a dummy class with methods as DatepickerEngine and force users to extend it and provide that.

[pkozlowski-opensource]

Downside is that if the user don't use it, app won't work, but I think that is a convention in angular 2.

I think that we can easily avoid this issue by sth like:

class NgbDatePicker {
    constructor(@Optional() private _settings: DatepickerEngine = new DefaultDatepickerEngine()) {
    }
}

This way people will get defaults if they don't provide anything.

Also, I think that if there are 2 providers under the same token they will override each other (the last one wins). So we could export NGB_PROVIDERS or NGB_DATEPICKER_PROVIDERS with defaults.

I think we can close this now as the general idea here is good and we can figure out technical details (if there is anything left to figure out) when actually working on the implementation.