En React Native, una pantalla es una parte de la interfaz asociada a una vista o tarea concreta: por ejemplo, el listado de productos, el detalle de uno de ellos o el perfil de una persona. No existe un componente integrado llamado «screen» que resuelva por sí solo la navegación. Lo habitual es crear componentes de pantalla con React y conectarlos mediante una biblioteca de navegación.
La decisión importante no es cómo llamar a cada archivo, sino dónde separar la interfaz, la lógica de cada tarea y el recorrido entre vistas. Una estructura clara facilita añadir rutas, conservar el estado cuando el usuario vuelve atrás y adaptar la experiencia a Android e iOS.
Qué es una pantalla y en qué se diferencia de un componente
Una pantalla suele representar una unidad que el usuario puede abrir desde la navegación de la aplicación. Un componente, en cambio, puede ser una pieza reutilizable dentro de una o varias pantallas: una barra de búsqueda, una tarjeta o un botón. Una pantalla puede combinar muchos componentes, y un componente no necesita convertirse en una ruta navegable.
Por ejemplo, una aplicación hipotética de recetas podría tener RecipeListScreen, RecipeDetailScreen y SavedRecipesScreen. La lista podría incluir componentes como RecipeCard y SearchBar. Mantener esta distinción evita crear una ruta para cada elemento visual y permite reutilizar piezas sin mezclar la navegación con su presentación.
La pantalla también es un buen límite para organizar responsabilidades. Puede ocuparse de obtener o recibir los datos que necesita, gestionar acciones propias de esa vista y componer la interfaz. Si varias pantallas repiten el mismo formato, se extraen componentes comunes; si comparten una regla de negocio, esa lógica puede vivir en una función o módulo independiente.
La navegación conecta pantallas, no las crea automáticamente
React Native proporciona elementos para construir interfaces nativas, pero la navegación entre pantallas suele resolverse con una biblioteca. React Navigation es una opción habitual; Expo Router es otra alternativa, con un enfoque basado en rutas y archivos dentro de proyectos compatibles. No son sinónimos de una pantalla: gestionan cómo se llega a ella y qué ocurre al avanzar o retroceder.
Pila, pestañas y rutas anidadas
Un navegador de pila representa una secuencia de vistas. Abrir un detalle desde un listado añade una pantalla al recorrido; volver atrás retira la vista superior y muestra la anterior. Es un patrón adecuado para flujos como lista, detalle y edición.
Las pestañas permiten cambiar entre áreas principales, como «Inicio», «Guardados» y «Perfil». En una aplicación real, una pestaña puede contener a su vez una pila: desde «Inicio» se abre un detalle, y al regresar se vuelve al mismo contexto. Esta combinación tiene sentido cuando las pestañas representan destinos principales y cada uno necesita navegación propia.
No todas las vistas deben aparecer en la barra principal. Una pantalla de inicio de sesión, un formulario temporal o un detalle suelen abrirse como parte de un flujo. Si cada vista se convierte en una pestaña, la navegación pierde jerarquía y resulta más difícil anticipar qué hará el botón de volver.
Parámetros frente a estado compartido
Los parámetros identifican el destino o transportan datos pequeños necesarios para mostrarlo. Al abrir el detalle de una receta, por ejemplo, se puede pasar su identificador; la pantalla consulta entonces el contenido correspondiente. Esta opción evita enviar objetos grandes o potencialmente desactualizados por la navegación.
El estado compartido sirve para datos que varias pantallas necesitan consultar o modificar, como una sesión de usuario o una selección persistente. Pasar un identificador por la ruta y cargar los datos en la pantalla suele ser más sencillo de mantener que duplicar el objeto completo en distintos lugares. La elección depende de dónde se usa el dato, cuánto dura y qué debe ocurrir si cambia.
Organizar los archivos para que el proyecto siga siendo legible
Una estructura pequeña puede separar las pantallas de los componentes y de la configuración de navegación. Por ejemplo:
src/
navigation/
AppNavigator.js
screens/
RecipeListScreen.js
RecipeDetailScreen.js
components/
RecipeCard.js
services/
recipes.jsLa carpeta es una convención, no un requisito de React Native. En proyectos con rutas gestionadas por archivos, la organización puede reflejar directamente el mapa de navegación. Lo esencial es que una persona pueda localizar con rapidez la vista, sus piezas reutilizables y el origen de sus datos.
Como regla práctica, una pantalla debería expresar el propósito de la vista y no el aspecto de un único control. Nombres como RecipeDetailScreen comunican mejor la función que WhitePanel. A la vez, no es necesario extraer cada bloque de pocas líneas: crear componentes solo aporta valor cuando mejora la reutilización, la lectura o la separación de responsabilidades.
Un recorrido práctico: del listado al detalle
Imaginemos una aplicación hipotética con una lista de recetas y una vista de detalle. El flujo puede diseñarse en estos pasos:
- Definir las rutas: el navegador registra la pantalla del listado y la del detalle. Cada ruta tiene un nombre estable que el resto de la aplicación utiliza.
- Mostrar datos resumidos: cada elemento del listado presenta información suficiente para elegir una receta, como su nombre y una imagen.
- Abrir el detalle: al tocar una tarjeta, la aplicación navega al detalle y pasa el identificador de la receta seleccionada.
- Resolver el contenido: la pantalla de detalle busca los datos a partir de ese identificador y contempla qué mostrar mientras carga o si la receta ya no existe.
- Volver al listado: la navegación restaura el recorrido anterior. Si el listado se desmonta al cambiar de ruta, quizá haya que conservar fuera de la pantalla información como la búsqueda o la posición de desplazamiento.
El ejemplo muestra por qué la navegación y los datos son asuntos relacionados, pero distintos. La primera determina qué vista está activa y cómo se retrocede; la segunda decide qué contenido necesita esa vista y cómo se obtiene.
Estado, foco y ciclo de vida de una pantalla
Una pantalla puede seguir montada aunque deje de estar visible, según el navegador y su configuración. Por eso, «la pantalla está abierta» y «la pantalla tiene el foco» no siempre significan lo mismo. El foco indica que esa vista es la que el usuario está viendo dentro de la navegación actual.
Esta diferencia importa al actualizar datos al regresar a un listado. Si la pantalla permanece montada, un efecto que solo se ejecuta al montarse no volverá a activarse por el mero hecho de recuperar el foco. Para refrescar en ese momento, se utiliza el mecanismo de eventos de foco que ofrezca la solución de navegación elegida, o se actualizan los datos como resultado de una acción concreta. Así se evita recargar información en cada renderizado.
También conviene distinguir el estado temporal del duradero. El texto que se está escribiendo en un campo puede pertenecer a la pantalla; una lista de elementos guardados quizá deba sobrevivir al cambio de ruta o incluso al cierre de la aplicación. La ubicación del estado debe responder a quién lo necesita y durante cuánto tiempo, no a una preferencia por centralizarlo todo.
Detalles de experiencia que suelen olvidarse
Volver atrás y áreas seguras
En Android, el botón de retroceso del sistema forma parte del flujo esperado; en iOS, los gestos y controles de navegación siguen convenciones distintas. La biblioteca de navegación gestiona parte de ese comportamiento, pero la aplicación debe evitar rutas que dejen al usuario sin una salida clara o que descarten un formulario sin explicación.
Las barras de estado, las zonas próximas a la cámara y los indicadores de inicio también condicionan el espacio disponible. El diseño de una pantalla debe contemplar las áreas seguras y no colocar botones esenciales debajo de elementos del sistema. El resultado se comprueba en dispositivos con diferentes tamaños y configuraciones, no solo en una vista previa.
Accesibilidad y rendimiento
Los controles interactivos necesitan etiquetas comprensibles para tecnologías de asistencia y un orden de lectura lógico. Un icono para volver, por ejemplo, debe comunicar esa acción; su forma visual por sí sola no siempre basta. También hay que comprobar contraste, tamaño de los objetivos táctiles y comportamiento al ampliar el texto.
En listas largas, renderizar todos los elementos a la vez puede consumir más recursos. Los componentes de lista optimizados de React Native permiten mostrar elementos de forma más eficiente, siempre que las claves sean estables y las filas no hagan trabajo innecesario. Si una navegación se siente lenta, revisar la carga de datos, el renderizado de la lista y las animaciones ofrece pistas más útiles que atribuir el problema genéricamente a las pantallas.
Cómo comprobar una implementación antes de ampliarla
Antes de añadir más rutas, recorre los casos principales en Android e iOS: abrir una vista, volver, cambiar de pestaña y recuperar una pantalla que conserva datos. Comprueba también los estados de carga, error y contenido vacío; una pantalla no está completa si solo funciona cuando la información llega correctamente.
- Verifica que cada acción conduce a la ruta prevista y que el botón de volver conserva un comportamiento coherente.
- Prueba parámetros ausentes o identificadores que ya no corresponden a un elemento disponible.
- Revisa qué estado debe mantenerse al salir de una pantalla y cuál debe reiniciarse.
- Comprueba etiquetas accesibles, desplazamiento, teclado y áreas seguras en tamaños de pantalla distintos.
Quien esté comparando patrones o herramientas puede ampliar la consulta sobre React Native. Para decidir la arquitectura, la referencia más útil sigue siendo el flujo real de la aplicación: cuántas áreas principales tiene, qué datos comparte y qué espera el usuario al navegar hacia delante y hacia atrás.
