Web Components stack includes efficient and well thought through templating solution with TEMPLATE and SLOT tags. While those have been widely adopted in web components world for multiple reasons, the shadow DOM behind of this tech prevents to use it in environments where UI styles managed separately and often driven by heavy legacy content: while styling in shadow DOM has own perks like css insulation, it does not work well with global css styling.
I would suggest to utilize the concept of slot in template in content management environments with classic css use. You could implement the convention by yourself with showing/hiding the slot with name
el.querySelector('slot[name="final"]').hidden = false;
To avoid the UI flickering , make sure the initial HTML includes the visibility state meant to be shown before JS is able to act:
<slot name="initial">Please wait while loading...</slot>
<slot name="final" hidden> initially is hidden, filled by JS and then shown </slot>
slot[hidden]{ display:none!important;}
Of course the page level javascript and HTML would limit only one slot name a time. Wrapping slots combinations into identifiable by JS container would help to handle multiple UI components with same kind of UI pattern(template). Like the avatar in the list and in profile UI.
The most convenient way to connect JS and HTML element is a custom element, i.e. Web Component with own tag. `this` in its methods would point to html element of own tag which would be triggered every time the tag appear in HTM, initially or dynamically later. In CMS it would prevent the messing with page, document, and script load handlers, a huge win for code maintenance when the code is spread across developers/teams and time.
Web Component does not dictate the use of ShadowDOM and allows to pick any way of template implementation. There are multiple "frameworks" with opinionated ways of templates handling. The HTML content meant to be handled by middle tier in classic CMS. Where the templates also play important role in content lifecycle. Adding another templating engine is not just increasing the complexity but also created the conflict between different approaches and handling the content variations like multi-lingual support or cohort targeting. Hence ability to reuse the CMS HTML capabilities along with template/slot concept would be most beneficial.
As CMS usually is not designed to serve the dynamic data, the fusion of externally served data and UI from CMS becomes a data plumbing task on UI tier. During this "data plumbing" process the UI should support multiple states including initial waiting, loading, error of multiple kind, and final with rendered data, perhaps with variations on data internals.
slotted-element comes handy for eliminating the coding for data plumbing in simplest cases and simplifying the programming otherwise.
Here this custom element is a sample for typical data plumbing to CMS driven HTML tasks.
- switch between slots to be shown. Hide all, display only one.
- clone slot content to be filled with data
- add customized slot. Could be more than once for list.
- data retrieval layer: url/method/headers/body, status, error handling, fetched data conversion.
- UI sub-elements access and manipulation convenience methods.
Whether you choose to use slotted-element, extend it, or decide to create own, keep in mind the list ^^.
Links:
