Reaccione Native desde la perspectiva de un desarrollador móvil



El artículo está dirigido a desarrolladores de iOS y Android que ya conocen bastante bien su campo y miran hacia React Native.

Cuando supe por primera vez acerca de React Native, aproveché la oportunidad para que los desarrolladores web invadieran mi territorio (¡ absolutamente imposible! ) Y al mismo tiempo estropearon el producto que funciona bien, libre de fallas y de 60 fps. Y así sucedió. El final La verdadera historia resultó ser más larga.

Negación


JavaScript en una aplicación móvil? Solo me vinieron a la mente un par de bibliotecas con el uso de JavaScriptCore en iOS (estas mismas bibliotecas representaron el 90% de los bloqueos de las aplicaciones en las que se usaron) y las aplicaciones híbridas del "modelo antiguo" (bueno, eso es generalmente atas).

Las aplicaciones híbridas mostraron esperanza hasta el momento en que las probó, después de lo cual comenzó a huir de ellas lo más rápido posible.

Recordando los intentos fallidos de aprender Xamarin hace 3 años, abandoné rápidamente la idea de usar React Native.

Vale la pena señalar que siempre estuve feliz de percibir nuevas formas de escribir aplicaciones nativas (desde ObjC a Swift, desde Java a Kotlin, desde Eclipse a Android Studio). He estado involucrado en el desarrollo de iOS y Android como hobby y profesionalmente durante muchos años. Después de cambiar a un nuevo idioma (dentro del mismo sistema operativo) o IDE, rara vez volví al anterior. Parecería que React Native es un próximo paso lógico, otro nuevo paso. ¿O es un paso atrás?

Ira


¿Por qué debería enseñar una versión simplificada cuando ya sé cómo hacer esto "de verdad"?
Todavía tenía que encontrar una respuesta a esta pregunta cuando la compañía estableció la tarea de rediseñar completamente una de las aplicaciones (en ese momento solo disponible en iOS) y lanzarla en Android.

¿Cómo hacer dos cosas a la vez y escribir menos código? Sugerencias como: un cliente ligero, bibliotecas C con una llamada del código Swift / Kotlin, ¿React Native?

React Native parecía bastante prometedor debido a la capacidad de crear bibliotecas y luego usarlas inmediatamente en tres plataformas (iOS / android / web).

Oferta


Prometedor para cualquiera, pero no para mí. Ciertamente no estaba contento con este giro. Sentí que estaba en la cima de la capacidad de desarrollar iOS y Android y luego me pidieron que desechara todo este conocimiento, como si fuera un recién graduado y tuviera 0. Incluso dudaba que con React Native pudieras crear un producto de calidad.



Depresión


Las dudas eran razonables. Los principales problemas son:

  • una cantidad decente de gotas en el núcleo de React Native;
  • métodos que funcionan solo en una plataforma (los muelles indican que funcionan en todas partes);
  • Descripción incompleta. Solo mira los muelles del coleccionista React Native .

El principal problema oculto: el bloqueo interno en mi cabeza, que me impedía ver las ventajas detrás de un montón de desventajas.

Aceptación


Y, por supuesto, React Native no solo tiene inconvenientes. Hay muchas cosas buenas, está escrito mucho más fácil y funciona mejor de la caja que en plataformas específicas.

Si descartamos problemas obvios, como bloqueos y muelles, aquí hay ejemplos de lo que tuve que enfrentar:

Javascript


No es de extrañar. Esto es lo primero que va de la mano a través de la sangre, el sudor y las lágrimas.
Cuando comencé a recordar mi experiencia previa como desarrollador frontend (estaba involucrado en sitios web antes de las aplicaciones móviles), comencé con el síndrome vietnamita: Johnny, ¡JavaScript nos rodea!

Si decide escribir aplicaciones en React Native, le recomiendo que tome uno de los últimos cursos de JS. No tienen que ser React o React Native.

