-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(modifier-managers): use 3.22 capabilities #25
Conversation
3ac6f20
to
3c0ccc9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, this can be done without a breaking change. Bring in either ember-compatibility-helpers or @embroider/macros
and use the appropriate manager API version based on the running Ember version.
Something like:
import { gte } from 'ember-compatibility-helpers';
import { setModifierManager, capabilities } from '@ember/modifier';
export default setModifierManager(
() => ({
capabilities: capabilities(gte('3.22.0') ? '3.22' : '3.13', {
disableAutoTracking: true,
}),
createModifier() {},
installModifier(_state, element, args) {
let [fn, ...positional] = args.positional;
fn(element, positional, args.named);
},
updateModifier() {},
destroyModifier() {},
}),
class DidInsertModifier {}
);
3c0ccc9
to
267ef12
Compare
addon/modifiers/did-update.js
Outdated
@@ -58,7 +59,7 @@ import { setModifierManager, capabilities } from '@ember/modifier'; | |||
*/ | |||
export default setModifierManager( | |||
() => ({ | |||
capabilities: capabilities('3.13', { disableAutoTracking: true }), | |||
capabilities: capabilities(gte('3.22.0') ? '3.22' : '3.13', { disableAutoTracking: true }), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to chat with @pzuraq about this one (did-insert and will-destroy seem fine). Specifically RE: disableAutoTracking
. If we move to using 3.22 version of modifier managers we would not get rerendered when our own args change (kinda the point of did-update
IMHO).
I don't know what the intersection of using the args proxy and using disableAutoTracking
will do...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is that this is why the tests are failing in 3.22:
not ok 5 Chrome 62.0 - [61 ms] - Integration | Modifier | did-update: it basically works
---
actual: >
null
stack: >
at Object.<anonymous> (http://localhost:7357/assets/tests.js:167:21)
at processModule (http://localhost:7357/assets/test-support.js:3963:17)
at module$1 (http://localhost:7357/assets/test-support.js:3988:4)
at Module.callback (http://localhost:7357/assets/tests.js:165:21)
at Module.exports (http://localhost:7357/assets/vendor.js:111:32)
at requireModule (http://localhost:7357/assets/vendor.js:32:18)
at TestLoader.<anonymous> (http://localhost:7357/assets/test-support.js:14870:11)
at TestLoader.require (http://localhost:7357/assets/test-support.js:14860:27)
message: >
Expected 4 assertions, but 0 were run
negative: >
false
browser log: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I figured it out?
267ef12
to
8c12abf
Compare
8c12abf
to
b757d8a
Compare
addon/modifiers/did-update.js
Outdated
installModifier(state, element) { | ||
|
||
installModifier(instance, element, args) { | ||
// save element into state bucket | ||
state.element = element; | ||
instance.element = element; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert this. The name of the first variable should not be instance
(bucket
is what we commonly use, but state
is still better than bucket
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does that mean that this should change to state? https://github.com/ember-modifier/ember-modifier/blob/master/addon/-private/class/modifier-manager.ts#L32
16b1319
to
d2d310f
Compare
travis build for ember 3.12 needs to be re-run I think? it crashed before the actual relevant-parts-to-this-PR began |
d7972e7
to
e530408
Compare
green! |
BREAKING CHANGE: destruction behavior changed to use new args proxy from 3.22 Resolves the issue described by: emberjs/ember.js#19162 fixed by: emberjs/ember.js#19163
9356885
to
6c06e0b
Compare
@@ -3,10 +3,9 @@ language: node_js | |||
node_js: | |||
# we recommend testing addons with the same minimum supported node version as Ember CLI | |||
# so that your addon works for all apps | |||
- "6" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to land in the other PR first
// consume all args | ||
for (let i = 0; i < args.positional.length; i++) { | ||
// "noop" / consume the arg | ||
args.positional[i]; | ||
} | ||
|
||
for (let key of Object.keys(args.named)) { | ||
// "noop" / consume the arg | ||
args.named[key]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, we definitely shouldn't do this. We should either stick with 3.13 capabilities (which does this for us) or fix the tests to actual consume.
@pzuraq what did the RFC say about rerunning RE: the arguments changes? Does it mention auto tracking (and therefore infer that consumption is required)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, we definitely shouldn't do this.
I don't think a did-update hook is possible to exist then :-/ (with capabilities 3.22)
it order for the update
to run, tracked things must be consumed during install.
We should either stick with 3.13 capabilities
this might be a good option. More discouraging of ember-render-modifiers to last into long-lived code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this very much a wip, but I'm gonna be doing these sorts of tests for ember-modifier, too: NullVoxPopuli#1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this very much a wip
Moved to draft state
I don't think a did-update hook is possible to exist then :-/ (with capabilities 3.22)
Works fine, you just have to consume what you care about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do you do that consumption? Did-update will not consume without running, and it won't run without an update. That leaves the only option to consume during install.
Moved to draft state
I meant the linked PR :/
After talking with @pzuraq about this, I'm gonna close it :D It doesn't make sense to use 3.22 capabilities, since this addon is an anti-pattern in modern code anyway. :D |
This fixes a deprecation and removes the anti-pattern. See emberjs/ember-render-modifiers#25.
@NullVoxPopuli do you mind to share some info about that statement? Seems waky to hear that about what guides do teach us in https://guides.emberjs.com/release/components/template-lifecycle-dom-and-modifiers/#toc_calling-methods-on-first-render |
BREAKING CHANGE: destruction behavior changed to use new args proxy from 3.22
Resolves the issue
described by: emberjs/ember.js#19162
fixed by: emberjs/ember.js#19163