Broken rendering when removing elements

I am adding/hiding elements within my <Masonry> component in response to a filter bar (kinda like what Isotope does). Everything works beautifully with animation, except removal of elements at the top of the Masonry layout:

When I have items 1-20 in the Masonry component, and then remove items 1-10, it leaves items 11-20. Unfortunately, instead of laying these out appropriately, it renders them all on the left side of the page (ie, they all have left: 0px).

When I dig into the react-masonry-component code, diffDomChildren seems to work correctly and return proper dictionaries, except when elements are removed. When these elements are removed, diffDomChildren returns:

{
  appended: [],
  moved: [],
  new: [10 elements],
  old: [10 elements],
  prepended: [],
  removed: []
}

(I believe it should be returning 20 ‘old’ elements, with 10 ‘removed’.)

If I change:

        var oldChildren = this.domChildren.filter(function(element) {
            /*
             * take only elements attached to DOM
             * (aka the parent is the masonry container, not null)
             */
            return !!element.parentNode;
        });

to:

        var oldChildren = this.domChildren;

…then things work beautifully again. I’m confused why my change works, as it obviously seems to be intentionally written the way you’ve written it. When componentDidUpdate is called, it seems the DOM elements have already been removed from the DOM and had their parentNode null-ed.

I see this behavior with both React 15.1.0 and React 15.4.1 (along with react-masonry-component 4.4.0 and masonry-layout 4.1.1.)

[afram]

v5.0.1 released

[mikelambert]

I am running the following without any console errors:

• react-masonry-component 5.0.0
• react 15.4.1
• masonry-layout 4.1.1 (transitively)
• outlayer 2.1.0 (transitively)

Though I think we’ve figured out in https://github.com/eiriklv/react-masonry-component/issues/63 why there is no crash in my code…the fact that I don’t use transitions and both 5.0.0 crash bug repro cases do.

However (and this is troubling), if I roll back to 4.4.0, I am unable to reproduce my old broken behavior that motivated this change. 😦 Likewise, I am as-of-yet unable to generate a 4.4.0 webpackbin that demonstrations the problem.

I have to head to sleep now, but I will investigate more deeply tomorrow. Might be a webpack cache issue confusing me late-night, or maybe jumping back through my commit log will help me reproduce it and isolate what’s going on.

(And hopefully once we dig to the bottom of this, we can then also fix some of the tricky namings of these variables that confused me.)