Atoms re-render whenever parent node updates (?)

[joshfrench]

Once I've added an atom, its render() method is fired on any subsequent changes in the same section. For the Ember editor (and now the React version 😁) this means the ADD_ATOM_HOOK also fires again, and you end up with N+1 objects in componentAtoms which are never cleaned up.

Not sure if this is by accident or design, since cards don't exhibit this behavior (or more accurately can't, because you can't edit their node.) If it is intentional I'll open a bug in the Ember editor for cleaning up the orphaned componentAtoms.

[bantic]

Thanks for reporting this.
You're right, cards avoid this behavior because they never need to be re-rendered.
But sections do get re-rendered on each change.
Can you use the atom's onTeardown hook to handle any cleanup necessary? E.g.:

// atom.js
{
  render({env}) {
    env.onTeardown(() => {
      // do atom cleanup here
    });
  }
}

[joshfrench]

onTeardown doesn't fire when the atom gets re-rendered as part of a section update, only when it's manually deleted/removed.

This is mostly a data sanitation thing. I'm not an Ember dev and my debugging skills there are limited, but I'm pretty sure every time an atom re-renders as part of a section update, the ADD_ATOM_HOOK adds another ref to it in componentAtoms and they're probably never getting GC'd. I didn't take quite the same path in the React version, but the same root cause still leaves me with a bunch of orphaned DOM nodes hanging out in memory (I haven't played around enough to confirm/deny whether those are getting GC'd eventually.)

[bantic]

@joshfrench Yeah, you're absolutely correct. Data sanitation and also memory pressure concerns.
I'm going to make a parallel issue on the ember-mobiledoc-editor repo, too. The eventual goal here is minimal-as-possible rerenders, but that's a little ways off. :) I'll investigate and add some notes here.