Re: [WICG/webcomponents] Lazy Custom Element Definitions (#782)

Here's a scenario from a real-world, well-known site that is heavily invested in Web Components, where the architecture could really benefit from some sort of lazy loading platform feature as is being discussed here...

Let's say you are building a feeds experience. Each feed is customized to a specific user. The feeds themselves are an infinite scrolling list of cards. Each card is a Web Component. The experiences that these card components afford are highly diverse and there are hundreds of different cards with the number growing all the time. There is a central engineering team that creates the shell and many of the cards, but a large portion of them are created by other engineering teams and partners, which have a business case for plugging into the overall feeds experience.

When any given user visits the site, the frontend queries a service to find the specific set of content for that user at that point in time. This content can contain any combination of the hundreds of cards available from the library, but the specific combination cannot be determined ahead of time, as it is based on preferences, current events, time of day, external advertising services, etc. As the user scrolls, additional data is loaded which the client then dynamically renders. At any point of in time, the core engineering team or partners may launch new card experiences and the backend services may begin sending back data for cards that did not exist at the time that the original server request was made by the client.

I won't get into the details of how this is/should be handled today with the current standards, but it's very non-trivial and less than ideal. However, it seems that one way the existing system could be simplified and improved is if the frontend could simply detect an HTML element that showed up which was undefined. It could then send a request to the server to get the batch of definitions (all unknowns seen within a current tick). Please note that upfront defining all lazily-loadable element names is not feasible in this context. Again, there are hundreds of experiences, which could amount to thousands of elements, and those can change while the user is interacting with the site at any point in time.

The use cases are even more interesting though. As the client may not want to simply load any element it doesn't have a definition for. Certain elements it may want to delay load until certain things happen. A typical example is the settings UI for the feeds experience. Most of the time that a customer visits the site, they don't mess with their settings. So, it's wasteful to load it. Instead, you want to load that set of components when some app-specific heuristics determine that the user is about to interact with the settings. Similar rules may also be applied to various cards within the library, which have more or less complex interactions. For example, a quiz/survey card may not want to load all its behavior unless a user signals that they are about to engage with the quiz/survey. A card that contains a casual game may not want to load until the user signals they want to play. The rules for what to load and when are application and experience-specific and are constantly being changed based on analysis of RUM data. In fact, these rules themselves may be user-specific.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/782#issuecomment-1540759211
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/782/1540759211@github.com>