Export instances of all directives

[pkozlowski-opensource]

Based on #778 (comment)

If people want to query for directive instances they can't. We need to evaluate for which directives it makes sense to have query and export those directives.

[colinmorelli]

Is there a reason you wouldn't want to export all directives that the module exports? IMO if it's something the angular module exports, then it's part of the public API and the TS module should export it as well.

[wesleycho]

Some may be meant purely for internal use with no external exposure. It also avoids the problem of users doing not great things and trying to pressure the library to support a subpar api as a result instead of solving a problem the right way in the library.

[pkozlowski-opensource]

I'm going to close this one till a real need surfaces.

[colinmorelli]

Some may be meant purely for internal use with no external exposure. It also avoids the problem of users doing not great things and trying to pressure the library to support a subpar api as a result instead of solving a problem the right way in the library.

I'm only referring to exporting types for components that are already being exported in the angular module. If they're internal only, the angular module shouldn't be exporting them and it's a non issue.

Anything that is being discussed here is already possible (and even encouraged, in many cases, on the docs site). Not exposing type information is not preventing people from doing anything (or at least not preventing them from doing much), it's just ensuring their code is less-safe when they do so, by forcing users to type cast to any and throwing away the value of TypeScript for these cases.

Given that we can assume people are calling methods on the component instances within templates (the docs actively encourage this in many places), it stands to reason that they'll also be called from within user-defined components. I think it's fairly easy to find a whole host of cases in which this is useful to have, and I see no reason to not export the primary components of the library (i.e. all the components that are documented on the doc site and are expected to be used).

[pkozlowski-opensource]

OK, got convinced by @colinmorelli - let's export public (documented) directives.

[CSchulz]

I want to import NgbAccordion to be able to trigger the toggle via component.

import {NgbAccordion} from '@ng-bootstrap/ng-bootstrap';

The panel is disabled at first and the user should click on next. This will trigger a method in the component, which checks the form and set the property to enable the next panel. Furthermore it should toggle the panel.

Using activeIds doesn't work, because it seems that first activeIds is interpreted before panel disabled is checked.

[pkozlowski-opensource]

@CSchulz could you put together a plunker with what you are trying to do? It sounds like it should be possible but I'm not sure I understand your exact use-case.

[CSchulz]

Here is my use case with an example http://plnkr.co/edit/APEi5jEhgyhnoEQHeZ5c?p=preview

Edit: Forgot the property binding, works like expected.

[AndriiDidkivsky]

#778
Hi, I have the similar issue with NgbDropdown that does not exported in @ng-bootstrap/ng-bootstrap

I've try to import
import {NgbDropdown} from '@ng-bootstrap/ng-bootstrap/dropdown/dropdown'
So, I've got an error 'Uncaught SyntaxError: Unexpected token import....'

I want to avoid 'any' type. I have a custom wrapper component, when I click it wrapper should expand and (set focus on input or open NgbDropdown, etc) of contained elements.

In this case i want have next code
@ViewChild('dropdown') dropdown: NgbDropdown;
But now I go
@ViewChild('dropdown') dropdown: any;

Does it not a real-world use-case ?

We use typescript to avoid runtime exceptions but you make us to get runtime exceptions with yours approach.

Webpack: 1, angular: 2.1.2, ng-bootstrap: 1.0.0-alpha.15.

Thanks.