render(ripple) called for custom component on Chrome but not IE 11

[whittala]

I had a custom component accountsFilter defined in file accounts-filter.js with a css file accounts-filter.css. I added the tag with passing the data using once:

o('accounts-filter', { filterAccounts: data , accountGroups: accountGroups , changeFilters: changeFilters , dispatcher: dispatcher , selected: undefined , focused: isActive , open: isActive }) .attr('css', 'accounts-filter.css') .on('change.accounts', changeAccounts)

On chrome the render(ripple) method calls the custom component function:

export default function accountsFilter(state) { var o = once(this)

However on IE11 the render(ripple) function doesn't call this method.

We added a change to force ripple to draw it on IE11:

o('accounts-filter', { filterAccounts: data , accountGroups: accountGroups , changeFilters: changeFilters , dispatcher: dispatcher , selected: undefined , focused: isActive , open: isActive }) .attr('css', 'accounts-filter.css') .on('change.accounts', changeAccounts) .each(ripple.draw)

but don't really understand why the render(ripple) method was not called.

[pemrouz]

Ok, I think I know what this is finally. Skip to end for TL;DR, some background for understanding:

• In general, manually invoking .draw shouldn't ever be necessary, since once will automatically invoke the draw function on a node, if any. This will redraw that node, which in our unidirectional architecture, will also recursively redraw all it's children too. However, this has been the case for a while, so I don't think that is the problem here.
• Looking at your snippet, I then thought it was because you are creating/updating the accounts-filter node, for which a draw is attempted, but that draw is halted by the needs rendering middleware module (rendering is blocked on missing dependencies to prevent FOUC). That bails the draw because the component has a required CSS stylesheet (accounts-filter.css) which you add afterwards. With the assumption that you were on a version before this commit, the .attr('css', 'accounts-filter.css') then triggered a redraw in Chrome, but not IE11. However, that is not correct: Although the needs module blocks draws on missing deps, it also cleverly kicks off a new draw if it adds any missing deps. Btw - this also means you can get rid of the line .attr('css', 'accounts-filter.css').
• Browsers that support Web Components will invoke certain callbacks for a Custom Element. The key one is attachedCallback, which is invoked when the element is first added to the page. In Ripple, all the attachedCallback's are pointed to the generic ripple.draw, which then determines which function to use from the registry based on the tag name being drawn (essentially ripple.resources[el.tagName].body). This is what allows for dynamically changing a component's implementation and simple hot loading, whereas with vanilla Web Components, Polymer, etc once you register a component definition, it's permanently fixed. For browsers that don't support Custom Elements, we use MutationObservers to invoke ripple.draw on elements that are newly added to the page. This observer is exposed on document.body.muto in case users want to disable it. I believe this may be disabled in your project and hence why newly added elements are not being drawn. See here for a reproducible example.

As a result, I think this area can be slightly improved: By just setting Element.prototype.draw = ripple.draw, once will correctly draw existing and newly added elements. This means we can drop the MutationObserver polyfills for IE11/FF, and it will also work exactly the same for the likes of IE9 - without all the extra .each(ripple.draw) :tada:..

[pemrouz]

New release published, with explanation here (note you may want to "watch" this repo to receive future digests by email). I've also added IE9 to list of browsers to run on the CI so we'll know for future releases if we break anything in older browsers. Let me know if this helps..