العودة   منتديات عميد التعريب > >

الملاحظات

English News & Topics مواضيع و أخبار عالمية متفرقة باللغة الإنجليزية Various international topics and news in English



إضافة رد
 
أدوات الموضوع انواع عرض الموضوع

قديم 2019-11-08, 12:32 AM   رقم المشاركة :1
معلومات العضو
عميد
`composed: true` considered harmful?
إحصائية العضو





معدل تقييم المستوى: 9
fbi is on a distinguished road
المنتدى : English News & Topics
Icon (42) `composed: true` considered harmful?


[LEFT]
Disclaimer: it was brought to my attention that in my desire to strike a very click-bait-like pose in reference to a wide field of "considered harmful" articles, that it might too directly call to mind a seminal post in this regard that takes a clear stance in opposition to its subject. While it is absolutely my goal to trick you onto this page with such a title, I won't pretend to have THE definitive stance on almost any subject, let alone on one as rich and varied as event handling. I do hope to strike up a good dialog if you'll join me in one, and find that a shared foundation of knowledge is the best place to get started on one. So, let's begin!

Photo by Toa Heftiba on Unsplash First of all, what even is composed: true, and when might you use it?

Event.composed outlines whether a DOM event will cross between the shadow DOM in which the event is dispatched into the light DOM in which the element that the shadow root is attached to exists. As you'll find in the MDN article on the subject, "all UA-dispatched UI events are composed" by default, but when you work with manually dispatched events you have the opportunity to set the value for this property as you see fit. So the "what" of composed: true at its simplest is "a way to manage the encapsulation of your event transmission", and the "when" is namely "while working with shadow DOM", a practice that is not exclusive to but has become somewhat synonymous to working with web components; shadow DOM, custom elements, ES6 modules, and the element. Next, we'll review some important concepts before we try to come to a decision about composed: true:

At that point, we'll all be specialists and we can get into some practices and patterns with DOM events that might be useful in your applications. I'll share some ideas that I've had or used, and I hope you'll do the same in the comments below. Ready to go?

Native DOM Events

Native HTML elements communicate up the DOM tree using DOM events. You might be used to seeing this with elements like which publish events like change and input or with the element, where it's common to rely on the click event that it publishes. It might not be immediately clear you are relying on these things, but when applying onclick (native) or onChange (virtual DOM) properties, it is these DOM events on which you are relying under the hood. Knowing that these events are dispatch along the DOM tree, we can choose locations (either explicit or general) at which to listen for them via the addEventListener(type, listener[, options/useCapture]) method that is present on any HTMLElement based DOM node.

These events have two phases; the "capture" phase and the "bubble" phase. During the capture phase, the event travels from the top of the DOM down towards the dispatching element and can be listened for on each of the elements that it passes through in this phase by setting the third argument of addEventListener() to true, or by explicitly including capture: true in an options object passed as the third argument. For example the steps of the "capture" phase of a click event on the in the following DOM structure:


Click me!
Would be as follows:

Then, being a click event, bubbles: true is set by default, so the event would enter the "bubble" phase and travel back up the DOM passing through the above DOM in the following order:

At any point in either phase that you are listening for this event, you will have access to the preventDefault(), stopPropagation(), and stopImmediatePropagation() methods that give you powerful control over the events that travel across your application. preventDefault() can most clearly be felt when listening to a click event on an <a href="..."> tag. In this context, it will prevent the anchor link from being activated and prevent the page from navigating. In a way, this is the event asking for permission to do an action, and we'll look at this more closely in conjunction with manually dispatched events. stopPropagation() prevents the event in question from continuing along the DOM tree and triggering subsequent listeners along that path, a sort of escape valve for the event when certain parameters are met. This can be taken one step further via stopImmediatePropagation() which also prevents the event from completing the current step of the phase it is in. This means that no later bound listeners on that same DOM element for the event in question will be called. Returning to the element in the example above, when a click event is dispatched, you could imagine the following completely trivial listeners:


