While it's really really awesome that React 16 now handles, if we want a really great story around noscript, I’d say automatically removing nested noscript-tags as per suggestion in Nested renders invalid HTML #6204 is key.The proposed solution to ignore the content of noscript-tags on the client is perfect (as long as we still keep the existing content in them).(If JS crashes before bucket has been set - Catch error and replace all relevant noscript-tags with divs and set their innerHTML with the innerHTML of the noscript-tag).Use dangerouslySetInnerHTML with the above.Instead of renderToStaticMarkup - Read existing textContent/innerHTML of the noscript-tag.Remove all nested noscript-tags in the resulting string (quite common for us since we also use noscript-fallbacks for lazy-loaded images).Render default component with renderToStaticMarkup (including using a couple of Providers to make Redux and react-router work).It could be as easy as but to make this work fully we have had to: Providing a noscript-fallback for conditional functionality that is determined on the client might be a bit niche but shouldn’t be that uncommon either. Often we still want to provide a default variant (in a noscript-tag) for people without JS, or as graceful degradation in cases where JS has crashed. We use this mainly for A/B-testing for cases where we want to determine the bucket on the client and render a component only after that. Var tgtTags = document.getElementsByTagName('noscript') Īlert("Num of noscript tags: " + tgtTags.length) Īlert("Num of noscript tags: " + tgtTags.I've been tracking this issue since #1252 and #6204 so I'll chime in with our current use-case and some thoughts (long post but some background is necessary I think). Window.addEventListener('load', onDocLoaded, false) (1) to fire on a button press, so you can see the effect in the DOM viewer of your browser's JS tools. Metadata content, flow content, phrasing content.
Dunno, probably mostly irrelevant here anyway. The
0 kommentar(er)
