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

Remove any logic where disabled affects state across components #7547

Open
1 of 8 tasks
Elijbet opened this issue Aug 17, 2023 · 1 comment
Open
1 of 8 tasks

Remove any logic where disabled affects state across components #7547

Elijbet opened this issue Aug 17, 2023 · 1 comment
Assignees
Labels
1 - assigned Issues that are assigned to a sprint and a team member. breaking change Issues and pull requests with code changes that are not backwards compatible. estimate - 2 Small fix or update, may require updates to tests. p - low Issue is non core or affecting less that 10% of people using the library refactor Issues tied to code that needs to be significantly reworked.

Comments

@Elijbet
Copy link
Contributor

Elijbet commented Aug 17, 2023

Description

Remove any logic where disabled affects state such as open across all relevant components.

Several components set the open prop to false in the open watcher in a similar fashion:

@Watch("open")
  openHandler(): void {
    // emit events

    if (this.disabled) {
      this.open = false;
      return;
    }

    // do something
  }

Proposed Advantages

It’s a good practice to separate concerns and maintain clear distinctions between different states and behaviors across components.

Which Component

  • combobox (open)
  • dropdown (open)
  • inline-editable (open)
  • input-date-picker (open)
  • input-time-picker (open)
  • split-button (active – internal prop)

Relevant Info

No response

Calcite package

  • @esri/calcite-components
  • @esri/calcite-components-react
@Elijbet Elijbet 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 Aug 17, 2023
@Elijbet Elijbet self-assigned this Aug 17, 2023
@Elijbet Elijbet added the estimate - 1 Very small fix or change (potentially a single line), doesn't require updates to tests. label Aug 17, 2023
@geospatialem geospatialem added spike Issues that cannot be estimated well enough until the team has done further research p - low Issue is non core or affecting less that 10% of people using the library labels May 28, 2024
@geospatialem geospatialem added 1 - assigned Issues that are assigned to a sprint and a team member. and removed 0 - new New issues that need assignment. labels May 28, 2024
@geospatialem
Copy link
Member

Spike in June to consider for the upcoming breaking change release and determine next steps if a breaking change is needed.

@geospatialem geospatialem removed the needs triage Planning workflow - pending design/dev review. label May 28, 2024
@jcfranco jcfranco added the breaking change Issues and pull requests with code changes that are not backwards compatible. label May 28, 2024
@geospatialem geospatialem removed the spike Issues that cannot be estimated well enough until the team has done further research label Aug 12, 2024
@geospatialem geospatialem added estimate - 2 Small fix or update, may require updates to tests. and removed estimate - 1 Very small fix or change (potentially a single line), doesn't require updates to tests. labels Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - assigned Issues that are assigned to a sprint and a team member. breaking change Issues and pull requests with code changes that are not backwards compatible. estimate - 2 Small fix or update, may require updates to tests. p - low Issue is non core or affecting less that 10% of people using the library refactor Issues tied to code that needs to be significantly reworked.
Projects
None yet
Development

No branches or pull requests

3 participants