En los últimos años, con el lanzamiento de los estándares ES6, ES7 y ES8, la forma en que escribes el código ha cambiado mucho.

Y se volvió muy personal .

Control estático


En los primeros meses, el analizador estático, que está en todos los idiomas móviles nativos, es muy deficiente.

Existen varias utilidades que suavizan su ausencia y realizan parte de las funciones.

Elementos de diseño


El mayor desafío aquí será para los desarrolladores principiantes de iOS.

Este desafío es la falta de un editor de interfaz visual.

Todo se hace en código usando el marcado JSX . Técnicamente, este marcado es opcional, ayuda a ver la jerarquía de componentes. Los desarrolladores de Android se sentirán cómodos al notar las similitudes con XML.

Al mismo tiempo, hay una visión clara de las vistas y el potencial de reutilización.

En iOS, hay uno u otro, según el método que se elija (diseño en código o en el generador de interfaces). Sí, ambos problemas pueden resolverse, pero debe escribir una cantidad decente de código.

React Native no tiene este problema.
En Android, por cierto, tampoco está allí.
Pero los expertos de Android apreciarán la forma en que los parámetros se transfieren de componentes externos a internos directamente en el marcado.

La vista básica aquí es un análogo de LinearLayout (android) y UIStackView (iOS) con una mezcla de constantes al mismo tiempo. Una forma bastante simple (en comparación con las restricciones) de elementos de posicionamiento.

UIViewController y Actividad


React Native no tiene ni lo uno ni lo otro.
Por supuesto que están debajo del capó. Interactuar directamente con ellos no funcionará. Sí, esto no es necesario.

El ciclo de vida de todos los componentes React Native es completamente diferente de iOS y Android, es difícil establecer paralelos. Si te enfocas en las diferencias de los sistemas nativos, entonces:

  • Los propios elementos de la interfaz de usuario cambian de estado / apariencia al cambiar los parámetros de entrada;
  • en Android no hay necesidad de hacer malabares con onSaveInstantState . React Native hace todo esto por nosotros;
  • En iOS, no hay métodos que informan explícitamente el momento en que aparecen / se ocultan las pantallas de la aplicación.

Tiempo de construcción / recarga en vivo / recarga en caliente


Se logra una gran velocidad debido al ensamblaje incremental: solo se reconstruyen los módulos modificados, y no todo el paquete.

Todos los cambios en el código JS son visibles inmediatamente visibles en el simulador. ¡Acelera enormemente el desarrollo!

Falta de funcionalidad nativa en JS


En la parte JS de React Native, no todo lo que necesita está listo para usar.

Puede escribir la parte nativa en ambas plataformas, hacer un contenedor JS y llamarlo como el resto del código. No hay nada complicado

Hay una gran cantidad de módulos listos para usar escritos por desarrolladores externos.

Todos los módulos están conectados a través de npm (análogo de CocoaPods para iOS y Gradle para Android), que tienen un código nativo con la funcionalidad necesaria.

Enlaces universales y profundos


La funcionalidad es implementada por Facebook.
Funciona bien y consistentemente.

Procesamiento de intenciones de terceros


Como un caso especial del párrafo anterior.

El mayor problema en Android es manejar un Intent que no sea un enlace profundo en una aplicación.
Depende, por supuesto, de la intención y de lo que debe hacerse cuando se recibe.

Puede escribir un artículo separado sobre este tema. El punto de partida es agregar el método createReactActivityDelegate a MainActivity.

Rendimiento


Es bastante fácil obtener 60 FPS al desplazarse por largas listas con celdas complejas.
El rendimiento de todo lo demás (por ejemplo, presionar un botón, imprimir texto en un campo) es menor. Es notable durante un cambio de estado animado en una gran cantidad de elementos. Esto se puede solucionar fácilmente. Una buena sección en la documentación Usando Native Driver para Animated .

Y no puede obtener el control normal de los gestos y su asociación con la animación fuera de la caja.