const body = document.querySelector('body'); const header = document.querySelector('header'); const button = document.querySelector('button'); // You can hear the `click` event during the "capture" phase on the `` element. body.addEventListener('click', () => { console.log('heard on `body` during "capture"'); }, true); // You cannot hear the `click` event during the "bubble" phase on the `` element. body.addEventListener('click', () => { console.log('not heard `body` during "bubble"'); }); // You can hear the `click` event during the "bubble" phase on the `` element. header.addEventListener('click', (e) => { console.log('heard on `header` via listener 1 during "bubble"'); e.stopPropagation(); }); // You can hear the `click` event during the "bubble" phase on the `` element. header.addEventListener('click', (e) => { console.log('heard on `header` via listener 2 during "bubble"'); e.stopImmediatePropagation(); }); // You cannot hear to the `click` event during the "bubble" phase on the `` // element being it is bound later than the previous listener and its use of the // `stopImmediatePropagation()` method. header.addEventListener('click', (e) => { console.log('not heard on `header` via listener 3 during "bubble"'); }); // You can hear the `click` event during the "capture" phase on the `` element. button.addEventListener('click', () => { coonsole.log('heard on `button` during "capture"'); }, true); button.click(); // heard on `body` during "capture" // heard on `button` during "capture" // heard on `header` via listener 1 during "bubble" // heard on `header` via listener 2 during "bubble"
The majority of values for bubbles, cancelable (needed to empower preventDefault()), and composed are the same across native DOM events, and in many of those cases the value of composed is true, so it's possible that the browser is already refuting the idea that it could "harmful". However, when working with native DOM events the values for these three properties are also not configurable. To access the power, and responsibility, that comes with being able to do so, you'll need to enter the world of manually dispatched events.

dispatchEvent()

So far we've mainly talked about the click event as automatically dispatched by the browser. There is, of course, a whole family of UA-dispatched UI events that can be addressed in the same manner (e.g. animationend/copy/keydown/mouseover/paste/touch, etc.). However, the real fun starts when you take that power into your own hands and start dispatching events on your own creation. For this, the browser supplies us with the dispatchEvent() method that hangs off of anything extended from EventTarget, which includes all of the HTMLElement based collection of DOM elements. For this to do its magic we need to supply it an event to dispatch. We're given a number of events classes to create our new event from (e.g. new Event(), new MouseEvent(), new InputEvent(), etc.), but event just new Event(typeArg[, initDict]) gives us very a wide range of possibilities.

Now, we're ready to dispatch an event.


el.dispatchEvent(new Event('test-event'));
Event dispatched!

The event has a type of test-event, so a listener set directly on the dispatching element will be able to hear it:


el.addEventListener('test-event', (e) => console.log(e.type)); // test-event
You can also listen for this event during the "capture" phase:


const body = document.querySelector('body'); body.addEventListener('test-event', (e) => console.log(e.type), true); // test-event
But, you won't be hearing it in the "bubble" phase:


const body = document.querySelector('body'); body.addEventListener('test-event', (e) => console.log(e.type)); // ... ... Bueller?
This is because by default a new Event() (as well as all derivative event constructors) have bubbles, cancelable, and composed set to false by default. This is where the optional initDict argument of our event constructor comes into play. When you want to customize the values of these, you'll create your event like so:


const event = new Event('test-event', { bubbles: true, cancelable: true, composed: true, };
Or however best supports (or least harms?


fbi غير متواجد حالياً   رد مع اقتباس
إضافة رد

مواقع النشر (المفضلة)

الكلمات الدلالية (Tags)
=, `composed, considered, dom, element, event, events, harmful, phase, true`

أدوات الموضوع
انواع عرض الموضوع

تعليمات المشاركة
لا تستطيع إضافة مواضيع جديدة
لا تستطيع الرد على المواضيع
لا تستطيع إرفاق ملفات
لا تستطيع تعديل مشاركاتك

BB code is متاحة
كود [IMG] متاحة
كود HTML معطلة



الساعة الآن 06:56 PM


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
منتديات عميد التعريب 2010 - 2019