enyo.Select BUG

edited February 2015 in Enyo 2.5
Hello all,

I'm needing some advice on a workaround for a fairly annoying bug in enyo.Select.
For some reason, I think it's because of the new style "set" and "get" methods, you can no longer set the selected property on an enyo.Select at create time. The only way to set the selection is after render.

Here's some fiddles:
enyo 2.2.0 http://jsfiddle.net/mmwfq7fe/ --- works
enyo 2.4.0 http://jsfiddle.net/mmwfq7fe/1/ --- works
enyo 2.5.1 http://jsfiddle.net/mmwfq7fe/2/ --- broken
enyo nightly http://jsfiddle.net/mmwfq7fe/3/ --- broken

This makes using things like bindings and view controllers a real treat. It seems that an
enyo.ViewController will run create - render - then initialize bindings on it's first view, but likes to run create - initialize bindings - render for subsequent views because you have to make it render it's new view when you swap them out.

Here's a fiddle:
http://jsfiddle.net/ez3k0m1o/

If anyone can give some advice on how to bind the selected property of an enyo.Select to an enyo.ModelController and still be able to set the selected property when you swap the view out and back in, it would be much appreciated, because quite frankly I'm dying here.

Comments

  • You're right there's a bug here but it's not with the bindings. That's working correctly. The issue is an order of operations problem in the rendered() method of enyo.Select. This manifests when setting selected on the control in the components block as well.

    Here's a hacky workaround pending a framework fix: http://jsfiddle.net/ez3k0m1o/1/

    Longer Version ...
    If you set a breakpoint in enyo.Select.selectedChanged(), you'll see it hits twice: once with the right value, once with the wrong. The right value is set via bindings but then overridden later in the render lifecycle. The cause is the order the methods are called in rendered; specifically, selectedChanged() should be called before change().

    Now, selectedChanged is called first during the create() phase when bindings are evaluated. However, since the enyo.Select hasn't been rendered, it can't be propagated to the node. When rendered is called, change() is first called which extracts the value of selectedIndex (via getSelected()) from the node and sets it onto selected. Since the desired value couldn't be set on the node earlier, getSelected() grabs the default value 0 from the node and that gets set as selected.

    The simple solution is to swap the order of selectedChanged and change in rendered(). That's effectively what the workaround does by injecting a call to selectedChanged() before calling the super. Some refactoring is probably in order to call it a real fix.


  • @theryanjduffy Thank you very much for your reply and workaround. I didn't mean to suggest that the bug was with the bindings (though after an almost 20 hour day I might have). I appreciate your looking at this so quickly. I created a Jira ticket for this issue at the time I made this post. The ticket is here: https://enyojs.atlassian.net/browse/ENYO-4131 in case you need a reference or so that a duplicate is not created.
  • Here's an updated fiddle with the pull request i submitted added in....
    Seems to be working good:

    http://jsfiddle.net/ez3k0m1o/2/


    I am working on an app right now that has many of these select boxes, and they were giving me a big headache.
  • This should also be fixed by https://github.com/enyojs/enyo/pull/1052. Credit to @chrisvanhooser for the resolution!
Sign In or Register to comment.