feat(picker-column-option): add the new component #28591
Conversation
github-actions
bot
added
package: angular
thetaPC
requested review from
liamdebeasi,
averyjohnston and
sean-perkins
as code owners
|
Made a dev build: |
| @Prop() value?: any | null; | ||
|
|
||
| componentWillLoad() { | ||
| this.inheritedAttributes = inheritAriaAttributes(this.el); |
There was a problem hiding this comment.
As per the ticket, we should be taking advantage of Stencil's watch decorator for attributes: https://stenciljs.com/docs/reactive-data#watching-native-html-attributes
There was a problem hiding this comment.
To add to this, you will still need to get the initial state of the attribute you are trying to reflect. inheritAttributes would be the better utility for this here, since you only are reflecting the aria-label (where as inheritAriaAttributes will parse all aria attributes on the element node). I would assign this to a @State variable, so a mutation to this variable in the @Watch function will trigger a re-render to reflect the aria label to the inner button.
The desired behavior is if the developer changes the aria-label after the initial render of the component, that it will still update in the shadow dom template.
There was a problem hiding this comment.
Thank you both for the deeper explanations. I now have a better idea on how this stuff works.
| @State() ariaLabel?: string | null = null; | ||
|
|
||
| /** | ||
| * If `true`, the user cannot interact with the select option. |
There was a problem hiding this comment.
| * If `true`, the user cannot interact with the select option. | |
| * If `true`, the user cannot interact with the picker column option. |
| const { value, disabled, ariaLabel } = this; | ||
|
|
||
| return ( | ||
| <Host id={this.optionId} class={getIonMode(this)}> |
There was a problem hiding this comment.
This doesn't seem to be used anywhere. Can we remove it? (Or document why it's needed)
There was a problem hiding this comment.
I added them for future usage. I'll remove them since this is a stubbed version.
There was a problem hiding this comment.
If they are for future usage I'm fine keeping them, I was just hoping we could document why it was needed.
There was a problem hiding this comment.
I was thinking that:
idwould be necessary for children components that act like an option in order to submit the right valuegetIonMode()would be necessary for styling based on mode
But since I'm not 100% sure if my reasoning is correct and that it's currently not being used, then I removed it.
Issue number: internal
What is the current behavior?
Users have to pass the
optionskey in an object to generate the buttons withinpicker-column-internal.What is the new behavior?
ion-picker-column-optionThe new component will replace the need to pass
optionsas a key. Since the component is stubbed, it won't have functionality and styles. Those will be applied at a later time.Does this introduce a breaking change?
The changes are being pushed to a branch that targets a major.
Other information
N/A