bindings of enyo

I have asked this question in twitter:
Is it possible to use bindings to bind a value to the style? like bind a value to the color of style? If yes, how? Thanks

Dave Freeman ‏@sugar_dave answered me:
@zhy1378 @EnyoJS probably better to bind a value to "classes" instead then let the CSS class name handle it.

And I wrote this:
But it's not flexible. Can enyo implement a @ selector? use [email protected]@color to visit the attributes of an object.

Now:
I tested bindings to style or classes, it works. But, I don't think use . is a good idea. If there is an inner object names "style" or "classes", it may cause ambiguity. I recommend an @ grammar like this:
@[email protected]/color... to visit the key/value pairs of the style of an .

And a bug report: The sampler of moonstone( moonstone/samples.html ) works well on Firefox, but it doesn't work properly on Chrome, Safari or Opera.

Comments

  • There is a reason why @sugar_dave replied with the suggestion to use classes. Most of the time, if you need to adjust the color of something in the UI, it's due to some kind of state change. If you use a css class to represent that state, you only need to apply or remove that one single css class and you're all set:
    enyo.kind({
        kind: "myButton",
        isPressed: false,
        // example binding added, because your original question involved bindings
        bindings: [{
            kind: enyo.BooleanBinding,
            from: ".owner.isPressed",
            to: ".isPressed"
        }],
        isPressedChanged: function() {
            this.addRemoveClass("button-pressed", this.get("isPressed"));
        }
    });
    The real benefit of just using a css class is that your JavaScript code doesn't have to concern itself with the visual representation of that state. For example, lets say your designer decides tomorrow that the button-pressed state is better represented with a css transition that involves not only color, but shadows and borders as well:

    - If you'd be using bindings to individual css properties, you would then need to add new bindings for borders, transitions, shadows, etc. Imagine doing this for multiple states, things could become very complicated very quickly!

    - If, on the other hand, you're using a .button-pressed css class to represent the state, all you have to do is change your css file and add some styles for border, shadows and transitions. Your JavaScript can stay unchanged, no additional complexity required.

    Having said that, I understand there may be scenario's where the color is best applied as a style (a color-picker input comes to mind as a possible scenario).

    If you really do need to represent the css color directly in your JavaScript code, I would suggest creating a property on your component that contains the color value. You can then use a change handler to apply new colors to your element. This is almost certainly much, much easier than trying to bind to styles directly:
    enyo.kind({
        kind: "myColorizedControl",
        color: "#fff",
        // example binding added, because your original question involved bindings
        bindings: [{
            from: ".owner.color",
            to: ".color",
            allowUndefined: false
        }],
        colorChanged: function() {
            this.applyStyle("background", this.get("color"));
        }
    });
  • I think Enyo should be far more intelligent. If a bindings is used to a css property, only this property is changed. The other properties, should stay what they were.

    Hence, Enyo could implement a "clever" grammar: Multiple bindings.
    My design is, if bindings target is the style property, the return result could be a JSON object. like:
    { color: blue; top: "10px"; left: "20px"; }

    And Enyo will update only the corresponding attributes.

    if the original css is: "color: red; top: 30px; background: green;"
    The background attribute wouldn't change.

    Therefore, this bindings style could be also used to generate an HTML tag. Put every calculation in one function could be an efficient way.

    If my suggestion is accepted, do u mind I join the Enyo developer team and implement it?

    Thanks very much for replies, I know my English is really poor.
  • I'm not a member of the Enyo team, I'm just a developer like yourself. However, if you think you have a good update for the framework, you can always open a pull-request on github or discuss changes on the google groups or even write a message to one of the core developers here on the forum.

    On the specific topic of dealing with styles using objects, I know the core team switched towards using strings and string-manipulation to manage styles somewhere between version 2.4 and 2.5. When I asked why the team decided to switch to using strings, they told me that manipulating the string turned out to be a much better solution in terms of performance.

    Considering the fact that styles are manipulated during animations, it makes sense to consider performance as something very important. As such, my personal preference would probably be to not weigh down the implementation with bindings. Adding binding support means you need to always do a diff and look for handlers for every change you make even though most of the time there will not be any.

    If this is something you'd really like to have just for a particular use-case, you could always implement it as a mixin. Keep in mind, it probably won't be easy, there are a lot of moving parts in enyo's internals.
  • I had come across a library (For backbone, I think...) that implemented bindings for css properties. I can't find it now but it seemed to be fairly elegant. That said, it didn't seem to fit in directly with what we were doing with Enyo bindings. You might take a look and see if you can find it and see if extending bindings might make sense for your project. However, I still strongly support the idea of using classes for the reasons that Ruben pointed out.
Sign In or Register to comment.