issues if usage of [isOpen] with variable

[stretau]

Describe the bug
If you use the [isOpen] functionality for ng-select with a variable its somehow not possible to get in Defaultmode (as it is if you NOT use [isOpen])

To Reproduce
Steps to reproduce the behavior:

1. Go to https://stackblitz.com/edit/ng-select-u8ezpw?file=app/app.component.ts

Use see the implementation like

<ng-select [items]="cities"
                   appendTo="body"
                   bindLabel="name"
                   placeholder="Select city"
                   [multiple]="true"
                   [isOpen]="myOpenVar"
                   [(ngModel)]="selectedCity">
        </ng-select>

if the myOpenVar is true/false everything works as expected. with true the searchlayer is (always) open, if false the searchlayer never opens. But if you use the "default"-value "-" like its mentioned here (https://github.com/ng-select/ng-select#api) the behavior is like [isOpen]=true

Expected behavior
Consider a situation where you want fill all the options dynamically by a configuration. Maybe the normal/default implementation should be an ng-select behavior without the [isOpen] functionality. But e.g false or true should be an option.

If [isOpen] is not provided in the config, then myOpenVar should get a value that ng-select behaves like [isOpen] is not provided, that means "open layer onclick" and "close layer on select":

summary
So it should be possible to get all 3 states for ng-select (isOpen true, isOpen false, isOpen default) by providing via variable.

Desktop (please complete the following information):
newest Chrome
angular6 and ng-select 2.9.0

[varnastadeus]

- means that there is no default value

[stretau]

- means that there is no default value

ok thx. So does this then mean, if I use [isOpen] than there is no way to get the behavior like its not used? Is this a bug? Is this a feature?

[varnastadeus]

I think this could be improvement to act as usual if value is not true or false

[raysuelzer]

The ngChanges which sets manually open seems to run after the dialog has already been closed by an outside click. The original intent of this feature was to make is so that an outside click would not close the select. For example, using a material overlay component inside the template of ng-select will cause the overlay to be rendered outside of the select and thus trigger the dialog to be closed.

I think that a solution might be to allow some elementRefs or selectors to be passed which will be ignored by the outside click directive.

Or, delay the call to close() until after changeDetection has run. Calling close() on outsideClick will happen before the props are updated.

[tesseris]

The ngChanges which sets manually open seems to run after the dialog has already been closed by an outside click. The original intent of this feature was to make is so that an outside click would not close the select. For example, using a material overlay component inside the template of ng-select will cause the overlay to be rendered outside of the select and thus trigger the dialog to be closed.

I think that a solution might be to allow some elementRefs or selectors to be passed which will be ignored by the outside click directive.

Or, delay the call to close() until after changeDetection has run. Calling close() on outsideClick will happen before the props are updated.

Current behavior is useless.