I came across the same problem. In my case I want to run some code when a new element is dropped into a container element in the designer tool. Just wanted to check if there is a better way of doing this rather than using the 'not ideal' watchMutation function.
Thanks Sepand On Thursday, October 10, 2013 2:29:08 PM UTC-4, Scott Miles wrote: > > I think there's universal agreement the name (`onMutation`) is not good. > > So, thanks for the suggestions! > > Scott > > > On Thu, Oct 10, 2013 at 11:24 AM, Seth Ladd <[email protected] > <javascript:>> wrote: > >> Ah ha, makes sense. And helpful. >> >> Warning! Bikeshedding! Perhaps a name that better conveys this is a >> one-time callback? >> >> * onFirstMutation >> * whenMutates >> >> Thanks for the explanation, >> Seth >> >> >> >> On Thu, Oct 10, 2013 at 11:16 AM, Scott Miles <[email protected] >> <javascript:>> wrote: >> >>> It's tempting for users to use `async` or `timeout` to try to wait for >>> DOM updates after modifying some data. As we know, it's easy to get into a >>> race-condition this way, and so it's an anti-pattern. >>> >>> Going through our examples, I found some usage like this and wanted to >>> replace it with a mutation observer. In all those use cases, these were >>> one-off situations. I change this, then when the DOM updates, change that. >>> For this reason, I coded `onMutation` as a one-time use API. >>> >>> There are clearly use-cases that want continuous monitoring. It's >>> possible to do this using onMutation, but it's not ideal (see example). We >>> are working on a modification to make this easier, or to allow declarative >>> monitoring of shadow-roots, light-dom, or possibly individual nodes. >>> >>> Example of using onMutation for monitoring: >>> >>> >>> >>> >>> >>> watchMutation: function() { >>> >>> >>> >>> >>> var change = function() { >>> this.presentationChanged(); >>> >>> >>> >>> this.onMutation(this, change); >>> >>> >>> >>> }.bind(this); >>> >>> >>> >>> this.onMutation(this, change); >>> >>> >>> >>> } >>> >>> >>> >>> >>> Scott >>> >>> >>> >>> On Thu, Oct 10, 2013 at 11:06 AM, Seth Ladd <[email protected] >>> <javascript:>> wrote: >>> >>>> Hi all, >>>> >>>> I see onMutation (a nice helper!) here: >>>> https://github.com/Polymer/polymer/commit/528129c Why does it >>>> disconnect after the first mutation? >>>> >>>> If we expect that there will be many mutations to a node, should we >>>> just use the raw MutationObserver ? >>>> >>>> I like onMutation... it's easier to use, but I'd like it to not >>>> disconnect (unless I'm missing a subtle part of the API) >>>> >>>> Thanks for the context, >>>> Seth >>>> >>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Polymer" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected] <javascript:>. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/b760a005-7a77-48e2-bdd3-830c84a21df0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
