Remove usage of getElementProp

[benelan]

Summary

Remove usage of the getElementProp util.

getElementProp is misleading from a naming and implementation perspective and needs to be revisited.

Current implementation

export function getElementProp(el: HTMLElement, prop: string, value: any): any {
  const closestWithProp = el.closest(`[${prop}]`);
  return closestWithProp ? closestWithProp.getAttribute(prop) : value;
}

1. getElementProp reads as a helper to get a prop, but it will actually get an attribute (string) OR whatever fallback value is provided.
2. The prop argument is used to build the selector for searching. This will only work for single-word props, e.g., will always fail for someName (prop), where the attribute is some-name.
3. Some usages of the fallback value argument have non-string types. This will lead to a mismatch or confusion on the expected value:

this.aBooleanProp = getElementProp(el, "a-boolean", false); // if a match is found it will return a string (getAttribute)

Proposal

Refactor getElementProp to:

export function getElementProp(el: HTMLElement, prop: string, value: T): T ;

1. convert the prop name to an attribute when building the selector
2. look at an element's property
3. update the type so that the fallback matches the expected return value

Introduce getElementAttr, which would be based on ☝

export function getElementAttr(el: HTMLElement, attr: string, value: string): string ;

1. use attr arg to build selector
2. look at an element's attribute
3. update the return type and fallback value type to be string (matching what getAttribute returns)

Related Issues:

• Changes to calcite-label's status property are not propagated to child calcite-inputs #3613
• [Input Message / Input] Remove usage of getElementProp to set status #3755

Which Component

• accordian-item
• combobox-item
• combobox-item-group
• dropdown-group
• dropdown-item
• inline-editable
• input
• input-message
• radio-group-item
• stepper-item
• tab-title

Other files that reference getElementProp:

• dom

[driskull]

Taking the first example (accordion-item)...

Instead of the accordion-item looking up at the parent to see what it's iconType, iconPosition or active state, those things should be set by the accordion. So it seems like logic needs to be moved to the parent.

So it seems in general, the logic just needs to move from the child to the parent component and the getElementProp shouldn't be necessary anymore.

The parent component will likely need to setup a mutation observer to do this as well as watchers for when it needs to modify the children.

[driskull]

@benelan @jcfranco how do we want to divide this up? What sprint?

[driskull]

This might be something for API consistency epic

[geospatialem]

Closing in favor of #6038.