Missing support for nested properties in @tracked

[michalsnik]

Missing support for nested properties in @tracked

[mmun]

We'll be exploring some solutions to this issue soon.

That said, I'm actually excited to see how far we can get with shallow tracking. In ember, there is a cost to supporting things like @each. There's a large performance cost associated with managing all the observers it installs. There's also a burden on the developer to use Ember's array APIs when interacting with the array.

[MartinMalinda]

This is also needed for tracking the change of args. Though maybe there will be a workaround later when didUpdate hook is introduced.

[mmun]

@michalsnik The solution is to use the data down, actions up programming model. Instead of trying to mutate the state of the todo in the todo-item directly, you should pass a callback in that mutates the todos from the root.

I've been working on implementing the todomvc app in glimmer but I need to fix this bug first: #34

[michalsnik]

Thanks for a quick answer. I'm aware of the extra cost of this, but I'm not seeing other possible solutions to this problem. Also I found that if I pass object to a component, for example:

<todo-item @todo={{todo}} />

Then if I change one property of the given todo in parent component - the child component does not re-render. Is there any workaround to make it work?

[michalsnik]

@mmun I know DDAU and I never wanted to mutate todo in todo-item. The problem is even if I mutate single todo in todos' parent component - the child component (todo-item) won't re-render. Maybe if I'd pass name and state separately instead of the full object it would work, but that's something I'd like to avoid. I'd be happy to see how you proceed with todomvc :)

[mmun]

@michalsnik: Here's my first pass: https://github.com/glimmerjs/todomvc-demo.

The main data flow is set up, but there are still a few issues I'm going to leave for contributors.

[hoodwink73]

Coming from React world, it is very intuitive for me to think that whenever an argument to a child changes the component will re-render. But I think GlimmerJS chooses to re-validate the component tree whenever a tracked property is changed.

The current todo-mvc implementation chooses to create a todo store with title and completed as tracked properties.

import { tracked } from "@glimmer/component";

let _idSequence = 0;

export default class Todo {
  private _id: number = _idSequence++;

  @tracked title: string;
  @tracked completed: boolean;

  constructor(title: string, completed: boolean = false) {
    this.title = title;
    this.completed = completed;
  }

  toggle() {
    this.completed = !this.completed;
  }
}

So, a change to them should trigger a re-render. A new thing I noted here, one can have tracked annotation outside the component.

My understanding is still a bit blurry but I wanted to share it either way. I think the circumstances under which a glimmer app re-renders is a crucial piece to understand.

[rwjblue]

This repo has been merged with glimmerjs/glimmer.js (into a monorepo setup). I am not sure if this issue is still applicable, but if you could confirm it is still an ongoing concern and open it over there that would be very helpful.

Sorry for the noise, but thank you for your help!