Recientemente, el equipo de Qwintry comenzó una migración activa a Vue.js en todos nuestros proyectos antiguos y nuevos:- en un sistema heredado basado en Drupal (qwintry.com)
- en nuestro nuevo hilo qwintry.com completamente reescrito (backend en Yii2 / Node.js)
- en nuestros sistemas B2B (impulsados por Yii2) (logistics.qwintry.com)
- en todos nuestros pequeños proyectos internos y públicos (principalmente usando PHP y Node.js en el backend)
Por qué nuestros programadores optaron por Vue.js, dice el jefe de desarrollo de Qwintry LLC . Anton Sidashin ➔Brevemente sobre nosotros: el proyecto Qwintry es utilizado por medio millón de clientes en todo el mundo, tenemos dos almacenes (en EE. UU. Y Alemania) que utilizan nuestro propio software en la nube, y somos uno de los mayores reenviadores de correo en EE. UU. En términos de tráfico de visitantes y salidas. Ayudamos a las personas a comprar productos en las tiendas en línea de EE. UU. Y a administrar sus paquetes en nuestra cuenta personal, así como podemos ahorrar significativamente en envíos internacionales. Utilizamos nuestra propia plataforma de TI y cadenas de suministro para proporcionar entregas internacionales de calidad a un buen precio.
Nuestro paquete en la puerta del cliente - de las opiniones de los clientesQwintry tiene una base de código bastante grande, que consiste principalmente en PHP y JS (+ Swift y Java para aplicaciones móviles).Decidimos usar Vue.js después de crear una aplicación de prueba con idéntica funcionalidad, nuestra calculadora , en React, Vue.js y Angular2. React.js
La popularidad de React se ha disparado en el último año o dos, y ahora, tal vez, es la opción predeterminada para un desarrollador de JS que quiere escribir algo más complicado en la interfaz que un párrafo de código de tres líneas.Vimos varios SPA y widgets dinámicos en React, probamos React Native (para iOS) y Redux. Creo que React fue un gran paso para el mundo JS en términos de conciencia del estado , y mostró a muchas personas lo que la programación funcional real es de una manera buena y pragmática. También creo que React Native es genial: literalmente cambia todo el panorama del desarrollo móvil.Reaccionar desventajas para mí:
A menudo, la limpieza, la inmunidad y la ideología dominan el enfoque pragmático.
No me malinterpretes. Aprecio la pureza y la simplicidad del enfoque render (); sin duda, esta es una gran idea que funciona en el desarrollo real. Estoy hablando de otras cosas.Creo que este nivel de rigor y limpieza puede ser útil cuando tienes 1,000 desarrolladores en tu empresa, casi al mismo tiempo que decides desarrollar tu propia sintaxis para traducir todo tu código PHP a tipos estáticos . O cuando eres un desarrollador de Haskell que decidió comprender JS. Pero la mayoría de las empresas tienen muchos menos desarrolladores, presupuestos más pequeños y objetivos que difieren de los objetivos de Facebook. Me detendré en esto con más detalle un poco más.JSX apesta
¡Espera un segundo! Lo se! Esto es "simplemente Javascript puro con sintaxis especial". Nuestros muchachos que dibujan un diseño en un boceto y un photoshop y luego lo convierten a HTML, que tienen plazos estrictos y que ahora hacen este formulario envolviéndolo en una serie de divisiones, en este momento, el tambor está limpio y es "simple" ES6. Aplicar algún diseño a los componentes React no es una fuente, porque JSX carece de legibilidad. La incapacidad de poner el IF viejo en algún bloque de código HTML es malo, y no confíe en los fanáticos de React que dicen que "if () es el siglo pasado, y ahora todos los programadores normales usan operadores ternarios". Permítame asegurarle: JSX sigue siendo una mezcla de HTML y JS en el momento en que lo lee y edita, incluso si luego se compila en JS puro.<ul>
{items.map(item =>
<li key={item.id}>{item.name}</li>
)}
</ul>
Muchos desarrolladores piensan (y estoy de acuerdo con ellos durante algún tiempo) que tales restricciones de sintaxis los harán más fuertes y los ayudarán a escribir más código modular, porque las limitaciones de JSX (listas para usar) lo obligan a colocar fragmentos de código en pequeñas funciones auxiliares y usarlos dentro funciones render (), como han sugerido este y muchos otros:stackoverflow.com/a/38231866/1132016JSX también te obliga a dividir componentes en 15 líneas HTML en 3 componentes, 5 líneas HTML en cada uno. No piense que este enfoque lo convierte en un mejor desarrollador.Aquí está la cosa:Cuando escribe un componente relativamente complejo, que probablemente no publicará en el rap público de GitHub mañana para demostrarlo en HackerNews, este enfoque de dividir componentes en componentes súper tontos debido a restricciones JSX siempre lo saca de la corriente, en que resuelves un problema comercial real. No, no estoy diciendo que la idea de los componentes fraccionales sea mala o no funcione. Debe tener claro que necesita dividir la funcionalidad en sus componentes para mantener su código en un estado controlado. Pero debe hacerlo sólo si usted piensa que esta entidad lógica particular en su código es mejor que ser un componente independiente con sus propios accesorios - y nopor cada dos o tres condiciones que se escribieron utilizando el operador ternario! Cada vez que crea un nuevo componente aquí y allá, le cuesta un esfuerzo muy específico e interrumpe su flujo., porque necesita cambiar del pensamiento del arquitecto (cuando ya recuerda el estado actual del modelo de componente y solo necesita agregar HTML aquí y allá para que la funcionalidad funcione) al pensamiento del gerente: necesita crear un archivo separado para el componente, piense en los accesorios de este nuevo componente cómo se asignan en el estado, cómo va a reenviar las devoluciones de llamada, etc. Como resultado, la velocidad de escritura del código se reduce, ya que tiene que dedicar esfuerzos a la modularidad prematura de los componentes donde probablemente no la necesitaría, si la sintaxis JSX fuera más flexible. En mi opinión, la modularidad prematura es muy similar a la optimización prematura. Para mí y para nuestro equipo, la legibilidad del código es importante, pero aún así es muy importante disfrutar escribiendo código. No es genialcuando una forma simple de calculadora requiere crear 6 componentes, cada uno con sus propios accesorios.A menudo, dicha hipermodularidad también es mala desde el punto de vista del mantenimiento, modificación o aplicación de un nuevo diseño, porque para actualizar el html en el widget, debe saltar varios archivos / funciones y verificar cada pequeño fragmento de HTML por separado.De nuevo, no propongo escribir monolitos. Sugiero usar componentes en lugar de microcomponentes para la programación diaria. Se trata de equilibrio y sentido común.Trabajar con formularios y Redux te hará imprimir todo el día
Reaccionar: se trata de limpieza y flujo unidireccional, ¿recuerdas? Es por eso que LinkedStateMixin se convirtió en una persona non grata., y ahora tiene que escribir 10 funciones para obtener información de 10 campos de formulario. No, por supuesto, puede escribir una función que verifique e.target, pero al final habrá un árbol de condiciones con la normalización de los datos que llegan desde el formulario que desea llorar; Por lo tanto, nadie hace eso. El 80% de estas funciones contendrá una línea con this.setState () o una llamada a la acción de Redux. (Entonces probablemente tendrá que crear 10 constantes más, una para cada acción). Creo que este enfoque sería aceptable si pudieras generar todo este código con solo pensarlo ... Pero no conozco ningún editor IDE que pueda simplificar en gran medida la redacción de este tipo de repeticiones. ¿Por qué deberías imprimir tanto? Porque los grandes decidieron que el enlace bidireccional es peligroso en aplicaciones de grandes empresas.Puedo confirmar que la unión bidireccional a veces no es tan simple y no tan legible, pero la mayoría de estos temores están relacionados con el sufrimiento general de las personas de la primera versión de Angular, donde la unión bidireccional puede no ser la mejor. Y sin embargo ... probablemente este no fue el mayor error de cálculo, incluso en Angular. Mire mi editor rápido, que recientemente me harté de Vue.js para nuestra plataforma Drupal (me disculpo de antemano por el diseño, este es el backend de la interfaz de usuario para nuestros operadores, y los diseñadores están ocupados creando interfaces para nuestros clientes, por lo que esta funcionalidad está esperando por su horas para volverse bella):Probablemente no fue el mayor error de cálculo, incluso en Angular. Mire mi editor rápido, que recientemente me harté de Vue.js para nuestra plataforma Drupal (me disculpo de antemano por el diseño, este es el backend de la interfaz de usuario para nuestros operadores, y los diseñadores están ocupados creando interfaces para nuestros clientes, por lo que esta funcionalidad está esperando por su horas para volverse bella):Probablemente no fue el mayor error de cálculo, incluso en Angular. Mire mi editor rápido, que recientemente me harté de Vue.js para nuestra plataforma Drupal (me disculpo de antemano por el diseño, este es el backend de la interfaz de usuario para nuestros operadores, y los diseñadores están ocupados creando interfaces para nuestros clientes, por lo que esta funcionalidad está esperando por su horas para volverse bella):
No puedo mostrar el código por razones obvias, pero escribirlo en Vue fue muy agradable, y el código era muy legible. Y sé con certeza que si escribiera una función separada para cada campo del formulario, como en React, ciertamente no saltaría de la felicidad.Redux también es detallado y requiere mucha escritura . Y en Internet, es fácil encontrar declaraciones de desarrolladores que acusan a Mobx de convertir React en Angular solo porque Mobx usa el enlace de datos bidireccional (consulte la cláusula # 1 sobre "limpieza"). Parece que muchas personas inteligentes valoran la "limpieza" de su código más que la tarea comercial rápida y bien resuelta (que, en principio, es normal si no tiene plazos).Al mismo tiempo, considero que el concepto Flux / Redux en sí mismo es muy bueno. Redux es simple y proporciona un nivel increíble de control sobre el estado de la aplicación, y separa el estado de las piezas de la interfaz, lo que facilita inmediatamente la escritura de pruebas. Pero, desafortunadamente, todo esto está dado por una gran cantidad de garabatos. Sí, la depuración del viaje en el tiempo como efecto secundario es increíble. Pero personalmente, estoy listo para sacrificarlo por el bien de la escritura de códigos de alta velocidad, y pensar si necesita viajar en el tiempo si necesita encontrar una constante para cada campo en el formulario.Exceso excesivo en herramientas
React funciona con el alcance original en Babel. No creará una aplicación React real sin un paquete decente de paquetes npm, comenzando con el compilador ES5. Una aplicación simple basada en la compilación inicial oficial en la carga recibe aproximadamente 75 MB de código JS en node_modules. Esto no es algo crítico y se relaciona más con el mundo JS en general que con React, pero aún agrega frustración y molestia.Mi veredicto de reacción: le permite escribir un gran código legible, pero escribirlo mucho no es divertido. Bueno, los problemas para los diseñadores de diseño que no poseen y no desean tener ES6 dentro de HTML, no desaparecen.Angular 1: demasiada libertad también es mala
Angular 1 es un buen marco para su tiempo, ubicado en la esquina opuesta (de React) de un mapa JS imaginario de limpieza y legibilidad del código. Angular le permite comenzar rápidamente, le permite disfrutar escribiendo las primeras 1k líneas de código, y luego prácticamente le hace escribir código que no funciona muy bien. Es probable que se pierda en directivas, ámbitos y flujos de datos bidireccionales que penetran en todas las capas de su aplicación, será el acorde final de la canción de cisne de su código, que los desarrolladores recién contratados ni siquiera querrán tocar, porque algo se romperá. ¿Por qué está pasando esto? Angular.js se creó en 2009, cuando el mundo del desarrollo front-end parecía bastante simple y nadie pensó en un buen control sobre el estado de la aplicación. No debería culpar a los autores: simplemente hicieron un competidor para Backbone con algunos chips nuevos y querían imprimir menos (y lo hicieron todo, otra pregunta a qué costo).Angular2
Simplemente cree una aplicación hello-world y observe la cantidad de archivos que terminan en el nabo. Tendré que usar Typecript (y no estoy 100% seguro de lo que quiero hacer todos los días; no, muchachos, la escritura estática en JS no es una panacea, pero una vez más tendré que imprimir, buenos pensamientos de Eric Eliott sobre este tema) y compiladores para comenzar. Esto fue suficiente para posponer Angular2 hasta tiempos mejores. Soy perezoso, y para mí es demasiado repetitivo antes de comenzar a escribir código real. En mi opinión, los autores de Angular 2 están tratando de construir un sistema ideal para una empresa que derrotará a React, en lugar de tratar de construir un marco que resuelva los problemas comerciales para un usuario promedio y común. Tal vez estoy equivocado y mi opinión puede cambiar: al final no tengo mucha experiencia en Angular2, al final creamos una aplicación de calculadora de prueba. Una maravillosa página de comparación en Vue.js llama a Angular2 un buen sistema, que tiene muchas ideas en común con Vue.js.Vue.js
Vue.js es algo que he estado esperando durante mucho tiempo (en adelante hablaré sobre Vue.js 2, que recibió muchas mejoras en comparación con la primera versión de Vue, y esta es la versión estable actual del sistema). Para mí, en términos de elegancia y concisión, además de centrarse en soluciones a problemas del mundo real, Vue.js es el mayor avance en JS desde el día en que Jquery me llamó la atención en 2007. Si miras los gráficos de la popularidad de Vue.js, entonces note que este año no solo me complació a mí:On Vue Github - Top 1 JS project of 2016 (entre nabos con códigos fuente).Por popularidad en Google Trends, Vue.js en 2016 superó notablemente a React (por supuesto, esta es la temperatura promedio en un hospital muy grande y depende en gran medida de la solicitud formulada, un signo muy indirecto de popularidad).https://www.google.com/trends/explore?q=vue.js,react.js,angular.jsVue.js es uno de los de más rápido crecimiento (en términos de la comunidad o al menos el número de me gusta en el github y usuarios de Vue Dev Tools en Chrome) JS en 2016, y estoy seguro de que esta no es solo otra biblioteca de moda para los hipsters que cambian a un nuevo marco JS cada 3 meses, o el trabajo del departamento de relaciones públicas es muy importante empresaLaravel ha agregado Vue.js al kernel, y este es un reclamo serio.Pros de Vue.js
Vue.js mantiene un excelente equilibrio entre legibilidad, facilidad de mantenimiento del código y el placer de escribir este código. Este equilibrio se encuentra a una distancia aproximadamente equidistante entre React y Angular 1, y si observa la directriz vue.js, notará de inmediato cuántas ideas útiles tomó de estos sistemas.De React Vue.js tomé el enfoque de componentes, accesorios, un flujo de datos unidireccional para la jerarquía de componentes, el rendimiento, la capacidad de renderizar en el back-end y la importancia de una gestión de estado adecuada. Vue.js tomó de Angular1 plantillas similares con buena sintaxis y enlace bidireccional, pero solo donde realmente lo necesita y no le permitirá disparar inmediatamente su pierna (dentro de un componente). Es muy fácil comenzar a escribir código en Vue.js. Vi esto en nuestro equipo. Vue.js no requiere ningún compilador predeterminado, por lo que es muy fácil agregar Vue.js a su base de código heredada y comenzar a copiar jQuery hash en código legible.La cantidad correcta de magia
Vue.js es muy simple de trabajar tanto en términos del enfoque centrado en HTML como desde el punto de vista de los desarrolladores de JS: puede crear plantillas bastante complejas sin perder el foco en la tarea empresarial, y la plantilla HTML resultante generalmente se lee bien incluso cuando Él ya es grande. En este momento, por regla general, ha logrado un buen progreso en la resolución del problema comercial y es posible que desee reorganizar las plantillas y dividirlas en componentes más pequeños; en este momento, ve la "imagen" completa de su aplicación mucho mejor que al principio. Mi experiencia muestra que esto es significativamente diferente del enfoque que suelen usar los programadores de React, y esta diferencia ahorra mucho tiempo y esfuerzo para los programadores que usan Vue.js. En React te ves obligado adivida los componentes en microcomponentes y microfunciones justo en el momento de escribir la versión inicial "borrador" del código, de lo contrario quedará literalmente enterrado en una mezcla de llaves y HTML entre ellos. En React, paso mucho tiempo puliendo accesorios y refactorizando componentes súper pequeños (que, por supuesto, nunca se reutilizarán) una y otra vez, porque no lo veo tan claramente cuando de repente necesito cambiar la lógica del código en el medio del proceso.Formas
Trabajar con formularios HTML en Vue.js es un placer. Aquí es donde realmente ayuda la unión a doble cara. Incluso en casos difíciles, no hay problema, aunque a primera vista los observadores pueden parecerse a Angular 1. Un flujo de datos unidireccional siempre está a su servicio cuando divide componentes.Tecnología
Si desea compilación, linting, PostCSS y ES6 no son un problema . Los componentes de un solo archivo parecen estar convirtiéndose en la principal forma de escribir componentes públicos en Vue.js 2. Por cierto, la idea de que Scoped CSS funcione en componentes de un solo archivo es lo que se ve realmente bien y puede reducir la necesidad de reglas estrictas de nomenclatura CSS clases y tecnologías como BEM .Gestión del estado
Vue.js tiene una administración de estado bastante simple y útil a través de los métodos data () y props (): funcionan bien en el desarrollo real. Si el alma pide algo más para la gestión del estado, está Vuex (que, en mi opinión, es similar a Mobx en React; el estado es mutable allí). Creo que un buen porcentaje de las aplicaciones de Vue.js no necesitarán administración de estado a través de Vuex, pero es bueno tener una alternativa.Rendimiento
El tema es holístico, en general, ambos reaccionan y vue.js son rápidos. Pero, sin embargo, aparentemente, vue.js en promedio es notablemente más rápido.Un enlace maravilloso de los comentarios sobre TodoMVC con mediciones:eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#Y aquí hay cuentas más detalladas (de la parte interesada, sin embargo) .Otra comparación de referencia detallada e inteligible:stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.htmlContras VueJS
Errores de plantilla de tiempo de ejecución
Mayor: errores de tiempo de ejecución desagradables en las plantillas. Víctima por la conveniencia de escribir código. Esto es muy similar a Angular 1. Vue.js logra generar muchas advertencias útiles para el código JS: por ejemplo, hay advertencias cuando intentas mutar los accesorios o usar el método data () incorrectamente, la influencia positiva de React es muy notable aquí. Pero los errores de plantilla en tiempo de ejecución siguen siendo la debilidad de Vue.js. Las trazas de la pila de excepciones a menudo son inútiles y conducen a los métodos internos de Vue.js. En este caso, en esta clase de errores y depuración, JSX es a menudo más agradable: debido a la compilación "de JS a JS", al hacer clic en un error en la consola del navegador generalmente se llega exactamente al lugar donde se produjo este error en el código.Bibliotecas
La infraestructura de Vue.js todavía es bastante joven. De hecho, los componentes estables de la comunidad se pueden contar con los dedos, y muchos de ellos se crearon para Vue.js 1, y a menudo no es tan fácil para los principiantes descubrir para qué versión de Vue.js está diseñada una biblioteca en particular. Este problema se mitiga por el hecho de que puede hacer cosas interesantes en Vue.js sin experimentar mucha necesidad de bibliotecas de terceros. Probablemente solo necesite una biblioteca para las solicitudes de Ajax ( vue-resource sería una buena opción si no le interesan las aplicaciones isomorfas, de lo contrario Axios ) y probablemente Vue-router, que se considera una biblioteca con un buen soporte de Vue.js.Comunidad de habla no inglesa
Comentarios chinos en el código de la mayoría de los repositorios públicos, y esto no es sorprendente: Vue.js se está convirtiendo en una solución muy popular en China (Vue.js habla chino)Proyecto de una persona.
Más bien, es un problema potencial que uno real, pero a veces quieres ir a lo seguro. Evan You es el tipo que creó Vue después de trabajar en Google y Meteor. Laravel, por supuesto, también es un proyecto para un solo hombre, pero aún así tiene mucho éxito, ¿verdad?Vue.js en Drupal
Disclaimer: Drupal 8 Qwintry, , PHP Node.js , legacy – Drupal. qwintry.com Drupal, Vue.js . , , , -, , , , . , Vue Drupal: , - , . JSON API – , . , REST API Saas , , - , . . , 2010 Ajax Drupal. , Drupal , - Ajax – . , , ctools_wizard_multistep_form (), ,
ajax_render !Al mismo tiempo, estos requisitos de las interfaces modernas impulsan a estos desarrolladores, pero la complejidad de la infraestructura moderna de JS los está llevando a una depresión. Sí, me reconozco hace un año. Entonces chicos, escúchenme! No encontrará un mejor momento y forma de mejorar sus interfaces que ahora tome Vue.js, colóquelo en sitios / todas / bibliotecas, agréguelo con drupal_add_js () a la plantilla y comience a escribir código. Te sorprenderá lo fácil que es mantener un sistema en el que Drupal solo es responsable del JSON generado cuando todo el código del cliente, incluidos los formularios, está totalmente alimentado por Vue.js.Vue.js en Yii2
Dato curioso: Yii fue creado por el desarrollador chino Qiang Xue. Por lo tanto, uno puede llamar a Yii + Vue.js una pila no solo una pila, cuyo nombre es casi imposible de pronunciar en el primer intento, sino también una pila con herencia china (en el buen sentido). Para la nueva versión de Qwintry.com (aún no publicada), elegimos Yii2, que, en mi opinión, es uno de los mejores y más rápidos frameworks PHP. Definitivamente no es tan popular como Laravel, que ha tomado la delantera en el mundo de PHP, pero la pila Yii2 está bastante bien con nosotros.(aunque miramos a Laravel de vez en cuando, los desarrolladores allí están aprovechando y, por supuesto, hay una infraestructura más madura en términos de bibliotecas). Estamos reduciendo gradualmente la cantidad de HTML que generan Yii2 y PHP, centrándonos más en la API REST, que genera JSON para el lado del cliente, ejecutándose en Vue.js / Swift / Java. El enfoque API-first se usa para la mayoría de nuestros modelos de Active Record en el proyecto. Aquí ya nos tomamos en serio la API y es por eso que pasamos mucho tiempo en una buena documentación de la API, incluso si esta API no es pública. En las secciones de código donde la parte HTML se genera a nivel PHP, usamos nuestras propias soluciones y paquete web para agrupar y desplegar convenientemente widgets Yii2, que, a su vez, usan componentes de un solo archivo Vue. Con PHP7 y la última versión de MySQL, el tiempo de respuesta de nuestro backend Yii2 JSON no es muy diferente del Nodo.js backends (estoy hablando de una velocidad de respuesta del orden de 15-20 ms), francamente, estas no son cifras cósmicas, pero esto es más que suficiente para nuestras necesidades y, lo más importante, es 10-20 veces más rápido de lo que puede dar nuestro antiguo sitio de Drupal. Al mismo tiempo, este es un buen PHP antiguo (y aburrido, tal vez) con toda la fuerza de las bibliotecas de compositores y una base de código estable. La capacidad de respuesta de las interfaces creadas en Yii2 y Vue.js es muy aceptable y, desde el punto de vista de la legibilidad del código, todo está en orden aquí también.La capacidad de respuesta de las interfaces creadas en Yii2 y Vue.js es muy aceptable y, desde el punto de vista de la legibilidad del código, todo está en orden aquí también.La capacidad de respuesta de las interfaces creadas en Yii2 y Vue.js es muy aceptable y, desde el punto de vista de la legibilidad del código, todo está en orden aquí también.También usamos Vue.js en varios proyectos internos y externos, donde el backend se ejecuta en Node.js. No agregaré nada nuevo a lo anterior, todo funciona bien.Conclusión
Hemos estado escribiendo código Vue.js todos los días durante aproximadamente 4 meses en varios proyectos, y los resultados son impresionantes. 4 meses no es nada en el mundo del backend, pero para el mundo JS este es un período decente para el que nacen y mueren cinco marcos :) Veamos qué sucede a continuación. Creo que Vue.js será la solución principal para JS en los próximos 16-24 meses si Evan You toma los pasos correctos, al menos entre los equipos de back-end y front-end pequeños. La pila React se generalizará en 2017, especialmente si React Native continúa creciendo y mejorando al mismo ritmo que ahora.UPD: En este artículo se golpeó las HackerNews superiores, y no se produjo una discusión útil (de 250 comentarios): news.ycombinator.com/item?id=13151317En la parte superior Reddit Webdev también visitamos, más de 60 comentarios aquí. Divertido comentario-opinión sobre Angular2 a partir de ahí:Toda la documentación de Google es como leer documentos de Microsoft de principios de la década de 2000.
"¡Crear un proyecto angular es pan comido! Solo asegúrese de que el mutante prototipo de referencia sin estado herede del objeto heredado del cargador de memoria base que implementa el proveedor de servicios MODOK (no es parte del núcleo: consulte aquí para obtener detalles igualmente ilegibles). Entonces estará listo para compilar su núcleo Angular, teniendo cuidado de usar Webpack 2.3.9 (nota: no 2.3.8 como se suministra con el repositorio). Esto es todo lo que necesita saber para comenzar un gran proyecto angular. Angular: ¡hacer que el desarrollo sea simple y divertido de nuevo! ”
Preguntas de los lectores:
JSX es genial y correcto, ¡pero no eres muy! Si realmente quieres condiciones, ¡programa tu componente If, estas son tres líneas!Es desagradable elegir un marco, y luego hacer tales cosas en su contra, cada nuevo desarrollador que ingrese al proyecto le preguntará acerca de tales decisiones, y en los componentes de otras personas sus ojos siempre tropezarán con ternura.Además, si el componente escrito "frente" tendrá problemas porque los componentes internos siempre se ejecutan. Pero hay soluciones más interesantes: github.com/AlexGilleran/jsx-control-statementsEntonces, ¿qué sugieres, querida, ahora necesitas abandonar urgentemente Reaccionar y reescribir todo a Vue.js?No no React es un marco excelente, y le permite escribir código legible y compatible, y también se ha escrito una gran cantidad de bibliotecas de alta calidad (y los microcomponentes y las limitaciones de JSX, que "regañé" anteriormente, juegan un papel positivo aquí, para las bibliotecas públicas esto es ya a menudo justificado), que no son para ninguna otra solución JS. Si usted y su equipo están contentos con todo en JSX y no se molestan en escribir mucho, tal vez no tenga sentido cambiar a Vue.js, el juego simplemente no vale la pena. Muchos amantes de JS recientemente han estado amando saltar de un marco a otro. No lo abuse, en mi opinión, es mejor pasar este tiempo en algo más interesante que los usuarios de su proyecto notarán.Pero si no puede comenzar a usar React debido a herramientas masivas y otras dificultades, y su código se encuentra con jQuery o Backbone mess, Vue.js puede ser una gran opción, no académica, simple y concisa.No leí todo el artículo, pero en el titular dijiste algo negativo sobre la inmunidad, ¡probablemente no eres ortodoxo debido a tu inexperiencia y estupidez, no entiendes lo grandioso que es un enfoque funcional!Separemos la inmunidad como un paradigma funcional (respetamos mucho el enfoque funcional, el concepto de inmunidad y la pureza de las funciones) y el estado actual del mundo JS y sus bibliotecas. Si un desarrollador, después de leer el blog de Facebook, felizmente toma Immutable.js y lo pone en producción, y luego se da cuenta de que no tiene un muy buen muelle, Lodash y todo el resto del código escrito por la generación anterior de desarrolladores no trabajan con él (sí, estoy al tanto sobre envoltorios inmutables alrededor de lodash, gracias), y por lo tanto el desarrollador no cumple con la fecha límite; esto significa que el desarrollador no compró el paradigma funcional, sino más bien la exageración en torno a la biblioteca específica. No piense que si Facebook tiene problemas reales que resuelven usando Immutable.js, esto significa que tendrá problemas de un orden similar en su página de destino o SPA.Lo más probable es que no, más biensus inversores se quedarán sin dinero, necesitará implementar funciones de trabajo lo más rápido posible, y es suficiente para que el código sea normal y no mute donde no es necesario, no necesita usar Immutable.js para esto (lea la opinión sobre Immutable.js, por ejemplo, aquí ). Por separado, noto que una gran cantidad de desarrolladores de JS, cuyas opiniones vi como la principal característica asesina de Immutable.js, no se llaman pureza y confiabilidad del código resultante, sino ¡atención! - aumento de la productividad (estamos hablando de comparaciones rápidas de estructuras)! Algo en este mundo está mal si las personas están empujando una pieza funcional de este nivel en aras de un mejor rendimiento en su proyecto. Parece que la moda ha vuelto a intervenir ...Si desea simplificar su vida, simplemente deje de mutar su condición, cambie a accesorios, y estas cosas simples mejorarán su vida en este momento.