Inestabilidad


A menudo, un proyecto simplemente deja de construirse, por ejemplo después de:

  • Reaccionar las actualizaciones del kernel nativo (incluso al actualizar la versión secundaria);
  • actualizaciones del módulo npm;
  • Actualizaciones de Xcode;
  • Actualizaciones de CocoaPods (problemas permanentes con esto);
  • solo asi Sí, eso también pasa.

Afortunadamente, la mayoría de estos problemas se solucionan con bastante rapidez. Puede agregar una secuencia de comandos que limpie todas las cachés en todas partes y ejecutarla cuando algo salga mal. Ayuda a resolver el 98% de los problemas extraños que surgen de la nada. Con la excepción de CocoaPods, todo es triste.

Inestabilidad de dependencia de terceros


El mayor problema en iOS fue y es el deseo generalizado de los módulos npm de utilizar el método swizzling .

Muchos módulos nativos están conectados por binarios. Comprender que varios módulos independientes svizlyat el mismo método no es tan simple.

El montaje se lleva a cabo en varias etapas y en cada una de ellas puede salir algo mal.

Inestabilidad al actualizar dependencias de terceros


Algunos módulos npm dependen de otros módulos npm, y así sucesivamente. Si dos módulos están vinculados a diferentes versiones del tercer módulo, inmediatamente recibimos una advertencia al instalar, en el mejor de los casos. Y en el peor de los casos, no hay advertencia, pero nada funciona.

Un problema similar si los módulos npm se basan en módulos nativos de Android con diferentes versiones.

Después de limpiar el caché, las nuevas versiones pueden cargarse silenciosamente. Parece que no hizo nada, pero dejó de trabajar.

Unidad y pruebas de IU


Un mecanismo de prueba muy fácil a través de la biblioteca Jest, viene con React Native. Análisis conveniente de la cobertura de la prueba: muestra qué líneas de la función bajo prueba nunca se han llamado.

Hay bibliotecas para pruebas de IU. Hasta ahora, de hecho, no tuvo que usar.

Conclusión


Después de 13 meses de trabajar con React Native, puedo decir con confianza:

  • es adecuado para la mayoría de las aplicaciones en las que solo necesita obtener una lista del servidor, mostrar la lista, mostrar una vista detallada del elemento de la lista, enviar cambios al servidor;
  • todo lo anterior se logra con menos código;
  • ahora esta es mi opción "predeterminada" para nuevos proyectos que me están contactando, porque vea el párrafo anterior;
  • no es adecuado para proyectos que se van al extranjero "envió una solicitud - recibió una respuesta", algunos ejemplos: editor de fotos, reproductor, trabajo con Bluetooth, AI, ML, social. mensajero de red;
  • Los proyectos avanzados se pueden hacer en React Native, pero aún tiene que escribir mucho código nativo, por lo que el punto ya no es válido;
  • React Native ha venido y no irá a ninguna parte, esto debe tenerse en cuenta;
  • la demanda de desarrolladores móviles nativos disminuirá ligeramente, la afluencia de nuevos desarrolladores móviles nativos disminuirá mucho más. Por qué ver abajo;
  • una persona generalmente sigue el camino más simple, y no hay necesidad de probar si el 95% de las aplicaciones se pueden hacer gastando el 20% del esfuerzo (en comparación con el desarrollo nativo) para estudiar;
  • Como consecuencia de los tres puntos anteriores: la brecha entre la demanda y la oferta de desarrolladores móviles nativos será aún mayor. Aquellos que realmente no pueden prescindir de ellos les resultará aún más difícil encontrarlos. Y esto es triste.

La última palabra para alguien que inmediatamente comenzó a escribir en React Native y por alguna razón decidió leer este artículo, incluso hasta el final.

Si crees que entiendes el tema y te está yendo bien, entonces, por favor, pruébalo como desarrollador nativo.

Source: https://habr.com/ru/post/es416097/


All Articles