Skip to content

Investigate BoxProps incompatibility in forwarding wrappers under mixed React Native type sources #1115

@georgewrmarshall

Description

@georgewrmarshall

Summary

After the ADR-0004 Box type migration, MetaMask Mobile hit TypeScript failures when consumer wrapper components extended BoxProps and then forwarded those props into <Box {...props} />.

The failure appears when the consumer dependency graph still exposes older @types/react-native callback types while @metamask/design-system-react-native resolves React Native 0.76 bundled types.

Repro shape

A minimal consumer-side pattern that can fail:

import { Box, BoxProps } from '@metamask/design-system-react-native';

interface WrapperProps extends Omit<BoxProps, 'children'> {}

export const Wrapper = (props: WrapperProps) => <Box {...props} />;

In MetaMask Mobile this surfaced most clearly on onLayout, where TS compared:

  • @types/react-native LayoutChangeEvent
  • vs React Native bundled LayoutChangeEvent

The JSX spread then failed even though BoxProps looks structurally correct.

Observed behavior

In MetaMask Mobile:

  • BoxProps in forwarding wrappers can fail TS checks on native callback props like onLayout
  • React.ComponentProps<typeof Box> works reliably because it matches the actual JSX contract of the concrete Box component
  • Removing/hiding node_modules/@types/react-native in a local repro made the HeaderSearch onLayout mismatch disappear

Why this matters

Mobile is temporarily using React.ComponentProps<typeof Box> in forwarding wrappers to unblock the stable design-system release pipeline, but this is a consumer-side workaround. We should decide whether MMDS can provide a clearer or safer library-side path.

Questions to resolve

  • Is the root cause entirely consumer-side mixed RN type identity, or does the exported BoxProps alias shape contribute?
  • Should MMDS explicitly document that forwarding wrappers should prefer React.ComponentProps<typeof Box> over BoxProps?
  • Should MMDS export an official wrapper-safe alias such as BoxComponentProps?
  • Can emitted declarations or package typing strategy be improved to reduce this mismatch for consumers still carrying DT React Native packages?

Suggested acceptance criteria

  • Reproduce the issue in a small consumer fixture
  • Confirm whether mixed RN type sources are sufficient to trigger it
  • Decide on the recommended library guidance and/or exported type surface
  • Document the intended consumer pattern for forwarding wrappers

Related context

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions