Preguntas de entrevista React Native

¿Cuál es la diferencia entre props y state en React Native?

Props son datos de solo lectura pasados por un componente padre, y pertenecen a quien los pasa; state es local al componente y cambia con el tiempo mediante useState o useReducer. Un componente que recibe los mismos props dos veces sin cambio de state debería renderizar la misma salida — eso es lo que hace que los props sean predecibles. Pasar setters hacia abajo como props ("elevar el state") es la forma estándar de que un hijo dispare un cambio de state que no le pertenece.

¿Qué es JSX y a qué se compila en realidad?

JSX es azúcar sintáctico para llamadas a React.createElement — <View style={styles.box}>{text}</View> se convierte en un árbol anidado de objetos elemento, no en nodos DOM reales porque en native no hay DOM. La transformación de Babel convierte las etiquetas en llamadas a funciones antes de que el JS siquiera se ejecute, así que JSX es una comodidad de build-time, no una característica de runtime. En React Native esos objetos elemento terminan describiendo una jerarquía de vistas nativas en lugar de HTML.

¿Qué hacen `useState` y `useEffect`, y cuándo se ejecuta el efecto?

useState da a un componente un pedazo de state y un setter que dispara un re-render al llamarlo; useEffect ejecuta un efecto secundario después de que el render se confirma, y solo se vuelve a ejecutar cuando algo en su array de dependencias cambió. Olvidar una dependencia es la causa más común de closures obsoletos — el efecto sigue referenciando el valor del render en que se creó. Un array de dependencias vacío significa "ejecutar una vez al montar", y no tener array significa "ejecutar después de cada render".

¿Cómo funcionan los estilos en React Native, y por qué Flexbox se comporta distinto que en la web?

No hay CSS — los estilos son objetos JS creados con StyleSheet.create, mapeados por debajo a propiedades de vistas nativas. Flexbox sigue siendo el motor de layout, pero flexDirection por defecto es column en lugar de row, no hay cascada CSS, y las unidades son píxeles independientes de densidad sin unidad, no px/em/rem. Anchos en porcentaje, flex: 1 para llenar el espacio restante, y justifyContent/alignItems para alinear cubren la mayoría de los layouts reales.

¿Cómo funciona la navegación con React Navigation, y qué agrega el deep linking?

React Navigation modela la app como un árbol de navegadores — stack, tab, drawer —, cada pantalla registrada con un nombre, y navigation.navigate('Screen', params) mueve entre ellas manteniendo una pila de historial para el gesto de volver atrás. El deep linking mapea un esquema de URL externo o un universal link a una pantalla específica con parámetros, así que una notificación push o un enlace web puede llevar al usuario directamente a, digamos, una pantalla de detalle de pedido en vez del inicio de la app. Hacerlo bien implica manejar tanto un cold start (la app no está corriendo) como una reanudación en caliente desde un enlace.

¿Qué es el bridge, y en qué se diferencia de JSI y la New Architecture?

En la arquitectura antigua, JS y el código nativo no comparten memoria — se comunican a través del bridge, una cola de mensajes asíncrona, agrupada en lotes y serializada en JSON, lo que significa que cada llamada nativa tiene costo de serialización y latencia. JSI (JavaScript Interface) reemplaza eso con bindings directos en C++, dejando que JS mantenga referencias a objetos nativos y llame a sus métodos de forma síncrona, sin necesidad de serialización. La New Architecture se construye sobre JSI: TurboModules reemplazan a los módulos nativos, y Fabric reemplaza al viejo UI manager, ambos capaces de hablar con código nativo directamente en vez de encolar a través del bridge.

¿Cómo evitas que un `FlatList` largo se ponga tosco?

Dale a cada item un keyExtractor estable, memoiza el componente de fila con React.memo para que un re-render del padre no vuelva a renderizar cada fila, y evita funciones y literales de objeto inline en renderItem, porque una referencia nueva en cada render anula la memoización. getItemLayout se salta un pase de medición cuando la altura de la fila es fija, y windowSize/initialNumToRender/removeClippedSubviews cambian memoria por fluidez de scroll. Para listas muy grandes o complejas, FlashList de Shopify resuelve el mismo problema con menos ajuste manual.

¿Cuáles son las diferencias reales entre construir para iOS y Android en React Native?

Las safe areas, el comportamiento del teclado y el estilo de sombras (props shadow* en iOS vs. elevation en Android) divergen lo suficiente como para que la paridad pixel-perfect necesite código específico de plataforma vía Platform.select o extensiones de archivo .ios.js/.android.js. Los permisos, la configuración de notificaciones push y los límites de tareas en segundo plano siguen las reglas propias de cada plataforma — los límites de ejecución en segundo plano de Android y la revisión más estricta de la App Store de iOS son restricciones distintas, no solo APIs distintas. Un módulo nativo escrito para una plataforma necesita una contraparte real en Swift/Objective-C y Kotlin/Java antes de funcionar en ambas.

¿Cómo sale realmente un release — qué tienen que ver Metro, las actualizaciones OTA y la revisión de la store?

Metro empaqueta y sirve el JS durante el desarrollo y lo empaqueta dentro del binario de la app para el release; no es parte de lo que reciben los usuarios, solo es la herramienta de build. Los servicios de actualización OTA como CodePush o Expo Updates envían un nuevo bundle JS directamente a las apps instaladas sin revisión de App Store o Play Store, lo cual es rápido para bugfixes pero está explícitamente prohibido para cualquier cosa que cambie código nativo o cruce lo que la store considera "no solo contenido". Los cambios nativos — un nuevo módulo nativo, un permiso, un bump de SDK — siempre requieren un build completo y un nuevo envío a la store, así que un equipo vive en dos velocidades: OTA para fixes solo de JS, releases de store para todo lo nativo.