fix select "bind to multiple" implementation and sample

[Thanood]

It's okay when selecting things but changing the view-model directly (which means: assign an object) breaks the sample.

[Thanood]

Please comment on this change:

aurelia-materialize-bridge/src/select/select.js

Lines 36 to 41 in 43ccb0c

	this.valueObserver.value = $(this.element).val();
	this.valueObserver.synchronizeValue();
	this.valueObserver.synchronizeOptions();
	this._suspendUpdate = true;
	this.valueObserver.notify();
	this._suspendUpdate = false;

I'm totally unsure if that's a good practice or more of an abuse of observerLocator.

[Thanood]

After a chat session with @charlespockert I've reverted this to using a CustomEvent. Charles' version works in a plunk with a multiple select and without Materialize.

I've forked that plunk and changed it to use a multiple select here: http://plnkr.co/edit/2zwr4ExgNndjFVeiqUVW?p=preview

In Materialize bridge, though, it doesn't work. If you select some options in a multiple select, the bound view model variable is not updated.
I've noticed some differences, which may be related (or not, I'm not sure). The plunk triggers a MicroTaskQueue flush after the select value has been changed.

The Materialize version triggers that flush before the event is triggered. Still, the underlying array is mutated, has changed and this is detected correctly.

Here is what happens:
Aurelia's SelectValueObserver does not notify its subscribers. As far as I can see, it is not necessary since the ModifyCollectionObserver handles this.

In Charles' plunk, the above is exactly what happens. SelectValueObserver finishes and immediately triggers a MicroTaskQueue flush, resulting in ModifyCollectionObserver to be called which in turn calls its subscribers.

In Materialize bridge, SelectValueObserver finishes but then no ModifyCollectionObserver is called. Instead, a jQuery event handler is executed.

I don't know yet, what all this means but before I forget, I put it here.

[adriatic]

I don't know yet, what all this means but before I forget, I put it here.

My attitude, exactly - with this additional explanation. I care a lot about understanding everything that happens in our team and it surrounding - so I subscribe to all these events as a service of Github. However, there is almost never a chance to spot one event and process it immediately and fully. So, saving the content of any discussion for your and other's later reading is really a must. Thank you Daniel !!

[Thanood]

Haha, I just noticed the color switcher selects are also broken now. 😄

@adriatic I will do this more often now since I know I forget things and the above is complicated enough to let me forget it over the weekend. 😄

[Thanood]

for reference: Dogfalo/materialize#2670 (comment)

[Thanood]

I still don't get it really. The select <option>s seem to be updated but not the bound view model variable.
The plunk is different in that it updates a ChildInterpolationBinding while the bridge updates a SelectValueObserver.

The valueObserver which is commented out in current bridge code is updated. Still, if you issue a notify, nothing changes. Only when setting valueObserver.value directly, notify changes the bound array and the viewmodel is okay.

this.valueObserver.value = $(this.element).val();
this.valueObserver.notify();

In knockout/Durandal I'd do valueObserver.valueHasMutated() - so if anyone knows an equivalent.. 😄

Somehow I can't wrap my mind around that issue.

[Thanood]

Note to myself: read this https://github.com/jdanyow/aurelia-breeze-northwind/blob/master/src/resources/materialize.js

[adriatic]

Let me know how easy was it to read this code :-)

[Thanood]

Very easy. Everything is commented. 😄

Although I usually need to apply those things to some practice before I really understand it. In short, it's easy to understand what it does but I don't know yet why he does it.

One thing is apparent, though: He also circumvents problems with getting the selected value. Even by implementing dirty checking and using an own MutationObserver.
Maybe my workaround wasn't that "abusive" after all but there's another way to do exactly that without setting the observed value directly.

I will have to try it. 😄

[Thanood]

Could it be that easy...?
aurelia/framework#431

[Thanood]

No, it's not that easy...

Almost reproduced..
https://gist.run/?id=782e8648988619066b3065f6ba4655e1

Seems like I wouldn't have that problem if Materialize fired a custom event on change.

[Thanood]

Wow.. Turns out this is actually a problem (or intended behaviour) of combining string interpolation with valueConverters and array mutations. Data is set correctly but the output isn't updated..

Changing the output to a <ul> "fixed" this.