Manipulating relationship in component

I have a component that receives a model A with a belongsTo relationship to model B. There are properties of B that I would like to render in A’s component, after doing some manipulation on them. Let’s say B has some property X that I need to manipulate with some function F before rendering it. One option would be to make F a template helper and just write in my template {{F A.B.X}} but say I have good reasons to instead want to apply F in the component’s js file. I tried doing something like this:

export default class MyComponent extends Component {
    get y() {
        return f(this.args.a.b.x)
    }
}

and then:

{{this.y}}

However that doesn’t work because this.args.a.b is a “proxy” object, which I guess would need to be awaited. However, a getter function cannot be asynchronous.

What approach do you suggest I pursue here?

And if you’re wondering why I’d rather not use helpers, it’s because I have lots of post-processing that I need to do on B’s properties, and it feels tedious to create a helper for each.

Yeah unwrapping these proxies can get tedious. If you can’t convert the relationship to synchronous, or unwrap the relationship before passing it into the component, the easiest way is probably just good old fashioned Ember.get:

    get y() {
        return f(this.args.a.get('b.x'));
    }

Thanks! I did actually try that and it works unless you write it like this:

get b() {
    return this.args.a.get('b');
}

get y() {
    return f(this.b.x) // or even f(this.b.get('x'));
}

Which is what I tried to do. Because I also have a z getter that also depends on b and didn’t want to write the full path (this.args.a.get('...')) again and again and instead was trying to do something like:

get y() {
    return f(this.b.x);
}

get z() {
    return g(this.b.w);
}

Anyways, it’s not a big deal, and it seems like the way to go is to go synchronous.

Thanks for the response.

Yeah I think this is still a pain point in terms of ergonomics after ES5 getters landed, then native modules and autotracking, etc but it gets a little better once you can hash out the specifics (like when you’ve got a proxy vs a record and how that affects the getters and autotracking) and then you can develop some patterns around it.

I don’t really know what I’m talking about here and I’m not up on the Ember Data roadmap so chalk this up to wild speculation but I think since Ember 4.0 dropped IE11 support Ember Data could theoretically use native proxies now and it’s possible that all of this could behave a lot more nicely in the future :crossed_fingers:

1 Like