[Dropdown]: unable conditionally render a dropdown on button click

[svlesiv]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

To avoid loading dropdown content, we used an external trigger button that renders the dropdown only on a button click. It worked in v2.6.0, but starting from v2.7.0, it seems that clicking the external trigger button is treated as a click outside, causing the modal to close immediately.

Expected Behavior

The dropdown component would be displayed when clicking on a button (outside the dropdown) that changes the state of a variable to render the dropdown.

Reproduction Sample

https://codepen.io/svlesiv/pen/vEBxJgZ

Reproduction Steps

1. Go to https://codepen.io/svlesiv/pen/vEBxJgZ codepen.
2. Click on the External Trigger button.
3. The dropdown will not be displayed for v2.7.0 - v2.13.2.

Reproduction Version

2.13.2

Relevant Info

No response

Regression?

2.6.0

Priority impact

impact - p1 - need for current milestone

Impact

Rendering a table with many dropdowns would again decrease the performance that was improved by https://github.com/ArcGIS/sitescan-manager/pull/7069 PR.

Calcite package

• @esri/calcite-components
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/calcite-ui-icons
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Site Scan

[geospatialem]

Calcite has now aligned the dropdown component to only support opening via the "trigger" slot. Adding the docs label to add context to the required "trigger" slot for users.

@svlesiv Could the use case support triggering the component through the "trigger" slot?

[svlesiv]

Unfortunately, we cannot use trigger slot for our use case.
Closing this issue because we found a workaround for it.

[gpbmike]

Thanks for your help @geospatialem. Adding more context to the use case Svitlana is referring to.

We found that when rendering many dropdowns at once, there is a significant performance hit. By deferring dropdown rendering by triggering with an external (to the dropdown) button, we can mitigate the performance drop.

The trigger slot does not work for us as that requires rendering the dropdown. We must rely on the "open" property. However, the above comment about "only support opening via the "trigger" slot" would imply that the "open" property should be read-only and should not open the dropdown. Is that a bug?

The workaround Svitlana referred to is to stop the click event from propagating and being caught by the newly rendered and opened (via "open" property) dropdown.

[geospatialem]

The trigger slot does not work for us as that requires rendering the dropdown. We must rely on the "open" property. However, the above comment about "only support opening via the "trigger" slot" would imply that the "open" property should be read-only and should not open the dropdown. Is that a bug?

@gpbmike This is not a bug, while it may have worked previously the intent of the dropdown component is to leverage the "trigger" slot to display its contents. We will re-open the above to add more context to the component's intent and use for folks.

[COV-GIS]

I would like some clarification. I'm also dynamically rendering dropdowns with custom components and using open programmatically with a hidden trigger to a void the focus error. I just want to make sure open won't be made read only. I'm developing a couple components now with plans on using this pattern more in the future and don't want to have it break. Thanks.

[geospatialem]

The above needs additional refinement before milestone-ing, some context for follow-up with @DitwanP and @jcfranco:

The original repro case doesn't seem to work for v3.0, is this a bug with the open prop that needs to be resolved?