On Wednesday, March 1, 2017 at 9:30:32 PM UTC, Rupert Smith wrote: > > On Wednesday, March 1, 2017 at 4:24:54 PM UTC, Witold Szczerba wrote: >> >> So, you ask for a list of mutations and then, for each mutation you >> repeat exactly the same procedure which is not related to the mutation you >> are currently at. >> Why are you iterating over mutations? >> > > Good point. No need to iterate, its just got left in there from your code. > > Using a MutationObserver to implement a ResizeObserver does not seem the > best idea. I don't really like that I end up scanning from the top instead > of looking at an actual mutation 'target'. But this trick of putting the > observer at the top is needed to get around the virtual DOM issue that > prevents the observer being placed on the actual node that I want to watch, > so I suppose doing a scan from the top on any mutation is justified as it > is part of this workaround. > > A ResizeObserver would be better its 'target' would definitely be the > thing being resized - not having to guess something is resized because it > or one of its children was mutated. I think ResizeObserver is not so well > supported though, which is why I stuck with MutationObserver. I called the > Elm module I wrote around it ResizeObserver, with a view to rewriting it > with a ResizeObserver at some future time when ResizeObserver is widely > supported. >
A more efficient way might be to start at the 'target' of the mutation, but then scan up the DOM ancestry until a node with the matching class us found, using jquery .closest: https://api.jquery.com/closest/ Using that approach I would iterate all the mutations and scan upwards for each one. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
