emberjs glimmer object set() with variable property name

Question

I have a component in Ember 3.15 where I am trying to do something like

import { action, set } from '@ember/object';

@action
someMethod() {
  const value = ... // something random
  let propertyName = ... // some variable string
  set(this, propertyName, value);
}

It seems to be working fine in the browser but typescript is flagging the set line as an error (specifically the propertyName argument). So if it works, why doesn't typescript like it?

This also seems to be happening with get() where it doesn't like variable propertyNames like get(this, propertyName).

score 2 · Answer 1 · answered May 01 '20 at 17:10

2

Generally if your property is @tracked you dont need set and can just do this[propertyName] = value;.

However your problem is probably a general typescript limitation. Actual a general problem of static typing:

Typescript does only static analysis. So it does not execute your code. So it can not know is a dynamically generated property key actually exists.

So if you have something like this:

class Foo {
  data1: number = 1;
  data2: number = 2;
  foo() {
    const fixedProp = 'data1';
    console.log(this[fixedProp]);
    const dynamicProp = 'data' + (1 + 1);
    console.log(this[dynamicProp]);
  }
}

Then typescript will not be able to verify if this[dynamicProp] actually exists because for this it would need to execute 'data' + (1 + 1); so it would know what dynamicProp actually is. So it is impossible to know if this[dynamicProp] exists by static analysis.

You can just tell typescript to do what you want by (this as any)[dynamicProp] and it will just ignore it. But generally if you dynamically compute property keys you can not rely on static analysis.

answered May 01 '20 at 17:10

Lux

17,835
5
43
73

That is good to know. I've never figured out how to use the keyaccessor via square brackets with typescript so thanks. However, for this specific use case, my variables are nested tracked properties. Because they're nested, from my understanding, you have to use the set() method for the Ember magic to work as just using @tracked doesn't work with nested properties. Maybe I could set it this way and then use the setPropertyChanged() method that Ember has. I'll try it next time I work on this project – Ian Kirkpatrick May 02 '20 at 14:19
1

A few notes: 1. You shouldn’t use either `set` *or* `setPropertyChanged` for these. Instead, you should restructure how you *model your data*. If you need those properties to be updated when changed, either update the whole root state (which means: don’t mutate them locally, do it in the class that owns them) or use `@tracked` for those properties directly on class that owns that state. 2. Don’t do `this as any` for the dynamic prop. Instead, either define the properties locally, or use the `keyof` operator to be more specific about what property names are allowed. – Chris Krycho May 08 '20 at 14:47
@ChrisKrycho why specifically should I avoid set? For my use case, I am interfacing with a 3rd party api where I have to navigate a large, complicated and dynamic structure of data. I track everything with `@tracked` but many of them are complex objects copied from the 3rd party data. – Ian Kirkpatrick May 09 '20 at 04:06
@IanKirkpatrick using `set` basically only “works” for you because it’s working *around* the auto-tracking model. I strongly recommend reading [this post](https://www.pzuraq.com/autotracking-case-study-trackedmap/) (by Ember Core team member Chris Garrett) to get a sense of how you can wrap other APIs (though the details will differ for you of course). The key is to wrap that third-party API in a system that correctly distinguishes “root” from “derived” state, where the root state is correctly autotracked and *nothing else knows or thinks about that at all*. – Chris Krycho May 09 '20 at 15:14

score 2 · Answer 2 · answered May 08 '20 at 15:07

There are two basic issues with the situation you have described—one of them related to TypeScript, one of them not.

The TypeScript issue is that TS is aware of the names of properties in general, and will check that you’re setting things correctly—both when using normal JS property lookup and assignment, and when using Ember’s get and set functions. Specifically, the types for Ember try to make sure you don’t end up typo-ing things when doing get and set. You can see why they don’t allow arbitrary strings in this example:

import Component from '@ember/component';
import { action, set } from '@ember/object';

export default class Whoops extends Component {
  greeting = 'Hello';

  @action updateGreeting(newGreeting) {
    set(this, 'greering', newGreeting);
    //         ----^--- TYPO!!!
  }
}

If the types for set (or get) just allowed arbitrary strings, TS couldn’t help you at all here; it would let it go, and you’d have to figure out the bug yourself—instead of the compiler helpfully telling you about it ahead of time.

In the case you’re running into, TypeScript presumably just sees a string, and it says “I don't have any way to check if this string belongs to the property.”

There are a couple ways to improve things here. First of all, if you can, you should figure out if it’s possible to constrain the type of propertyName to be a keyof for the type it’s coming from. (Explaining keyof is beyond the scope of this answer, this section in the handbook and this blog post will get you up to speed.)

Second, though, and connected to the bigger issue: you noted in discussion to the other answer on this question that the problem is that you’re trying to deeply set properties on a single piece of tracked root state. In general, you should not mutate autotracked state this way—it’s a holdover from the old observers-driven patterns that Ember Classic used with its computed properties. Instead, prefer to drive all changes to that autotracked state through the owner of that state. Then you won’t need set at all, and the system will update correctly automatically.

You can do that either by making the nested state itself be autotracked, either by defining a class for it or by using something like tracked-built-ins to wrap a plain JS object. Either way, instead of reaching in and deeply mutating that state from just anywhere, do it only on the object that owns that state. If you follow that pattern, and constrain the propertyName to be a keyof TheOwnerOfTheState where TheOwnerOfTheState is some class, everything will “just work”—both on the Ember side and the TypeScript side.

emberjs glimmer object set() with variable property name

2 Answers2