5 ms·

It seems like you reinvented Edge Site Includes (https://en.m.wikipedia.org/wiki/Edge_Side_Includes https://en.m.wikipedia.org/wiki/Edge_Side_Includes).

lelanthran 3y ago
I like to think that I didn't reinvent it (just like react, et al didn't reinvent it), I only refined the concept into the simplest form that works :-) After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec. Look at the options for including HTML fragments in web pages: 1. Complex client-side react/vue/etc, 2. A server language , 3. A build-step including a non-spec bundler/packer, 4. A `<remote-fragment src="..." /> My point is that webcomponents make quite a lot of complicated things redundant for particular use-cases. As time goes on I see the fat front-end frameworks having more of their functionality being replaced with less complex (to use) custom elements. (Hence my experiments with value propagation using custom elements)
- nesarkvechnep 3y ago
  Refined the concept into the simplest form that works… as long as you have JavaScript enabled.
  - lelanthran 3y ago
    What's the alternative other than simply doing without this feature?
    - Quekid5 3y ago
      E.g. Apache's Server Side Includes[0] allows for  Tbf, you did specify 'server language' in a post further up the comment chain, but the the thing is that it doesn't have to be much more complicated that SSI -- assuming it's available for your deployment target, of course. (SSI obviously does not require JavaScript.) [0] https://httpd.apache.org/docs/current/howto/ssi.html https://httpd.apache.org/docs/current/howto/ssi.html
      - lelanthran 3y ago
        I've used those before, but I feel that having something that works within the spec, independent of any particular implementation's extensions is much more valuable for longevity. Sure, you can use $A if using $B server, or use $C when using $D language, or use $E when using $F framework, or use $G when using $H reverse-proxy, or use $I when using $J CDN, or use $K when using $L hosted cloud service ... Or you can just use what's in the specification which works on all of the above, but won't work on clients with Javascript disabled. It's a "choose your poison" scenario.
- mewpmewp2 3y ago
  Technically you could also just write a bit of JS within the HTML to do without needing any of the first 3. You could querySelectorAll and check the src attribute etc, then fetch the content put it in the innerHTML. <remote-fragment src="https://..." /> <script> document.querySelectorAll("remote-fragment").forEach(async (el) => { const src = el.getAttribute("src"); const result = await fetch(src).then((res) => res.text()); el.innerHTML = result; }); </script> Or if you want to react to any such component inserted at times down the line or src attribute changes, you could use MutationObserver.
  - lelanthran 3y ago
    That breaks on edge cases. For example it won't work recursively when a fetched fragment has fragments of its own. Or when the js snippet loads before some fragment element is loaded (say, from a DOM update). The nice thing about custom elements is that you get to treat them exactly like normal elements.
    - mewpmewp2 3y ago
      In this case you could use MutationObserver - although we are doing manually the logic web components provide, but my point is that you can do it also without using web components. My code doesn't include attribute changes, but this should be possible to also do with MutationObserver. <body> <script> const onRemoteFragmentMount = async (el) => { const src = el.getAttribute("src"); const result = await fetch(src).then((res) => res.text()); el.innerHTML = result; }; const callback = (mutationsList, observer) => { for (let mutation of mutationsList) { if (mutation.type === "childList") { mutation.addedNodes.forEach((node) => { if (node.tagName === "REMOTE-FRAGMENT") { onRemoteFragmentMount(node); } }); } } }; const observer = new MutationObserver(callback); const bodyElement = document.querySelector("body"); observer.observe(bodyElement, { childList: true, subtree: true, }); </script> <remote-fragment src="..." /> </body>
- dannye 3y ago
  why waste 28 minutes writing your own component? copy/paste takes 2 minutes https://dev.to/dannyengelman/load-file-web-component-add-external-content-to-the-dom-1nd https://dev.to/dannyengelman/load-file-web-component-add-ext...

lelanthran 3y ago

I like to think that I didn't reinvent it (just like react, et al didn't reinvent it), I only refined the concept into the simplest form that works :-) After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec. Look at the options for including HTML fragments in web pages: 1. Complex client-side react/vue/etc, 2. A server language , 3. A build-step including a non-spec bundler/packer, 4. A `<remote-fragment src="..." /> My point is that webcomponents make quite a lot of complicated things redundant for particular use-cases. As time goes on I see the fat front-end frameworks having more of their functionality being replaced with less complex (to use) custom elements. (Hence my experiments with value propagation using custom elements)

nesarkvechnep 3y ago
Refined the concept into the simplest form that works… as long as you have JavaScript enabled.
- lelanthran 3y ago
  What's the alternative other than simply doing without this feature?
  - Quekid5 3y ago
    E.g. Apache's Server Side Includes[0] allows for  Tbf, you did specify 'server language' in a post further up the comment chain, but the the thing is that it doesn't have to be much more complicated that SSI -- assuming it's available for your deployment target, of course. (SSI obviously does not require JavaScript.) [0] https://httpd.apache.org/docs/current/howto/ssi.html https://httpd.apache.org/docs/current/howto/ssi.html
    - lelanthran 3y ago
      I've used those before, but I feel that having something that works within the spec, independent of any particular implementation's extensions is much more valuable for longevity. Sure, you can use $A if using $B server, or use $C when using $D language, or use $E when using $F framework, or use $G when using $H reverse-proxy, or use $I when using $J CDN, or use $K when using $L hosted cloud service ... Or you can just use what's in the specification which works on all of the above, but won't work on clients with Javascript disabled. It's a "choose your poison" scenario.
mewpmewp2 3y ago
Technically you could also just write a bit of JS within the HTML to do without needing any of the first 3. You could querySelectorAll and check the src attribute etc, then fetch the content put it in the innerHTML. <remote-fragment src="https://..." /> <script> document.querySelectorAll("remote-fragment").forEach(async (el) => { const src = el.getAttribute("src"); const result = await fetch(src).then((res) => res.text()); el.innerHTML = result; }); </script> Or if you want to react to any such component inserted at times down the line or src attribute changes, you could use MutationObserver.
- lelanthran 3y ago
  That breaks on edge cases. For example it won't work recursively when a fetched fragment has fragments of its own. Or when the js snippet loads before some fragment element is loaded (say, from a DOM update). The nice thing about custom elements is that you get to treat them exactly like normal elements.
  - mewpmewp2 3y ago
    In this case you could use MutationObserver - although we are doing manually the logic web components provide, but my point is that you can do it also without using web components. My code doesn't include attribute changes, but this should be possible to also do with MutationObserver. <body> <script> const onRemoteFragmentMount = async (el) => { const src = el.getAttribute("src"); const result = await fetch(src).then((res) => res.text()); el.innerHTML = result; }; const callback = (mutationsList, observer) => { for (let mutation of mutationsList) { if (mutation.type === "childList") { mutation.addedNodes.forEach((node) => { if (node.tagName === "REMOTE-FRAGMENT") { onRemoteFragmentMount(node); } }); } } }; const observer = new MutationObserver(callback); const bodyElement = document.querySelector("body"); observer.observe(bodyElement, { childList: true, subtree: true, }); </script> <remote-fragment src="..." /> </body>
dannye 3y ago
why waste 28 minutes writing your own component? copy/paste takes 2 minutes https://dev.to/dannyengelman/load-file-web-component-add-external-content-to-the-dom-1nd https://dev.to/dannyengelman/load-file-web-component-add-ext...