Awesome! In the world of web components we like to return to the roots of what the browser has to offer. I think it's easy to forget about new browser features because you're waiting for cross-browser support. Like dis you know CSS :is() is very well supported across browsers now?
@@ElliottMarquez Exactly! I really like to take advantage of everything that the modern web supports today. I think a combination of ES Modules in the browser and Web Components can make for a powerful yet simple workflow without the use of a bundler. *Edit: And I have heard of :is(), it's great! I've used :where() a few times too, that one is great to hide some complex selectors for default Web Component styles that you want to make overridable by the component user :)
Working with MFE's and finding that sibling to sibling relationships can be needed - but being on different parts of the HTML page, means that they cannot all be under the same parent, and so the mediator pattern although agreeable, doesn't seem to fit that scenario. A good example is a shopping cart update (denoting number of items in basket) also existing in two very different places in the DOM. The only way I can see this working i then falling back to SPA style ... which I thought we were breaking away from. Would love any thoughts on this ....
I want to make three comments having been developing a relatively largish application single handedly since 2016 (initially with Polymer - now with Lit - no other frameworks involved). This is slowly replacing a large Microsoft Access application that I have been maintaining since 2009. Firstly - events only work when the elements are actually in the dom. In my application I actually page out (normally with the cache directive) all the large subtrees that are not active at the current time, and then further down the tree hierachy a second layer of subtrees. Nevertheless, although a database is the formal master datastore there is need for the cross tree updating of elements when they are paged out to avoid a re-read of the database when they are paged back in. In that case I developed a publish subscribe type model using callbacks, so that key data entities that have been updated in one subtree that can effect data for paged out subtrees elsewhere in the application. Secondly - although I use a lot of the mediator pattern - child to child communication can also take place by dispatching events and adding event listeners to document.body. In fact, I have developed a custom element that provides a subscribe service for such events, and that adds an event listener to document body and dispatches a local event upwards when when it receives the document.body event. This subscribe element is then a child of its parent who can then receive the event as though it was emitted locally. Thirdly - a design pattern I use a lot - mainly for dialog boxes that pop up to get information from the user, for sub sub elements which can be used all over the application, is to fire an event upwards with some data to a "dialog" element placed high in the hierarchy. It receives the info and remembers the sender. In fact it can often position itself close by the sender. Then when the information is gathered from the user it sends an event back to the element that dispatched it (by dispatching the event on the sender element), where it can be picked up via the @event declaration. Because this is a common pattern I developed a mixin to handle all the communication (I have a 'xxxx-request' and 'xxxx-reply' convention for the event names, with 'xxxx' being the value of a property I call eventBase that the mixin uses) Note I have a few mixins for common patterns, so for example I have a "page-manager" mixin that works in combination with a distributed routing module so that different urls (at different url hierarchy levels) control which page is switched in and out that I mention in the first comment above
Lots of really great info! Lots of agreement coming from me, I wish I had the time in the video to go deep into these topics! A cool pattern I've been toying around with was to communicate by passing around an instance to `new EventTarget()` now that it's supported in Safari 14. A bit more portable and private than document.body. problem is still getting a reference to it, but can be possible using a ReactiveController which Andrew will be covering in 2 videos from now
I would like to have a video explanation on the Lit lifecycle, because it's confusing where to put loading of remote data depending on changing of a certain property. Maybe someone can explain such a specialty.
interesting one! I might tackle that one soon! Though for now you might want to take a look at @lit-labs/task and give us feedback on our GitHub discussions and GitHub issues so you can shape how it looks coming out of Labs!
What if my web components will be used by another application. One component is a filter. Another component is a label that will need to refresh when the filter changed. But the container application doesn't know how these web components should communicate. I just import the lit project js to my other ui application, add a filter component and a label component. How will the label component know when the filter has changed?
I suppose that both components should be children ie. siblings of parent element. then you use events as described. What have confused me is how to add mediator role for the new parent in the new project? Can all mediator logic be writen in separate .js file and then 'imported' or something like that? rookie in this field here, don't judge me too hard if I missed the whole ball :)
Thanks Elliot - 💪🏽. Quick question, why did you use new Event('eventname') instead of new CustomEvent('eventname',{...detail}). Is there a reason for using the one you did?
Subscribe to never miss a video on Lit! → goo.gle/Lit
Thanks - the trombone example and code is brilliant !
Thanks! I had a lot of fun making it as well as the mini-synth!
A really cool set of videos. They are easy to grasp despite they touch deep fundamentals. Awesome.
Using events to communicate with parent and children elements is genius! Thanks for mentioning it, I forgot how useful that really could be.
Awesome! In the world of web components we like to return to the roots of what the browser has to offer. I think it's easy to forget about new browser features because you're waiting for cross-browser support.
Like dis you know CSS :is() is very well supported across browsers now?
@@ElliottMarquez Exactly! I really like to take advantage of everything that the modern web supports today. I think a combination of ES Modules in the browser and Web Components can make for a powerful yet simple workflow without the use of a bundler.
*Edit: And I have heard of :is(), it's great! I've used :where() a few times too, that one is great to hide some complex selectors for default Web Component styles that you want to make overridable by the component user :)
Man this is great, love Lit! Hope you guys keep on growing the channel with video's like these!
Thanks! Check in in a few weeks for the next Build It With Lit video!
I like the trombone demo, waiting for the state management
some things on state management are coming 👀
Working with MFE's and finding that sibling to sibling relationships can be needed - but being on different parts of the HTML page, means that they cannot all be under the same parent, and so the mediator pattern although agreeable, doesn't seem to fit that scenario. A good example is a shopping cart update (denoting number of items in basket) also existing in two very different places in the DOM. The only way I can see this working i then falling back to SPA style ... which I thought we were breaking away from.
Would love any thoughts on this ....
We're waiting the state manager full production grade implementation from Lit team video !!!! : )
We have some state manager videos in the pipeline!
I want to make three comments having been developing a relatively largish application single handedly since 2016 (initially with Polymer - now with Lit - no other frameworks involved). This is slowly replacing a large Microsoft Access application that I have been maintaining since 2009.
Firstly - events only work when the elements are actually in the dom. In my application I actually page out (normally with the cache directive) all the large subtrees that are not active at the current time, and then further down the tree hierachy a second layer of subtrees. Nevertheless, although a database is the formal master datastore there is need for the cross tree updating of elements when they are paged out to avoid a re-read of the database when they are paged back in. In that case I developed a publish subscribe type model using callbacks, so that key data entities that have been updated in one subtree that can effect data for paged out subtrees elsewhere in the application.
Secondly - although I use a lot of the mediator pattern - child to child communication can also take place by dispatching events and adding event listeners to document.body. In fact, I have developed a custom element that provides a subscribe service for such events, and that adds an event listener to document body and dispatches a local event upwards when when it receives the document.body event. This subscribe element is then a child of its parent who can then receive the event as though it was emitted locally.
Thirdly - a design pattern I use a lot - mainly for dialog boxes that pop up to get information from the user, for sub sub elements which can be used all over the application, is to fire an event upwards with some data to a "dialog" element placed high in the hierarchy. It receives the info and remembers the sender. In fact it can often position itself close by the sender. Then when the information is gathered from the user it sends an event back to the element that dispatched it (by dispatching the event on the sender element), where it can be picked up via the @event declaration. Because this is a common pattern I developed a mixin to handle all the communication (I have a 'xxxx-request' and 'xxxx-reply' convention for the event names, with 'xxxx' being the value of a property I call eventBase that the mixin uses)
Note I have a few mixins for common patterns, so for example I have a "page-manager" mixin that works in combination with a distributed routing module so that different urls (at different url hierarchy levels) control which page is switched in and out that I mention in the first comment above
Lots of really great info! Lots of agreement coming from me, I wish I had the time in the video to go deep into these topics!
A cool pattern I've been toying around with was to communicate by passing around an instance to `new EventTarget()` now that it's supported in Safari 14. A bit more portable and private than document.body. problem is still getting a reference to it, but can be possible using a ReactiveController which Andrew will be covering in 2 videos from now
I would like to have a video explanation on the Lit lifecycle, because it's confusing where to put loading of remote data depending on changing of a certain property.
Maybe someone can explain such a specialty.
interesting one! I might tackle that one soon! Though for now you might want to take a look at @lit-labs/task and give us feedback on our GitHub discussions and GitHub issues so you can shape how it looks coming out of Labs!
I am looking for routing and other stuffs which JavaScript framework already give. Also how it differs from qwik framework?
Looking dashing Elliott! Thanks for the vid😁
What if my web components will be used by another application. One component is a filter. Another component is a label that will need to refresh when the filter changed. But the container application doesn't know how these web components should communicate. I just import the lit project js to my other ui application, add a filter component and a label component. How will the label component know when the filter has changed?
I suppose that both components should be children ie. siblings of parent element. then you use events as described.
What have confused me is how to add mediator role for the new parent in the new project? Can all mediator logic be writen in separate .js file and then 'imported' or something like that?
rookie in this field here, don't judge me too hard if I missed the whole ball :)
what is that intro music?
Its COOOOLLLL....
Would it be possible to cover extending the Lit Component in your next video lessons? Thanks!
That is exactly what we're tackling in the next Lit U video!
Thanks Elliot - 💪🏽. Quick question, why did you use new Event('eventname') instead of new CustomEvent('eventname',{...detail}). Is there a reason for using the one you did?
Simply because I had no need for a detail!
Some people on our team also like extending Event for type safety rather than using CustomEvent
@@ElliottMarquez is there any benefit for extending Event?
@@christopherderrell8470 mostly type safety in TypeScript and adding methods to the class
@@ElliottMarquez Coolio. Thanks for answering
dude can any of these videos actually use meaningful examples... last time i used a trombone renderer was... never
well, for anything there is a first step, so...
but nevertheles, i find it very informational and creative. have a nice one! 👍