Remove duplicate handler for indicator

[rkulinski]

I have no idea why two different handlers should be applied for single action. The approach with two handlers was forcing to call stopPropagation which was causing this issue to occur
#5050

[changeset-bot]

🦋 Changeset detected

Latest commit: 7fc125e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
react-select	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 7fc125e:

Sandbox	Source
react-codesandboxer-example	Configuration

[Rall3n]

Removing the dedicated event handler for the DropdownIndicator component introduces breaking changes and also breaks interaction with the component when using the prop openMenuOnClick:

• setting openMenuOnClick={false} does not open the menu when clicking on the indicator
• additionally setting isSearchable={false} shows no indication of interaction with the component upon clicking the indicator (resembles an <select readonly /> element)

Even though both handlers do the same actions, they react in different ways to the interaction. One should not be removed on the basis that they both end in the same behavior. Instead, a way should be found to replace stopPropogation without changing current behaviour.

[rkulinski]

@Rall3n got it, I wasn't able to find any difference in how it was working, but I'm not that familiar with library code so I missed some edge case scenarios. I'll try to somehow get rid of stopPropagation, but I'm not sure if this will be easy.

[rkulinski]

@Rall3n I wasn't able to find any better and easier workaround for this with how components are structured. Some snapshots tests are failing and ofc branch name will have to be changed, but wanted to get a feedback on solution itself.

[rkulinski]

Closing in favor of #5089