# Problem tracking nested structure
**URL:** https://meta.discourse.org/t/problem-tracking-nested-structure/320886
**Category:** Development
**Created:** [August 9, 2024, 12:12pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886 "2024-08-09T12:12:57Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [August 9, 2024, 12:12pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/1 "2024-08-09T12:12:57Z")
I’m inserting a Glimmer component in `topic-above-footer-buttons`. This Glimmer component attempts to show some metadata about the topic. I am serializing these to `topic.my_metadata`
When the metadata is updated from a background job(!), the topic refreshes via `MessageBus.publish("/topic/#{topic.id}", { reload_topic: true, refresh_stream: true })`
Now this correctly updates in the template:
`{{this.args.topic.my_metadata.status}}`
However, when I access it via a getter
```plaintext
get statusMessage() {
return this.args.topic.my_metadata.status;
}
```
then
`{{ this.statusMessage }}`
does not update.
(And the same goes for all getters that I have that depend on `this.args.topic.my_metadata` in any way. Which is the actual problem).
What am I doing wrong?
I’ve already tried a lot, including defining custom events, copying `topic.my_metadata` to a `@tracked metadata` and then using `this.metadata`, etcetera.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 9, 2024, 12:30pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/2 "2024-08-09T12:30:56Z")
I think you are only guaranteed a getter will be re-evaluated if one of the values it relies on is tracked (and that changes)
so in this case I think `{{this.args.topic.my_metadata.status}}` is better, though btw you should write it like: `{{@topic.my_metadata.status}}`
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [August 9, 2024, 12:35pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/3 "2024-08-09T12:35:11Z")
Well, it’s not a matter of “better” or not, there is a lot of logic in Javascript evaluating the metadata and for instance deciding of a button should be shown, like
```plaintext
get showButton() {
// do some heavy stuff on this.args.topic.my_metadata.foo and this.args.topic.my_metadata.bar
}
```
so I _need_ the getters and I need them to reevaluate _somehow_.
Additionally, the Glimmer documentation says _args and its values are automatically tracked_.
If the template is able to autotrack them, why can’t the getter?
Even this works, passing the metadata as an argument
```plaintext
{{this.getStatus this.args.topic.my_metadata}}
```
with
```plaintext
getStatus(arg) {
return arg.status;
}
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [August 9, 2024, 12:54pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/4 "2024-08-09T12:54:30Z")
This is an unfortunate part of us being midway-through converting from Ember’s ‘classic’ reactivity system (get/set/computed) to the ‘octane’ `@tracked` / native-getters.
So as discussed above, the problem with your example is that you’re accessing a non-`@tracked` property from a native getter.
Accessing the full path directly from a template will work, although as you say, it limits the logic available.
Alternatively, using `.get()` will allow Ember’s new autotracking system to work against classic (i.e. non-`@tracked`) properties.
So in this case, it would be
```js
get statusMessage() {
return this.args.topic.get("my_metadata.status");
}
```
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 9, 2024, 12:57pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/5 "2024-08-09T12:57:56Z")
thanks David
could you also solve this with `@computed` or is that a no-no?
```plaintext
@computed('args.topic.my_metadata.status')
get statusMessage() {
// this might be a lot more complicated
return this.args.topic.my_metadata.status;
}
```
I believe this would have the benefit of caching the result if the computation was significant.
(obviously trivial in this example but something @RGJ alluded to)
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [August 9, 2024, 1:35pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/6 "2024-08-09T13:35:26Z")
`@computed` is part of Ember’s classic reactivity system. It’s not officially deprecated, but we try to avoid adding it to new code.
If your getter is complicated enough to warrant caching, then you can use [`@cached`](https://api.emberjs.com/ember/release/functions/@glimmer%2Ftracking/cached):
```js
import { cached } from "@glimmer/tracking";
...
@cached
get statusMessage() {
// this might be a lot more complicated
return this.args.topic.my_metadata.status;
}
```
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [August 9, 2024, 1:49pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/7 "2024-08-09T13:49:55Z")
> [@david](#):
>
> Alternatively, using `.get()` will allow Ember’s new autotracking system to work against classic (i.e. non-`@tracked`) properties.
This works like a charm. Thank you for saving the remainder of my Friday @david !!! Much appreciated!!
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [September 8, 2024, 1:50pm UTC](https://meta.discourse.org/t/problem-tracking-nested-structure/320886/8 "2024-09-08T13:50:26Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.