-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
onParentChange callbacks #137
Comments
@yurique Sadly this won't make it to 17.x, too many other features. |
No worries! I can barely remember what I wanted this for :). Definitely no rush with it. |
Ok cool, I'll keep applying the same prioritization logic for now then :) |
Came across another potential use case for it: If you add a ResizeObserver to the element's parent, so that you can resize the element when the parent changes size (e.g. for an svg chart element to fill the entire available space), you may want to know if/when the element is moved, because onMountUnmountCallbackWithState only fires if the element is actually unmounted, and normally, moves from one mounted element to another should not trigger a re-mount (pending #163). |
Laminar elements can in theory be moved from one parent to another without unmounting. Few people knowingly use that feature, but it's possible, especially in Laminar 15.x.x. In those cases, certain advanced use cases (Frontroute URL routing, or integration with third party JS libs) might require notifications about such moves.
I think I can implement
onBeforeParentChange
andonAfterParentChange
callbacks at no performance or complexity cost to users who don't need them. I'm not yet sure which one of those I will implement (feedback welcome). I do not plan to implement any other helper methods (*bind, *insert, etc.). I'm also not yet sure if these callbacks should fire on any parent change, or only if the element is mounted and remains mounted after the change.Also, if the callback is to provide a reference to the next or previous parent, make sure this does not jeopardize GC – by the time the callback finishes, the reference to the old parent should be GC-d if it's not actually used, even if the callback spawned other closures (that also have access to the old parent reference, but don't use it). Figure out how to test for that.
Requested by @yurique
The text was updated successfully, but these errors were encountered: