Estoy construyendo mi primera aplicación React Native + Redux en este momento.
Antes de comenzar, habría clasificado mi nivel de habilidad js como “intermedio”. Podría comenzar con un editor en blanco y jquery y producir cualquier tipo de sitio web con bonita animación y gráficos. También me siento cómodo depurando y extendiendo js de otras personas, que es algo que tuve que hacer con cada módulo que compré en Code Canyon. Podía mirar el js no minificado desde cualquier sitio web y leerlo sin problemas.
… luego vino React Native …
- ¿Cuál es la mejor aplicación en Play Store para descargar videos de YouTube?
- ¿Cuánto dura la producción de aplicaciones móviles para ciertas campañas de marketing?
- ¿Dónde puedo informar cuando mi aplicación Quora no funciona correctamente?
- ¿WhatsApp tendrá cuentas verificadas para empresas?
- ¿Cuál es la mejor aplicación de noticias de electrónica?
La pila que estoy usando es React Native + Redux con flujo. Ha sido una curva de aprendizaje muy empinada para mí.
Primero, está usando ES6 … bueno, más o menos. Utiliza ES6, pero gran parte de la documentación y los ejemplos son ES5, especialmente los ejemplos web React, que TBH son casi inútiles para React Native. Personalmente, ES6 tiene una serie de “características” que realmente no me gustan. También estoy usando el flujo para la escritura estática. No lo había usado antes. Prefiero la escritura estática en idiomas, pero es una especie de ‘hack-y’.
A continuación, utiliza JSX, que es una extensión de JavaScript que le permite un marcado en línea similar a XML. Es una especie de “ordenado” porque construir interfaces de usuario jerárquicas es tan fácil como abrir un elemento, agregar elementos secundarios y luego cerrar el elemento. Sin embargo, es confuso al principio, tratando de recordar cómo mezclar JSX y javascript. Por ejemplo, JSX no tiene funcionalidad de comentario, por lo que debe colocar el JSX que desea comentar en un bloque de JavaScript y luego comentar el JSX. Debido a que es un ML y no un lenguaje de programación, no hay control de flujo, por lo que descubrir cómo hacer el control de flujo dentro de su salida JSX es confuso. Todavía no estoy seguro si la forma en que lo estoy haciendo es correcta.
Además, los mensajes de error informados por el depurador no siempre son útiles. Los errores de sintaxis son bastante buenos, pero he tenido algunos que eran como “se esperaba el tipo ‘Objeto’ pero recibí el tipo ‘Objeto'” con un archivo y un número de línea en algún lugar de la base de código RN sin rastrear ninguno de mis códigos … aunque sé que el error proviene de mi código en alguna parte.
React Native también sufre problemas de reinvención, pero, por ejemplo, si no ha utilizado las bibliotecas Java o C / C ++ UI antes, estará bien. Encontré que la nomenclatura del sistema de eventos de IU de RN no es estándar por ninguna buena razón que pueda ver. También sufre de ineficiencias que se han resuelto en otros sistemas, pero según la nomenclatura no estándar, supongo que los arquitectos no investigaron mucho. (Esto parece ser algo común con las plataformas y bibliotecas javascript).
Dicho esto, la curva de aprendizaje ha valido la pena. Me gusta la plataforma RN. Durante semanas he podido ver dónde están las eficiencias de desarrollo, incluso si solo ahora puedo aprovecharlas. También me gusta la arquitectura sensata. Hay muy poca “magia”, y no pretende ser algo que no es.
Normalmente me doy 2 semanas para ser “productivo” con una nueva plataforma. En retrospectiva, con RN y donde estaba con JavaScript cuando comencé, debería haber asignado 6 semanas.
Además, aquí hay algunos consejos:
Ponga cualquier bloque de comentario grande fuera de sus funciones. El optimizador cuenta los comentarios cuando analiza los tamaños de las funciones. Las funciones de menos de 600 bytes están en línea (o algo similar), y el tamaño de 600 bytes incluye bytes ocupados por comentarios dentro de la función. Comencé con la fuente de la aplicación F8 para comenzar a aprender RN, y me preguntaba por qué solo hay uno o dos comentarios en toda la fuente.
Si escribe mal un nombre de estilo cuando asigna un estilo a un componente, no hay error ni advertencia de que el estilo no existe. Si sigue cambiando los parámetros de estilo y el componente no cambia, verifique la asignación.
El empaquetador solo verá enlaces simbólicos creados mientras se está ejecutando. Si detiene el demonio del empaquetador y lo reinicia (como para un reinicio), tendrá que volver a crear los enlaces simbólicos en su árbol fuente para que el empaquetador los vea y los envíe a su aplicación para probarlos. De lo contrario, su aplicación a) se quejará de la falta de archivos, o b) no cargará los archivos sin ninguna advertencia o error, y las cosas no funcionarán como se esperaba.
