Skip to content
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

[Input Message / Input] Remove usage of getElementProp to set status #3755

Closed
benelan opened this issue Dec 21, 2021 · 6 comments
Closed

[Input Message / Input] Remove usage of getElementProp to set status #3755

benelan opened this issue Dec 21, 2021 · 6 comments
Assignees
Labels
4 - verified Issues that have been released and confirmed resolved. refactor Issues tied to code that needs to be significantly reworked.

Comments

@benelan
Copy link
Member

benelan commented Dec 21, 2021

Description

calcite-input-message and calcite-input should not use getElementProp to set status.

Proposed Advantages

This is not a great pattern for inheriting properties - as of now it only detects and sets on load. Users should manage status on each component individually.

Relevant Info

The verbiage on calcite-label here: (https://github.com/Esri/calcite-components/tree/master/src/components/calcite-label#basic) should also be removed.

Which Component

calcite-input-message
calcite-input
calcite-label

cc @driskull

@benelan benelan added refactor Issues tied to code that needs to be significantly reworked. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Dec 21, 2021
@macandcheese
Copy link
Contributor

To clarify (I think), this property should be kept on calcite-input-message and calcite-input, but their use of getElementProp to get and set the prop from calcite-label should be stopped.

The verbiage on calcite-label here: (https://github.com/Esri/calcite-components/tree/master/src/components/calcite-label#basic) should also be removed.

@macandcheese macandcheese changed the title Input Message: remove status property [Input Message / Input] Remove usage of getElementProp to set status Dec 21, 2021
@benelan benelan added this to the Sprint 01/17 - 01/28 milestone Dec 30, 2021
@benelan benelan removed the needs triage Planning workflow - pending design/dev review. label Dec 30, 2021
@y0n4 y0n4 self-assigned this Jan 20, 2022
@y0n4
Copy link
Contributor

y0n4 commented Jan 20, 2022

Is it also recommended to remove the verbiage or change the code demo by adding additional status prop in the components for calcite-input and calcite-input-mesage?

@y0n4
Copy link
Contributor

y0n4 commented Jan 21, 2022

Does calcite-label still need the status property other then the purpose of having it propagate to calcite-input/calcite-input-message?

@driskull
Copy link
Member

No, we should deprecate it or remove it.

@y0n4 y0n4 added 1 - assigned Issues that are assigned to a sprint and a team member. 2 - in development Issues that are actively being worked on. 3 - installed Issues that have been merged to master branch and are ready for final confirmation. and removed 0 - new New issues that need assignment. 1 - assigned Issues that are assigned to a sprint and a team member. 2 - in development Issues that are actively being worked on. labels Jan 24, 2022
@github-actions github-actions bot assigned benelan and unassigned y0n4 Jan 27, 2022
@github-actions
Copy link
Contributor

Installed and assigned for verification.

@benelan
Copy link
Member Author

benelan commented Feb 7, 2022

verified on beta.76

@benelan benelan closed this as completed Feb 7, 2022
@benelan benelan added 4 - verified Issues that have been released and confirmed resolved. and removed 3 - installed Issues that have been merged to master branch and are ready for final confirmation. labels Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - verified Issues that have been released and confirmed resolved. refactor Issues tied to code that needs to be significantly reworked.
Projects
None yet
Development

No branches or pull requests

4 participants