Repository navigation
Deprecate PromiseProxyMixin, Enumerable, and Observable (mixins, RFC#… - #21588
NullVoxPopuli wants to merge 5 commits into
Conversation
📊 Size reportTarball size — dist/dev 0.6%↑
Show files (33 files)
dist/prod 0.7%↑
Show files (32 files)
smoke-tests/v2-app-template/dist 1%↑
smoke-tests/v2-app-hello-world-template/dist 1%↑
🤖 This report was automatically generated by wyvox/pkg-size |
42d121c to
2271ebc
Compare
d6f0090 to
075a2b2
Compare
There was a problem hiding this comment.
I didn't want to expose all these new internal files as importable things, so they got filtered out
075a2b2 to
2e69858
Compare
| @public | ||
| */ | ||
| static create<M extends typeof Mixin>(...args: any[]): InstanceType<M> { | ||
| static override create<M extends typeof InternalMixin>(...args: any[]): InstanceType<M> { |
There was a problem hiding this comment.
docs above need @deprecated
There was a problem hiding this comment.
Shouldn't create also get marked @deprecated?
There was a problem hiding this comment.
idk, the whole class is deprecated - so it feels redundant.
27efb8f to
8ed880e
Compare
8ed880e to
831dd86
Compare
56bd561 to
a44ff39
Compare
| import Controller from '@ember/controller'; | ||
| import Service, { service } from '@ember/service'; | ||
| import { _ProxyMixin } from '@ember/-internals/runtime'; | ||
| import _ProxyMixin from '@ember/-internals/runtime/lib/mixins/-proxy-internal'; |
There was a problem hiding this comment.
I think this use should also go away when the deprecations are removed
There was a problem hiding this comment.
meaning I think it should get a guard
| @deprecated Invoke the corresponding method directly instead. | ||
| @param {String} actionName The action to trigger | ||
| @param {*} args Arguments to pass on with the action | ||
| @private |
There was a problem hiding this comment.
This one (and a couple of others) were private but are currently until: 8 because they share the TARGET_ACTION_SUPPORT deprecation that previously landed for public API
| public mixin emits. | ||
|
|
||
| @internal | ||
| */ |
There was a problem hiding this comment.
What's the point of the empty internal version?
There was a problem hiding this comment.
just using InternalMixin, so the Mixin class doesn't cause a deprecation -- needed until we remove EmeberArray
There was a problem hiding this comment.
tho, perhaps it could be removed entirely with no-effect. I need to look in to that.
There was a problem hiding this comment.
Yeah I don't think it does anything. It doesn't even maintain any inspecting of hierarchy now that it has a different name
| @internal | ||
| */ | ||
| // eslint-disable-next-line @typescript-eslint/no-empty-object-type | ||
| interface InternalMutableEnumerable extends InternalEnumerable {} |
There was a problem hiding this comment.
Again, empty internal version?
There was a problem hiding this comment.
same as Enumerable
| const Observable = DeprecatedMixin.create(InternalObservable, { | ||
| init() { | ||
| this._super(...arguments); | ||
| deprecateUntil( |
There was a problem hiding this comment.
Are there no docs for the Observable mixin that need to be marked @deprecated? Was it even public?
There was a problem hiding this comment.
hmm wonder why that's @class
but in that case, it needs an @deprecated
kategengler
left a comment
There was a problem hiding this comment.
Some comments. I want to generate the docs tomorrow and check out the result.
RFC #1116 deprecates applying Ember's mixins, but Ember's own internals are built on several of them. Those mixins need to exist twice: an internal copy that applies silently, and a public copy that emits the deprecation. This is the mechanical half -- the six mixins under @ember/-internals move to `-internal` filenames with their contents unchanged, and their importers follow. The public, deprecating copies are added in the next commit. Add deprecating public mixin wrappers (RFC #1116 follow-up) Every mixin Ember applies to its own classes now exists twice: the internal copy applies silently, and the public copy wraps it and emits the deprecation from `init`. The public copies keep the API documentation; the internal copies carry the implementation. `Mixin` itself gets the same treatment -- `InternalMixin` holds the machinery and `Mixin.create` is the deprecating subclass -- which lets the `INTERNAL_MIXIN_CREATE` symbol go away entirely. Because the two copies are distinct objects, `meta.hasMixin` would no longer match a public mixin against an object that only ever had the internal copy applied. `DeprecatedMixin` overrides `detect` to look through to the wrapped copy, so `EmberArray.detect(someArrayProxy)` keeps working while the deprecation is live. Ember's own tests that exercise a mixin's behavior now apply the internal copy, matching what the framework does; tests that specifically cover the deprecation keep using the public copy. `EmberObject` already applies the internal `Observable`, so `observable_test` no longer re-applies the public one on top. The internal copies are kept out of `renamed-modules` so they are not advertised as importable module paths. Move deprecations to 7.5 Set deprecate flags, and update untils
Tests imported the silent `-internal` copies of the deprecated mixins. Such a test stays after the deprecation is removed, and it keeps the internal copy in use. These tests now import the public mixin, expect its deprecation, and use `testUnless(...isRemoved)`. They go away with the deprecation. - `EmberArray` in `runtime/tests/mixins/array_test.js` - `MutableArray` in `glimmer/tests/integration/helpers/tracked-test.js` - `ContainerProxyMixin` in `container_proxy_test.js` - `TargetActionSupport` in `target_action_support_test.js` - `_ProxyMixin` in `ember/tests/service_injection_test.js` `TestArray#init` in `array_test.js` now calls `super.init`. Without that call, the deprecation of the mixin does not fire. Three tests in `array_test.js` do not use the mixin. They moved to their own module, so they still run after the removal. `mixin/deprecation_test.js` still imports `InternalMixin`. That test checks that the internal constructor does not fire the deprecation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A production build runs one assertion for all deprecation expectations of a test. A development build runs one assertion for each expectation. Two expectations made `assert.expect` fail in the production build jobs. Each test now has one expectation. Its pattern matches the mixin deprecation and the `triggerAction` deprecation. The `assert.expect` counts are back to their values on the base branch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3ba8803 to
44e5959
Compare

Supersedes:
Advancement:
"Deprecating Mixin Support"to Stage Ready for Release rfcs#1143RFC:
Guides:
Best viewed with:

Note
Because of the strategy of this deprecation (internal + public extends + deprecate), our tests don't have a lot of the testUnless stuff. We still need the tests because many of these mixins are still used internally. This makes this deprecation a bit different from the other ones due to how entangled mixins our in the codebase