-
Notifications
You must be signed in to change notification settings - Fork 54
Clarify when details should go on events vs targets #585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
0985dde
9337eb6
1193cfa
4c962eb
209d533
0d037b5
0c3916f
726b82f
c3ab2f1
3459c82
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1615,7 +1615,7 @@ Unlike dictionaries, interfaces: | |
(i.e., one can check if it is an `instanceof` a particular class on the global scope), | ||
|
||
Defining an interface also exposes it on the global scope, allowing for the specification of static methods. | ||
For example, the `canParse()` static method of the URL interface. | ||
For example, the `canParse()` static method of the URL interface. | ||
|
||
```JS | ||
if (URL.canParse(someURL)) { | ||
|
@@ -2554,12 +2554,30 @@ as it implies that it's possible to dispatch an event asynchronously. | |
All events are dispatched synchronously. | ||
What is more often implied by "asynchronous event" is to defer firing an event. | ||
|
||
<h3 id="state-and-subclassing">Use plain {{Event}}s for state</h3> | ||
<h3 id="state-and-subclassing">Put state on {{Event/target}} objects rather than {{Event}}s</h3> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The previous heading seemed… incomplete. |
||
|
||
Where possible, use a plain {{Event}} with a specified `type`, | ||
and capture any state information in the {{Event/target}} object. | ||
Where possible, capture any state information in the {{Event/target}} object, | ||
and use events with a specified `type` to signal updates to that state. | ||
|
||
It's usually not necessary to create new subclasses of {{Event}}. | ||
<div class="note"> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this need to be a note? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did it to separate the rule from the explanation of the rule, since the explanation is non-normative. But this spec doesn't have such a strict divide between normative and non-normative. But I don't mind either way, happy to go with whatever you think. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure if I understand this paragraph... Or if it's completely accurate. There are a few events that are fired asynchronously, e.g. |
||
This means the {{Event/target}} object can used to determine the current state, | ||
jakearchibald marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
without waiting for the next \'change\' event. | ||
|
||
This is particularly useful if there's a final state, | ||
where there will be no further \'change\' events. | ||
</div> | ||
|
||
It's usually not necessary to create new subclasses of {{Event}}, | ||
but they can be used to provide information relating to how the state change occurred. | ||
|
||
<div class="example"> | ||
Properties on {{HTMLInputElement}}, | ||
such as {{HTMLInputElement/value}}, | ||
provide the state of the input. | ||
Properties on {{InputEvent}}, | ||
such as {{InputEvent/inputType}}, | ||
describe the nature of an update to the state. | ||
</div> | ||
|
||
<h3 id="events-vs-observers">Use Events and Observers appropriately</h3> | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated change, but it's something many editors do automatically. I can remove it, but I imagine others will run into the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are not the only one. We should maybe lint for trailing whitespace.