Integrate with client side rendering frameworks like react

[chirag04]

First off thank you for this amazing polyfill!

I tried to integrate this with our react app and noticed something strange. We render the noscript tag with img correctly on the sider side first. Loading attribute polyfill kicks in on the client and appropriately sets up everything(rendering placeholder, setting up observers etc). It is after this react will client-side render the app which will render the noscript tag again. As a result, we end up losing all the setup this polyfill did.

any idea how we can integrate this with react?

[mfranzke]

That‘s a great comment, thank you for pointing that out, @chirag04

I could mainly think about four ways to handle this:


Inserting different HTML code on upfollowing frontend rendering

This would both loose the effect of the polyfill itself in non-supporting browsers, and probably be a little hard to implement and differentiate.

Provide an API for reinitializing the polyfill functionality

By providing a method that you could deliver a DOM object to for executing the polyfilling functionality again, everybody would be totally flexible to do this in their way & style and their context. Still this might be a little difficult for one or the other to implement in their context.

Automatically identifying any changes to the DOM

By introducing a MutationObserver we would be most flexible to identify changed / new or readded loading-items wrapped on those noscript tags and that for we would be able to reinitialize our functionality directly out of the plugin.

Develop a ReactJS, Angular, vue.js etc. component

The main downside on this is the effort, responsibility to both identify and contribute to all of those frameworks (would need community support) and keeping stuff maintained.

I’m open minded and would like your feedback on this. I tend to identify the third option as the most universal and probably even also easiest to implement.

[chirag04]

those are great ideas! my 2 cents on those:

Inserting different HTML code on upfollowing frontend rendering

I feel like this will get tricky with client-side rendering at runtime adding/removing images.

Provide an API for reinitializing the polyfill functionality
Develop a ReactJS, Angular, vue.js etc. component

If we expose(export) the polyfill functionality then the community can trivially build higher-order components on top of it. It will be some maintenance but I feel the community should help with that a lot. I have confidence that this library will become mainstream very soon.

Automatically identifying any changes to the DOM

This def is the most universal optional of all. My slight hesitation is that now DOM mutations to these noscript tags can/will happen from two different places(react and mutation observer). Will there be any race condition or unintended side-effects because of that?

[danielbachhuber]

I've run into a similar issue. Our infinite scroll implementation adds more <noscript> images to the page, but this polyfill doesn't process them.

One (really bad) workaround is to call:

window.document.dispatchEvent(new Event("DOMContentLoaded", {
  bubbles: true,
  cancelable: true
}));

It would be nice if the polyfill exposed a function I could call, or listened for a custom event on the document that I could trigger. In fact, listening for a custom event seems like the most lightweight, easy to maintain approach.

[rfgamaral]

I believe I've also run into this issue on my AngularJS (yes, I know) app. If I understood the problem correctly is that this polyfill will run before the client-side framework had a chance to render the components, correct?

I'm confused by this comment @mfranzke. All of those solutions are proposals, correct? I mean, none of that is possible to do with the current polyfill version, correct?

With that in mind, I see a quick and dirty solution posted by @danielbachhuber above. Do you recommend that @mfranzke or do you have a recommendation for a different approach to work around this problem until a proper solution is implemented?

[eugef]

I have an issue with rendering <noscript> tag with React on client-side. Apparently it is not possible anymore. facebook/react#13537 facebook/react#11423

Would be great if this polyfill would allow to wrap <img> tag in any other tag.

[mfranzke]

I believe I've also run into this issue on my AngularJS (yes, I know) app. If I understood the problem correctly is that this polyfill will run before the client-side framework had a chance to render the components, correct?

I'm confused by this comment @mfranzke. All of those solutions are proposals, correct? I mean, none of that is possible to do with the current polyfill version, correct?

With that in mind, I see a quick and dirty solution posted by @danielbachhuber above. Do you recommend that @mfranzke or do you have a recommendation for a different approach to work around this problem until a proper solution is implemented?

You're right, all of those are still proposals and a final solutions hasn't been integrated and distributed so far. @danielbachhuber sounds like a good solution for now.

[mfranzke]

I have an issue with rendering <noscript> tag with React on client-side. Apparently it is not possible anymore. facebook/react#13537 facebook/react#11423

Would be great if this polyfill would allow to wrap <img> tag in any other tag.

What do you think about a method being exposed by the polyfill that you could send some DOM to and get the expected (transformed or not transformed based on the browsers capabilities) resulting HTML back in return? Using another tag than noscript wouldn't prevent the browser from loading the image source in the first place.

[eugef]

@mfranzke I would prefer that my application doesn't use polyfill directly.
Ideal scenario is when app is not aware if polyfill exists on the page or not.

If other tag is not an option, maybe polyfill can rely on data-src attribute instead of src?

[mfranzke]

@eugef, thanks for your feedback - that makes perfectly sense. The polyfill could‘t rely on a non-standard attribute as there‘s no graceful degradation for that way of implementation.

[mfranzke]

@chirag04, @danielbachhuber, @rfgamaral - sadly it took me a while to provide a solution. Do you have the chance to review my implementation provided with #96 ?

[rfgamaral]

@mfranzke I no longer work at the company/product where I was having this issue so I can't be of any further help here.

[mfranzke]

@rfgamaral, okay, but still thanks a lot for participating in this earlier.