Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type: class to support some kind of mapping or parse function #12

Closed
jrmyio opened this issue Aug 13, 2014 · 5 comments
Closed

Type: class to support some kind of mapping or parse function #12

jrmyio opened this issue Aug 13, 2014 · 5 comments

Comments

@jrmyio
Copy link

jrmyio commented Aug 13, 2014

I came across an issue where my model has a "status" property that can be "phase1", "phase2" or "phase3" and my classes are equal but prepend "widget-". When I try to use the bindings to change the class of the view element there is no way to prepend, append or parse the class name.

As a work around I had to poison my models with class properties. In my opinion models should not contain any CSS information so i propose the following syntax to make my usage possible without modifying the models:

bindings: {
            'model.status' : {
                type: 'class'
                parse: function(status){
                        return "widget-" + class;
                }
            }
}
@legastero
Copy link

Ah, I've had to deal with this situation before a few times. Creating derived properties on the view was what I ended up with:

    derived: {
        widgetStatus: {
            deps: ['model.status'],
            fn: function () {
                return 'widget-' + this.model.status;
            }
        }
    },
    bindings: {
        widgetStatus: {
            type: 'class'
        }
    }

@kamilogorek
Copy link

+1 on this. Classes namespacing may come handy when working with really generic APIs.

@jrmyio
Copy link
Author

jrmyio commented Aug 13, 2014

Views can hold props/derived? I made a AmpersandJS/ampersandjs.com#81 on this undocumented feature.

However, I think the proposal still stands.

@chesles
Copy link
Contributor

chesles commented Nov 12, 2014

+1 on this -

Defining a derived property on the view is a decent workaround, but quite often there's something you want to do just to transform the value of the model's property before displaying it, whether it's prefixing a class, formatting a date or a number, etc. It's not ideal to have to define a bunch of formatted_[property] or prefixed_[property] properties that are just an extra layer between what is actually being rendered. It would be nice to define that function right there as part of the binding, as proposed here.

I think the option should be named something like format or transform instead of parse to make it clear what the function is meant to do: not necessarily parsing anything, but formatting or transforming the value for display.

@pgilad
Copy link
Member

pgilad commented Aug 30, 2015

Closing this as a duplicate of #13 - It will be resolved there.

@pgilad pgilad closed this as completed Aug 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants