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

No way to listen for changes to this.element on modifier #798

Open
emattias opened this issue Feb 23, 2022 · 4 comments
Open

No way to listen for changes to this.element on modifier #798

emattias opened this issue Feb 23, 2022 · 4 comments

Comments

@emattias
Copy link

(This was originally an issue on ember-modifier here but it was concluded that its the underlying infrastructure that needs changing, not ember-modifier so I created the issue here instead.)

I built a modifier heavily based on @miguelcobain:s css-transitions modifier.

It lets you animate an element out by cloning it and keeping track of an elements nextElementSibling and insert the clone before it.

In this example I have an ember-dragula list implemented and every item in the list uses my custom-modifier.

I was able to work around it by adding a MutationObserver tracking removed nodes in the list and sending that array of removed nodes as an argument which triggers didUpdateArguments and in that I update nextElementSiblings. This fixes this problem, see video, showing the bug.

In the twiddle I add a green outline for 3 seconds when an element is removed. Notice how when the mutation observer the outline is on the wrong element for the second deleted item:

MutationObserver off

CleanShot.2022-02-14.at.19.41.12.mp4

MutationObserver on

CleanShot.2022-02-14.at.19.41.44.mp4

Maybe we could add something like a didUpdateElement event or have this.element changes trigger didUpdateArguments?

Or a better solution might be if we could hook in right before this.element is removed from the dom. That way we would not need to save the nextElementSibling on didInstall.

But if we can't add a hook to right before the element is removed from the dom I guess hooking in every time this.element is changed would also work.

@chriskrycho
Copy link
Contributor

Thanks for reopening over here. I believe willDestroy (and more importantly the destroyModifier API on which it is built) does first right before this.element is removed from the DOM; does it not?

@Panman82
Copy link

I'm not sure if this relates here, but one thing I've heard before with animation needs was access to the element before it is inserted into DOM. I don't think the current Modifier API provides that access. This isn't something I've dealt with personally, just something that has stuck with me for some reason. 🤷‍♂️

@jelhan
Copy link
Contributor

jelhan commented Mar 21, 2022

one thing I've heard before with animation needs was access to the element before it is inserted into DOM. I don't think the current Modifier API provides that access.

I created an issue about that limitation some time ago: #652 I run into it when using web components.

@wagenet
Copy link
Member

wagenet commented Jul 23, 2022

This appears to be a valid concern. What would it take to get this to RFC?

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

No branches or pull requests

5 participants