Skip to content

Support passing IDOMElementDescriptors as targets#1446

Merged
NullVoxPopuli merged 1 commit intoemberjs:masterfrom
bendemboski:dom-element-descriptors
Feb 12, 2024
Merged

Support passing IDOMElementDescriptors as targets#1446
NullVoxPopuli merged 1 commit intoemberjs:masterfrom
bendemboski:dom-element-descriptors

Conversation

@bendemboski
Copy link
Contributor

Implement support for RFC #726

#### Parameters

* `target` **([string][64] | [Element][65])** the element or selector to unfocus (optional, default `document.activeElement`)
* `target` **([string][64] | [Element][65] | IDOMElementDescriptor)** the element, selector, or descriptor to unfocus (optional, default `document.activeElement`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this may be nitpicky, but do we have a precedence for prefixing interfaces with I? I know there are eslint rules against against it in @typescript-eslint (as they don't really want to be associated with C# / Java / etc).

(otherwise, can we drop the I? <3 )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name is specified in the RFC and implemented in dom-element-descriptors (and now referenced in PRs in several other libraries), so I guess if you want this changed, that needs to be done via an amendment to the RFC?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, it's probably fine then. not worth the effort to change this if folks already agreed to use it

} else if (target instanceof Window) {
return target.document;
} else {
throw new Error('Must use an element or a selector string');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking, and maybe stylistic, but I really like using assert for type-narrowing and error-communication.

this bit of code would be:

assert('Must use an element, sel...', descriptorData)

return resolveDOMElement(descriptorData);
  • less nesting
  • less branching
  • we want an error anyway

return rootElement.querySelectorAll(target);
} else {
throw new Error('Must use a selector string');
let descriptorData = lookupDescriptorData(target);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so here, I suppose

.then(() => {
if (!target) {
throw new Error('Must pass an element or selector to `doubleClick`.');
throw new Error(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this error is used in a good number of places, I think it may be worth using a custom error class, so the message is predictably consistent - free from typos?

if (isDocument(element)) {
nodeType = 'Document';
} else {
// This is an error check for non-typescript callers passing in the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for adding a "why" comment.
not enough of these in OSS. <3

import { buildInstrumentedElement, insertElement } from '../../helpers/events';
import { isEdge } from '../../helpers/browser-detect';
import hasEmberVersion from '@ember/test-helpers/has-ember-version';
import { createDescriptor } from 'dom-element-descriptors';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this library seems useful! it's doing a lot of heavy lifting!

@NullVoxPopuli NullVoxPopuli merged commit e6a7205 into emberjs:master Feb 12, 2024
@NullVoxPopuli
Copy link
Collaborator

Released in 3.3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants