Composing React UI with Providers

Summary

Speaker examines complexity of large React UI components using Slack composer as example.
Argues against monolithic components with many boolean props and conditional logic.
Proposes composition plus lifted providers (context) to separate UI from state implementations.
Demonstrates composing header, input, footer, dropzone, and action components via JSX instead of arrays/flags.
Recommends lifting provider/state to allow external components to access actions without prop drilling.
Suggests provider interface decouples state implementation (useState, global sync hook) from component internals.
Emphasizes codebase design benefits for human developers and AI code generation/editing.

(Soon – Team) Replace large boolean-prop monolith components with composed subcomponents and provider roots.
(Soon – Team) Create distinct action components for footer actions instead of a single actions array.
(Next Sprint – Team) Lift component provider state higher to allow external controls to access submit actions.
(Next Sprint – Team) Abstract common subtrees (e.g., common actions) as reusable compound components.
(Future – Team) Support multiple state implementations by swapping provider implementations (local vs global sync).

Component	Responsibility	Notes
Provider	Holds state & shared actions; defines context interface	Implementation can be local useState or global sync hook
Frame	Visual container for composer UI	Rendered inside provider
Header	Composer header UI	Simple composition unit
Input	Renders and updates text from context	Agnostic to state implementation
Footer	Renders action components and submit UI	Built via JSX; accepts custom children
DropZone	Handles drag-and-drop attachments	Only render when attachments enabled
Common Actions	Reusable group of left-side actions	Wraps individual action components
External Actions Row	Actions outside composer box accessing submit	Uses provider context without prop drilling

Problem: many boolean props lead to 30+ conditional checks across the component tree.
Symptoms: duplicated checks, prop drilling, fragile unions, and unreadable arrays of action configs.
Solution: use composition (JSX) to render distinct trees per use case, not flags controlling internals.

Implement every footer action as its own component; share base button internally.
Avoid looping over arrays with many conditional fields (menu, divider, items).
JSX enables clear, maintainable component trees and easy customization.

Provider/Context Interface: defines actions and state shape consumed by children.
Implementations:
- Local/Ephemeral: provider uses useState for modal-forward composer.
- Global/Synced: provider wraps a hook (e.g., useGlobalChannel) to sync across devices.
Key benefit: swap state implementation by replacing provider without changing children.

Problem: buttons outside composer needing access to composer state or submit.
Pattern: lift provider higher so external components are still inside provider tree.
Benefit: external actions can call submit via context; no upward prop drilling or effect syncing.

Favor composition and explicit JSX composition over single monolithic components with many props.
Use a provider-per-composer pattern; provider exposes a stable interface for children.
Implement shared subtrees (common actions) but allow per-composer custom action composition.
Swap state mechanisms by replacing provider implementation, not changing consumer components.

Which existing monolithic components should be prioritized for refactor first?
What testing strategy ensures provider swapping retains behavior across local/global state implementations?
Should a standard interface spec be documented for composer providers to ensure consistent consumption?
How to migrate existing code that currently relies on many boolean props without large regressions?