Skip to content
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

Closed

Conversation

NullVoxPopuli
Copy link
Contributor

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

Copy link
Member

@rwjblue rwjblue left a 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 {}
);

.travis.yml Outdated Show resolved Hide resolved
addon/modifiers/did-insert.js Show resolved Hide resolved
addon/modifiers/did-update.js Show resolved Hide resolved
addon/modifiers/will-destroy.js Show resolved Hide resolved
package.json Show resolved Hide resolved
tests/integration/modifiers/did-update-test.js Outdated Show resolved Hide resolved
@@ -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 }),
Copy link
Member

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...

Copy link
Member

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: |

Copy link
Contributor Author

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?

Comment on lines 66 to 72
installModifier(state, element) {

installModifier(instance, element, args) {
// save element into state bucket
state.element = element;
instance.element = element;
Copy link
Member

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

Copy link
Contributor Author

@NullVoxPopuli NullVoxPopuli Oct 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NullVoxPopuli
Copy link
Contributor Author

travis build for ember 3.12 needs to be re-run I think? it crashed before the actual relevant-parts-to-this-PR began

@NullVoxPopuli
Copy link
Contributor Author

green!

@@ -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"
Copy link
Member

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

Comment on lines +75 to +84
// 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];
}
Copy link
Member

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)?

Copy link
Contributor Author

@NullVoxPopuli NullVoxPopuli Oct 19, 2020

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?

Copy link
Contributor Author

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

Copy link
Member

@rwjblue rwjblue Oct 19, 2020

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.

Copy link
Contributor Author

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 :/

@rwjblue rwjblue marked this pull request as draft October 19, 2020 14:16
@NullVoxPopuli NullVoxPopuli marked this pull request as ready for review October 19, 2020 15:01
@NullVoxPopuli
Copy link
Contributor Author

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

nbibler added a commit to railsdiff/railsdiff that referenced this pull request Apr 9, 2021
This fixes a deprecation and removes the anti-pattern.

See emberjs/ember-render-modifiers#25.
@SergeAstapov
Copy link
Contributor

this addon is an anti-pattern in modern code

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants