unsuitable for current large-scale projects

[Waterkyuu]

Proposal: Support uncontrolled APIs for overlay components

Many overlay components in gluestack-ui, including AlertDialog, Modal, Drawer, Menu, and Popover, currently require consumers to manage their open state externally.

In larger applications, this leads to a significant amount of repetitive state-management code:

const [isOpen, setIsOpen] = useState(false);

This state usually has no business meaning. It exists only to connect a trigger to an overlay component.

When this pattern is repeated across many screens, developers either have to maintain a large number of trivial boolean states or create additional wrapper components around gluestack-ui. Both approaches add unnecessary complexity.

Controlled APIs are valuable when an overlay must be opened or closed programmatically, but they should not be required for the common case.

It would be helpful if gluestack-ui supported both controlled and uncontrolled usage, similar to other modern component libraries:

<AlertDialog>
  <AlertDialogTrigger asChild>
    <Button>Delete</Button>
  </AlertDialogTrigger>

  <AlertDialogContent>
    ...
  </AlertDialogContent>
</AlertDialog>

The component could also support defaultOpen for uncontrolled initialization, while retaining open and onOpenChange for controlled usage.

Suggested API capabilities:

• Uncontrolled state by default
• A composable Trigger component
• Support for defaultOpen
• Controlled open and onOpenChange as an optional escape hatch
• Consistent behavior across AlertDialog, Modal, Drawer, Menu, and Popover

I migrated away from several gluestack-ui overlay components because the required state-management boilerplate became difficult to maintain across a large project.

Would the maintainers be open to supporting an uncontrolled, trigger-based API for these components?