Controller updates to input-model not reflected in view about angular-multi-select HOT 15 CLOSED

This is weird.. The sample in the manual seems to be working. May I see your controller? You can paste it in jsFiddle.

from angular-multi-select.

See http://plnkr.co/edit/w6PkejQeZsdKR1HWTMJY?p=preview

Notice that while the check mark clears in the drop down, the button label does not change.

Then make the code modification I suggested a re-run

From: Steven [mailto:[email protected]]
Sent: Friday, May 16, 2014 11:54 AM
To: isteven/angular-multi-select
Cc: ilopata1
Subject: Re: [angular-multi-select] Controller updates to input-model not reflected in view (#8)

This is weird.. The sample in the manual seems to be working. May I see your controller? You can paste it in jsFiddle.

—
Reply to this email directly or view it on GitHub #8 (comment) . https://github.com/notifications/beacon/4304514__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNTg3ODQzMCwiZGF0YSI6eyJpZCI6MzI0MDkxNzN9fQ==--210aae23f202880c7dcc13d1e7a0e5b71e0b56b7.gif

from angular-multi-select.

Aha, I understand your case. Admittedly it was never designed to update a single item like that.

Anyway simply adding a 'true' to the watch function will break the reset function. It needs two watchers, one for total change and one for granular change.

I made the changes & updated the script. Just re-download. Thanks!

from angular-multi-select.

Sorry to reopen, but...

With this change (adding true to the watch) the output-model is refreshed any time any properties of the input-model changes. This causes angular.copy to be called many times for changes that don't impact the selected collection at all. It is a significant performance hit in my app. There are ways around this of course but ideally shouldn't output-model only be refreshed if the tick-property is changed?

from angular-multi-select.

Hi @Hypercubed , no worry, feel free to re-open.

The thing is, there can be changes that do not impact the selection state but impact the data representation, such as changing the attribute of an item (let's say a lowercase name into all-uppercase). This, ideally, require the output-model to be refreshed as well.

May I know how bad the impact is? Any measurable amount of performance drop? And with how many data you have there?

As usual a jsfiddler or plunker sample would be great. Thanks.

from angular-multi-select.

Here is a plunker: http://plnkr.co/edit/Xq5M23

You will see the multi-select and a table of the input-model data. Click on the true/false to toggle the ticked property. The select box changes as expected thanks to the change above. You can also click the number to change a score property. No change is reflected in the multi-select.

My thought is that if I do a $scope.$watch or $scope.$watchCollection on the output-model variable (selected in this example) then it should only be triggered if the selection changes (i.e. ticked is changed in one object). I would think that if the selection is not changed the selected array would be the same array as previously, containing the same objects so these watches would not be triggered. Only if I $scope.$watch with the second parameter of true should changes in the values of the other properties that don't impact the selection. It's clear in the code that the output-model array is being regenerated using angular.copy, see #L178. If the list of selected objects is the same as previously then there should be no need to change the selected array since the array itself contains the objects that are already changed. (not sure if that sentence is clear).

Admittedly, my case may be a worse case example. I have thee multi-selects on a page each with several hundred items. By removing the output-model on the multi-select and adding my own watchers I've been able to get around this issue somewhat. However, since refreshSelectedItem is still being run #L171 is still creating a new selectedItems internally to the directive.

(sorry this is so long)

from angular-multi-select.

Perhaps something like this. In my case since the inputModel object is never changed it might work.

            $scope.$watch( 'inputModel' , function( oldVal. newVal ) {   

                if ( $scope.newVal !== 'undefined' ) {
                    validateProperties( $scope.itemLabel.split( ' ' ), $scope.inputModel );
                    validateProperties( new Array( $scope.tickProperty ), $scope.inputModel );
                }

                if (!newVal || !oldVal || newVal.length !== oldVal.length) {
                    $scope.refreshSelectedItems();
                    return;
                }

                for (var i = 0; i < newVal.length; i++) {
                    if (newVal[i][$scope.tickProperty] !== oldVal[i][$scope.tickProperty]) {
                        $scope.refreshSelectedItems();
                        return;   
                    };
                }

            }, true);

BTW... I think newVal and oldVal are swapped and not used. What is $scope.newVal?

from angular-multi-select.

Hi Jayson,

I understand your problem. Indeed your case is unique.. Just now I tried the multi-select with about 1000 data. It slows down indeed but not significantly, at least on my PC browser. Maybe you have a really complex model there.

By the way, just to confirm, is it heavy from the start, or is it heavy because you need to $watch the models (be it input and/or output) from within your controller?

For now, some possible solutions:

1. There's a validation function triggered in both watches in the directive. It's not really required so you can safely remove them. I assume this will - at least - speed up the initial load time.

2. Comparing the length like what you wrote might work.

3. Another solution is that you can comment out the first $watch (the one with true) altogether. A consequence is that you won't be able to update the model attribute programatically.

For the near future, the directive will have a callback that is triggered when user CLICK to select / deselect an item (not programatically). Will this help in your case?

Yes another user alerted me with that newval and oldval thing.. Thanks for reminding =)

from angular-multi-select.

you can remove the validateProperties() .. it loops the inputModel so might speed things up a bit if you remove it. The next version won't have this.

from angular-multi-select.

In my case I'm now not using output-model at all, just watching the input-model myself ($scope.$watch in my controller similar to the code I wrote above). Having something in the directive itself could help reduce the number of times refreshSelectedItems (and the $scope.selectedItems.push) is run but as I have it now I'm at least skipping the angular.copy.

from angular-multi-select.

OK.. so as for now, does your solution solve your problem?

Also, with this solution of yours, are you still able to update the model programatically? Not only the select/deselect status, but also, say, updating the label, for example.

I'm actually quite itchy to know the structure & amount of data you use for input model. Can you email me those data so I can test locally on my PC? I hope they're not some top-secret / private information.

from angular-multi-select.

I'm doing a lot of work to optimize a data intensive angular app. Unfortunately I can't share the data now. Basically I'm using multi-select to turn on and off nodes in a very large directed graph. For example I have ~150 type A nodes and ~800 type B nodes. The user can turn on and off nodes using the multi-select. When the selection changes (now determine by my controller that dirty checks the ids) I have to generate the edges between the nodes. The nodes themselves have lots of metadata. My next step may be to only use the multi-select to track the ids and keep the other data separate.

I am still able to update the model problematically because the directives watchers are still in place.

from angular-multi-select.

Ah nodes.. okay that's some serious stuff you got there. I've worked with nodes & paths before, implementing Djikstra shortest path algorithm for a shopping center directory. There were a lot of rows in the database due to the possible paths between store A and store B. Luckily it was all server side job.

Anyway since you've found a solution, can I close this issue? Also, next time please open a new issue instead of re-opening an old one. Kinda hard to track :)

from angular-multi-select.

You can close this one. I may open another one as I still think that the output-model object should not be regenerated each time, elements should be added or removed as items are ticked and unticked. But before that can happen we need a onClick callback.

from angular-multi-select.

Noted. FYI; If you are going to fork & modify, I suggest you to wait for the next version which will come soon.

Closing this one.

from angular-multi-select.