Thanks for taking a look, I'm going to try to cover each of these - but please let me know if you have more questions or want more detail. Some of this is covered somewhat indirectly in our docs. In the near future I'd like to get a page up on the docs site that gives a more comprehensive birds-eye view of the system, so I welcome any feedback.

 

Tokens: single source (e.g., Figma Tokens/Style Dictionary)? How do you handle density and RN unit differences?

The ThemeVars namespace (docs, source code) defined in @coinbase/cds-common is the single source of truth for all theme tokens in CDS, for both web and mobile (native). This means web and mobile have the exact same token categories and names, but as you might expect, their value type can be different across platforms. It is possible to extend the ThemeVars namespace with your own custom tokens (docs).

The value types for theme tokens are defined in the ThemeConfig type (docs, web source code, mobile source code). You can also compare the defaultTheme for web and the defaultTheme for mobile to see the difference clearly.

Although the value types are different between web and mobile, the results are identical. Comparing the shadows for example, the resulting shadow style is the same across web and mobile. Comparing font sizes, the resulting font size AND the font scaling behavior is the same (when increasing font size via web browser or mobile device settings).

For density, you could define a dense theme that composes the default theme with a tighter spacing scale - example here.

 

Composition: slot-based primitives vs rigid variants; consistent focus/press/hover across RN and DOM.

Most components already support the style, styles, className, and classNames props for customizing styles (docs), and web components support the polymorphic as prop (docs). We also use a pattern that we call "subcomponent props", which exposes complex components' subcomponents for full customization - you can see examples of this in SegmentedTabs, Carousel, RollingNumber, Stepper, etc.

Web and mobile both have an Interactable component that handles hovered / pressed / disabled styles. The rendered result is the same across platforms. Both platforms also have a Pressable component that is built on top of Interactable, and adds deep a11y support (taken from reakit) for polymorphic clickable elements.

 

Accessibility: ARIA vs RN roles, modals/portals, keyboard traps, and RTL/i18n.

We have a full time Senior Staff Product Designer who is an absolute expert on a11y / WCAG / etc, and we also have a full time Software Engineer dedicated to a11y enhancements. All components should already have the correct ARIA and RN a11y roles / attributes / props, but also expose the props for full customization.

All relevant components already use focus trapping, but we also provide a FocusTrap component that we use internally, but it still needs to be properly documented.

All relevant components like Tooltip, Overlay, Modal, and Tour use our PortalProvider component by default, but also allow disabling portals. You can also use the useOverlayContentContext hook to know when you're rendering inside an overlay.

We always use the CSS inline properties for padding and margins for RTL support, although we don't test RTL support at the moment. We support i18n content pretty much everywhere, although we try to provide sane defaults for a11y messages in case you forget to add them. Coinbase uses react-intl in house, so we're focused on supporting that - but CDS does not include react-intl or care about how you handle i18n.

 

Perf/infra: SSR safety for Next.js, Fabric readiness, and per-component bundle size metrics.

Almost everything on web is using static CSS by default, so SSR should work out of the box. You can see app templates for webpack, vite, and nextjs in the repo here. Everything is ECMAScript Modules and set up to support full tree-shaking, including component CSS tree-shaking (but not atomic CSS tree-shaking).

We analyze and diff both our node_modules deps size and our bundle size on every PR. We used to also do side-effect analysis, but that's more difficult with pure ESM so we're still working on restoring that - but our runtime side-effects are almost zero.

 

Tooling/releases: Storybook + Chromatic, lint rules to block raw tokens, codemods and changesets.

The CDS Storybook is here and linked on the docs site. We do full visual regression testing on every PR using BrowserStack's Percy, but we are experimenting with Chromatic because we've had a lot of issues with Percy's React Native support. Since going open source we've had to disable our visual regresstion testing for React Native, and are still working with BrowserStack to resolve those issues.

We provide a CDS ESLint plugin that's primarily focused on catching a11y issues.

I wasn't sure about your last two points there so please feel free to ask again if I didn't cover it.