onChange blocked about angular-selectize HOT 15 CLOSED

Why not use a $watch() statement in your angular controller?

from angular-selectize.

Here's a better solution that doesn't call onChange twice:

      config.onChange = function(){
        if( !angular.equals(selectize.items, scope.ngModel) )
          scope.$evalAsync(function(){
            var value = angular.copy(selectize.items);
            if (config.maxItems == 1) {
              value = value[0]
            }

            if(modelCtrl.$viewValue != value) {
              modelCtrl.$setViewValue( value );
              scope.config.onChange(value);
            }
          });
      }

from angular-selectize.

I could have, but I assumed all of the config options to work and would have saved a couple of hours of headscratching had I known the of the issue :)

I was going to add that adding a $watch to the $digest cycle for each selectize input isn't ideal either, but then I'm unsure how that compares performance-wise with this implementation.

from angular-selectize.

+1 on this, same issue, onChange called twice

from angular-selectize.

+1 also seeing onChance called twice

sounds like we should just watch the model for now

from angular-selectize.

+1 onChange does nothing, should expose same events as selectize

from angular-selectize.

Nor does onInitialize

from angular-selectize.

For what it's worth, the ng-change directive seems to work.

ng-change="change(app.settings)"

from angular-selectize.

+1 onChange is being called twice

from angular-selectize.

+1 onChange is being called twice

from angular-selectize.

+1 onChange is being called twice

from angular-selectize.

👏

from angular-selectize.

As I wrote as comment to your commit (but I feel it belongs more here), I think you still need to set the silent flag to the setValue calls. Not only it prevents unnecessary calls (minor), but it also fixes the double call to onChange in the case of single selection mode.

from angular-selectize.

I've created a v3 branch that uses the latest version of Selectize:
https://github.com/machineboy2045/angular-selectize/tree/v3.0.0

I was able to simplify the Angular directive a lot. I'd be curious what you
think.

I like the idea of adding support for objects. But I'm worried if we add
functionality that doesn't exist in Selectize itself, then we could diverge
from it so far that we can't take advantage of updates. It would be ideal
if Selectize would add support for objects. But who knows when that would
be.

What if I made an experimental branch? Maybe there could be a better name
for it. And we could add object support to it?

Also, thanks for all your contributions. I know you've been very active
answering questions in the issue pages. :)

On Thu, Aug 6, 2015 at 1:30 AM, Philippe Lhoste [email protected]
wrote:

As I wrote as comment to your commit (but I feel it belongs more here), I
think you still need to set the silent flag to the setValue calls. Not only
it prevents unnecessary calls (minor), but it also fixes the double call to
onChange in the case of single selection mode.

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

from angular-selectize.

Yes, it is nice, it has a cleaner style.
Suggestion: take the opportunity of a new major version number to rename the file from selectize.js to angular-selectize.js, to avoid some confusion (eg. when debugging).

Support for objects: would be nice, I can live without, it just has the overhead of searching the object in the list of options.
Perhaps you can add an angular-selectize specific configuration to enable this.
It is not a major divergence from Selectize, it is just an added feature in the wrapping.

A more risky operation (toward future versions of Selectize) would be to monkey-patch it to fix some issues, like I did in selectize/selectize.js#783
Something that would be useful to have in the wrapper, but currently I just have it in the service wrapping angular-selectize.

from angular-selectize.