Implement trackedObject, trackedSet, trackedWeakSet, trackedMap, and trackedWeakMap

[NullVoxPopuli]

RFC: emberjs/rfcs#1068

Followup to: #1713

Changes from the tracked-built-ins implementation (as described by the RFC)

• use tags directly, don't use cache / tracked-storage apis (these don't exist anyway)
• defaults to Object.is for the equals function
  • this means that equality / dirty checking is value-based by default, rather than every assignment causing a dirty
• has overridable equals function
  • to get tracked-built-ins behavior back, you set equals: () => false
    example:

    class TrackedArray {
      constructor(input) {
        return trackedArray(input, { equals: () => false });
      }
    }

• description is currently unused, but @wycats has plans -- description is meant for debugger hints

Progress:

• trackedWeakSet
• trackedWeakMap
• trackedSet
• trackedMap
• trackedObject

Tasks for self-review

• all collections have some expectType tests
• tests for specifying equals

I found an issue with reactivity in the array implementation and I'm investigating that in a separate PR here: #1761

these other collections (for now) are more straight-forward

[github-actions]

	This PR	main
Dev	600K └─┬ . 169K ├── runtime 160K ├── syntax 100K ├── compiler 58K ├── opcode-compiler 36K ├── validator 27K ├── manager 11K ├── program 8.9K ├── reference 7.2K ├── destroyable 6.3K ├── util 4.3K ├── node 3.4K ├── global-context 2.5K ├── wire-format 1.0K ├── vm 969B ├── encoder 844B ├── vm-babel-plugins 606B └── owner	588K └─┬ . 169K ├── runtime 160K ├── syntax 100K ├── compiler 58K ├── opcode-compiler 27K ├── manager 24K ├── validator 11K ├── program 8.9K ├── reference 7.2K ├── destroyable 6.3K ├── util 4.3K ├── node 3.4K ├── global-context 2.5K ├── wire-format 1.0K ├── vm 969B ├── encoder 844B ├── vm-babel-plugins 606B └── owner
Prod	236K └─┬ . 70K ├── syntax 63K ├── runtime 48K ├── compiler 18K ├── opcode-compiler 9.8K ├── validator 7.9K ├── manager 4.8K ├── program 3.6K ├── reference 2.4K ├── util 2.1K ├── node 1.6K ├── wire-format 1.5K ├── destroyable 737B ├── vm 594B ├── global-context 516B ├── encoder 469B ├── vm-babel-plugins 155B └── owner	231K └─┬ . 70K ├── syntax 63K ├── runtime 48K ├── compiler 18K ├── opcode-compiler 7.9K ├── manager 5.1K ├── validator 4.8K ├── program 3.6K ├── reference 2.4K ├── util 2.1K ├── node 1.6K ├── wire-format 1.5K ├── destroyable 737B ├── vm 594B ├── global-context 516B ├── encoder 469B ├── vm-babel-plugins 155B └── owner

[chandlerprall]

is it worth adding a test asserting updating to the same value doesn't cause an update, for the default equals?

[NullVoxPopuli]

do you mean something different from the first test in the file?

[chandlerprall]

Ah, I imagined an extra test case at the top which this idea mirrored. nvm this

[chandlerprall]

❓ just curious if there are existing thoughts on a fully-managed object, where
nested objects/values would be tracked

[NullVoxPopuli]

how do you mean?

[chandlerprall]

Thinking about something that proxies the whole object shape, to handle this type of case

const var = trackedObject({ foo: 123, bar: { zig: 'zag' } });
var.bar.zig = '...'; // reading var.bar is tracked but the write to zig isn't

const bar = var.bar; // read is tracked
bar.zig = '...'; // subsequent reads from here aren't, and update isn't

[NullVoxPopuli]

You may be interested in this rfc:

emberjs/rfcs#1079

[chandlerprall]

commenting this line out has no effect, looks like the test approach isn't correct?

[NullVoxPopuli]

Perhaps, ya. These were copied directly from tracked-built-ins -- i didn't put any thought in to them.

I would personally test reactivity a bit differently.

But i don't want to do that until we merge the ember and glimmer-vm monorepos

[chandlerprall]

Changes LGTM