|
|
|
|
|
|
by jimmont
1566 days ago
|
|
|
here are a few resources:
video survey with a lot of nuance, especially relative to React: https://youtu.be/9FB0GSOAESo?list=PLNM_ABHoF7B0qDu0GI09eCXim... https://developers.google.com/web/fundamentals/web-component... https://developer.mozilla.org/en-US/docs/Web/Web_Components https://lit.dev/docs/#next-steps
https://lit.dev/docs/composition/overview/
https://lit.dev/docs/components/overview/ generally I do this:
* make components that take responsibility for a bucket of concerns: like the app (track the app state--user, etc); then views (generic pages, more complex main-section things, etc); then more granular composable stuff like a highly specialized button (arbitrary example);
* communicate state changes up via events, for global or highly generalized coordination between anything just handle that on the window/self (setup/undo on the component lifecycle methods); send/intercept/capture these messages on the event.detail (use composition and bubbling);
* stick to first-principles: KISS, YAGNI; don't over-engineer your stuff, use encapsulation, if you don't need a shadowRoot it's not required, or use slotting..., use global styles where that's appropriate, use shadow encapsulation of styles where that's separately appropriate--keep those concerns separate and use common sense about appropriate separation of concerns;
* don't automate or use external libraries or anything fancy unless it has a clear self-apparent business case (for my work or the customer or the business); forget all the assumptions of the frontend community--it's mostly noise an example, it's very rough and I'm working through a starting point for myself:
https://github.com/sourdough/starter |
|
|