- From: Caridy Patiño <notifications@github.com>
- Date: Tue, 28 Feb 2023 20:37:03 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/986/1449327114@github.com>
From my recollection of the many discussions about Web Components with some google folks many years ago, there was one idea that hunted me for years, it was @domenic challenging the presumption that web components were meant to be used to encapsulate complex logic, specifically, multiple layers (logical layers - (e.g.: a gallery using a gallery item on its shadow, or a product set, containing a product price on its shadow). He kept saying, "don't do that", and of course, we didn't listen. It took us years, it took me years I should say, to realize what he was saying, and more important, to realize that this is the root of many problems for Salesforce ecosystem of Web Components. If you fall into that trap, then all the problems that you're describing will emerge immediately. My recommendation is: "Listen to @domenic", it is somehow counter intuitive because most of us are coming from different frameworks, and mostly trying to adapt to the WC model, so it is very tempting. Here are some of the rules that you can reasoning about: 1. build building blocks that encapsulates logic and UI elements that are "fully" customizable by using existing mechanisms (css properties, parts, slots, etc.). everything most be customizable from outside the shadow. 2. if a building block is using another building block on its shadow, it must do it as part of the default content of a well defined slot. <-- this is extremely important, otherwise you're going to violate 1. 3. only accept primitive values as properties and attributes. 4. don't be afraid of creating a big/large HTML with many composable building blocks to construct your experiences, you don't necessary need a shadow at that point, and you will have a single hump to style/customize any part of such large html fragment. I suspect that we, as a community, need to do a better job communicating and perhaps be more prescriptive, certainly implementers will not do it, but I see more and more developers falling for this trap, and at the end it is not helping the WC cause. Trying to supplement WC with new APIs to allow you to customize encapsulated components will never be good enough IMO, because the problem is the model you're aiming for, not necessary the WC API. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/986#issuecomment-1449327114 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/986/1449327114@github.com>
Received on Wednesday, 1 March 2023 04:37:16 UTC