Compartir el contrato semántico entre React y React Native en vez del código
El proyecto Vellira separa los tipos y las reglas comunes de cada implementación: un botón significa lo mismo en web y en nativo, pero cada runtime expone lo que su entorno permite.
Compartir un sistema de diseño entre React y React Native parece sencillo hasta que aparece el primer componente serio. La propuesta que defiende el autor de Vellira es no compartir la implementación, sino el contrato semántico: que un botón signifique lo mismo en las dos plataformas aunque debajo haya primitivas distintas.
El argumento de partida es que nadie consume el árbol de componentes, sino la API pública y su comportamiento. Al desarrollador le da igual cómo se implemente por dentro un botón; lo que quiere es aprender una vez que existen appearance, size, loading o disabled y poder llevar ese vocabulario del web al nativo sin volver a estudiarlo.
El contrato compartido
En Vellira ese vocabulario vive en un paquete de tipos común. El código está en el repositorio y la referencia, en la documentación. Allí se definen los valores de tamaño (sm, md, lg), los colores (primary, neutral, success, warning, danger), las apariencias (solid, outline, ghost, soft, link) y una interfaz base que recoge color, appearance, size, shape, fullWidth, loading, loadingText, disabled e iconOnly. Nada de eso menciona el DOM ni las props nativas: describe qué es un botón del sistema. Si appearance="soft" existe en ambos lados, tiene que significar lo mismo, y si loading bloquea la interacción, esa regla también es idéntica.
Cada plataforma extiende a su manera
A partir de ahí, cada runtime añade lo que su entorno permite. En web, la interfaz extiende los atributos de HTMLButtonElement y toma de los anclajes las props href, target, rel y download, además de tooltip, badge o shortcut. En React Native, el mismo contrato se combina con PressableProps y añade StyleProp<ViewStyle>, iconSize, testID, accessibilityLabel y los eventos de gesto, con un onPress que recibe un GestureResponderEvent.
Inventar un href falso en nativo para que las firmas queden simétricas se descarta a propósito: sería paridad sobre el papel y una API peor. El criterio que propone el autor es distinguir si una propiedad describe comportamiento del producto o del runtime. Lo primero va al contrato común; lo segundo, al paquete de plataforma.
El mismo principio vale para los tokens. Espaciados, radios, tipografías y colores salen de una fuente única, pero CSS y los objetos de estilo de React Native los consumen a su manera. Compartir la decisión, adaptar la ejecución.
Queda el riesgo evidente: dos implementaciones se separan con el tiempo. Si el botón web gana una apariencia nueva y el nativo no, la paridad se rompe sin que nadie lo note. Probar en la frontera del contrato, y no dentro del componente, es la parte que el texto apunta pero no llega a resolver.
