`l` is not a function (reported from

Describe the bug

Sentry Issue: CAMUNDA-MODELER-8P0

TypeError: l is not a function
  at apply (./src/shared/ui/overlay/OverlayDropdown.js:62:10)
...
(11 additional frame(s) were not displayed)

We don’t pass onClose in start instance:

         <OverlayDropdown
           title="Start current diagram"
           className={ classNames(css.StartInstanceTool, { 'btn--active': this.state.activeButton }) }
           items={ this.START_ACTIONS }
           buttonRef={ this.anchorRef }
           overlayState={ this.state.activeButton }
         >

Steps to reproduce

https://user-images.githubusercontent.com/28307541/177513557-743d7490-ff06-4ee9-8ed6-f4822aea87c7.mov

1. Open start instance
2. Click the button again

Expected behavior

No error

Environment

• OS: [e.g. MacOS 10.2, Windows 10]
• Camunda Modeler Version: [e.g. 2.0.0]
• Execution Platform: [e.g. Camunda Platform, Camunda Cloud]
• Installed plug-ins: […]

Additional context

No response

[Skaiir]

@nikku @barmac For visibility

[Skaiir]

Following some investigations, I’ll leave this in the state that it following RCA.

---

What happens

1. We make use of a component called OverlayDropdown in different places in the application

2. OverlayDropdown holds multiple different responsibilities

• It’s a visual component to display groupings (ref1, ref2)
• It handles the logic for displaying or not of the overlay based on either
  • A shouldOpen state variable as is the case with CreateNewAction to force it open externally
  • Internal state management, which involves multiple different functions
  • Internal messaging to external state management, using the onClose hook, which then is used to close the component externally.

1. StartInstanceTool is using both OverlayDropdown, as well as StartInstanceConfigOverlay for the second step. It attaches that second overlay into the button that OverlayDropdown provides to position itself.

2. The overlay displaying state management logic ends up shared between StartInstanceTool and OverlayDropdown, leading to hard to predict behavior.

---

The main issues

• State is handled all over the place, it should be central.
• We are breaking hierarchy by trying to add a second overlay to OverlayDropdown, which makes the code hard to read and hard to predict.
• There are too many different ways of using OverlayDropdown, which again contributes to issues in readability and predictability.

---

Proposal

Right now, the only fix I could provide would be to make the OverlayDropdown a little more fault tolerant. But IMO the problem lies in how the whole component works, not our implementation of it. My fix would remove the exception, but actually this exception isn’t visible to the user in the first place, so it would be a monkey-patch only to make the debugger less red.

In my view, this section is simply in need of a refactor.

What I would do, is separate out the toggling buttons and state management logic from the visual logic OverlayDropdown provides. We could then actually compose more complex overlay and handle state management in one place safely.

This could be a good topic for a spring cleaning or slack time.