JavaScript robusto: persiguiendo un mito

JavaScript a menudo se llama el "lenguaje m谩s popular", pero parece que nadie habla del desarrollo de JS como "el m谩s seguro", y la cantidad de problemas al acecho en el ecosistema es grande. 驴C贸mo sortearlos de manera efectiva?



Ilya Klimov pens贸 en esto cuando el error fue muy costoso (literalmente), y como resultado hizo una presentaci贸n en HolyJS. Y dado que las opiniones de la audiencia resultaron ser excelentes, ahora hemos preparado una versi贸n de texto de este informe para Habr. Debajo del corte, tanto texto como video.



Hola a todos Mi nombre es Ilya Klimov, soy de Jarkov, Ucrania. Tengo mi propia empresa de outsourcing peque帽a, de hasta diez personas. Hacemos todo por lo que se paga dinero ... en el sentido, programamos en JavaScript en todos los sectores. Hoy, hablando de JavaScript confiable, quiero compartir mis mejores pr谩cticas en alg煤n lugar durante el a帽o pasado, ya que este tema comenz贸 a molestarme bastante en serio.

Quienes trabajan en outsourcing comprender谩n el contenido de la siguiente diapositiva:



Todo lo que hablaremos, por supuesto, no tiene nada que ver con la realidad. Como dicen en South Park, todos los personajes est谩n mimados y son miserables. Naturalmente, aquellos lugares donde hay una sospecha de violaci贸n de la NDA se acordaron con representantes de los clientes.

Nada afect贸 mis pensamientos sobre la fiabilidad y similares como la base de mi propia empresa. Cuando comienzas tu propia compa帽铆a, de repente resulta que puedes ser un programador genial, puedes tener muchachos geniales, pero a veces suceden cosas incre铆bles, un par de cosas imposibles y completamente locas.

Tengo un proyecto educativo Ninja JavaScript. A veces hago promesas. A veces incluso los sigo. Promet铆 en 2017, como parte de un proyecto educativo, grabar un video sobre Kubernetes. Me di cuenta de que hab铆a hecho esta promesa y ser铆a bueno cumplirla el 31 de diciembre. Y me sent茅 a grabar ( aqu铆 est谩 el resultado ).

Como me gusta grabar videos lo m谩s cerca posible de la realidad, aprovech茅 ejemplos de un proyecto real. Como resultado, en el cl煤ster de demostraci贸n, implement茅 una cosa que tom贸 贸rdenes reales de producci贸n real y las puse en una base de datos de Kubernetes separada en mi cl煤ster de demostraci贸n.

Como era el 31 de diciembre, parte de las 贸rdenes desaparecieron. Desestimado por estacionalidad: todos fueron a tomar el t茅. Cuando el cliente se despert贸 alrededor del 12 al 13 de enero, el costo total del video fue de aproximadamente $ 500,000. Todav铆a no he tenido una producci贸n tan costosa.



Ejemplo n煤mero dos: otro cl煤ster de Kubernetes. Infraestructura del ecosistema de nueva moda como un c贸digo: todo lo que pueda se describe mediante c贸digo y configuraciones, Kubernetes se contrae program谩ticamente desde los shells de JavaScript, etc. Genial, a todos les gusta. Un peque帽o cambio en el procedimiento de implementaci贸n, y llega un momento en el que necesita implementar un nuevo cl煤ster. Surge la siguiente situaci贸n:

const config = { // 鈥 mysql: process.env.MYSQL_URI || 'mysql://localhost:3306/foo' // ... } 

Muchos de ustedes probablemente tambi茅n tengan esta l铆nea de c贸digo en sus configuraciones. Es decir, tomamos la configuraci贸n de la variable mysql o tomamos la base de datos local.

Debido a un error tipogr谩fico en el sistema de implementaci贸n, result贸 que el sistema se configur贸 nuevamente como producci贸n, pero la base de datos MySQL utiliz贸 una base de datos de prueba, local, que era para pruebas. Esta vez se gast贸 menos dinero, solo $ 300,000. Afortunadamente, esta no era mi empresa, sino el lugar donde trabajaba como consultor comprometido.



Puede pensar que todo esto no le concierne como front-end, porque habl茅 sobre DevOps (por cierto, admiro el nombre de la conferencia DevOops , describe la esencia perfectamente). Pero te contar茅 sobre otra situaci贸n.

Hay un sistema que controla las epidemias veterinarias en Etiop铆a, desarrollado bajo los auspicios de la ONU. Contiene uno de los elementos de la interfaz cuando se trata de una persona, y 茅l ingresa manualmente las coordenadas: cu谩ndo y d贸nde hubo brotes de una determinada enfermedad.

Hay un brote de fiebre aftosa regular (no soy fuerte en las enfermedades de las vacas), y el operador presiona accidentalmente el bot贸n "agregar" dos veces, dejando los campos vac铆os. Como tenemos JavaScript, y JavaScript y los tipos son muy buenos, los campos vac铆os de latitud y longitud con alegr铆a conducen a coordenadas cero.

No, no enviamos al m茅dico lejos al oc茅ano, pero result贸 que todo esto se calcul贸 previamente desde el punto de vista de la agrupaci贸n para mostrar en el mapa, generar informes, an谩lisis, analizar la ubicaci贸n de las personas en el backend. Estamos tratando de unir los puntos de estallido.

Como resultado, el sistema se paraliza durante el d铆a, ya que el backend est谩 tratando de calcular el cl煤ster con la inclusi贸n de este punto, todos los datos se vuelven irrelevantes, las 贸rdenes completamente irresponsables de la serie "drive 400 kilometros" llegan a los m茅dicos. 400 kil贸metros en Etiop铆a es un placer dudoso.

La p茅rdida total estimada es de aproximadamente un mill贸n de d贸lares. En el informe sobre esta situaci贸n estaba escrito "Fuimos v铆ctimas de un conjunto desafortunado de circunstancias". 隆Pero sabemos que el punto es JavaScript!



Y el 煤ltimo ejemplo. Desafortunadamente, aunque esta historia fue hace mucho tiempo, todav铆a no puedo nombrar la compa帽铆a. Pero esta es una compa帽铆a que tiene su propia aerol铆nea, sus propios hoteles, etc. Ella trabaja muy interactivamente con las empresas, es decir, les proporciona una interfaz separada para reservar boletos, etc.

Una vez que ocurri贸 un accidente absurdo, llega una orden para reservar boletos de Nueva York a Los 脕ngeles por un monto de 999,999 piezas. El sistema de la compa帽铆a compr贸 felizmente todos los vuelos de su propia aerol铆nea, descubri贸 que no hab铆a suficientes asientos y envi贸 los datos al sistema internacional de reservas para compensar la escasez. El sistema de reserva internacional, al ver una solicitud de aproximadamente 950,000 boletos, desconect贸 felizmente a esta aerol铆nea de su sistema.

Dado que el cierre es un evento fuera de lo com煤n, el problema se resolvi贸 en siete minutos. Sin embargo, en estos siete minutos, el costo de las multas que tuvieron que pagar fue de solo $ 100,000.



Afortunadamente, todo esto sucedi贸 en m谩s de un a帽o. Pero estos casos me hicieron pensar en problemas de fiabilidad y hacer dos preguntas originales en ruso: 驴qui茅n tiene la culpa y qu茅 hacer al respecto?

Por qu茅 sucede esto: la juventud del ecosistema


Si analiza muchas historias, encontrar谩 que hay m谩s historias sobre problemas similares con JavaScript que con otro lenguaje de programaci贸n. Esta no es mi impresi贸n subjetiva, sino los resultados del an谩lisis inteligente de las noticias en Hacker News. Por un lado, esta es una fuente hipster y subjetiva, pero, por otro lado, es bastante dif铆cil encontrar una fuente sensata por fakap en el campo de la programaci贸n.

Adem谩s, hace un a帽o realic茅 una competencia donde ten铆a que resolver problemas algor铆tmicos todos los d铆as. Como estaba aburrido, los resolv铆 en JavaScript usando programaci贸n funcional. Escrib铆 una funci贸n completamente pura, y en el Chrome actual, funcion贸 correctamente 1197 veces, y 3 veces produjo un resultado diferente. Fue solo un peque帽o error en el optimizador TurboFan, que acaba de ingresar al Chrome principal.

Por supuesto, se solucion贸, pero usted comprende: esto significa, por ejemplo, que si sus pruebas unitarias pasaron una vez, esto no significa en absoluto que funcionar谩n en el sistema. Es decir, ejecutamos c贸digo aproximadamente 1197 veces, luego vino el optimizador y dijo: 鈥溌uau! Caracter铆stica caliente! Optimic茅moslo ". Y en el proceso de optimizaci贸n llev贸 al resultado incorrecto.

En otras palabras, podemos llamar a la juventud del ecosistema una de las primeras razones por las que esto sucede. JavaScript es una industria bastante joven precisamente en el campo de la programaci贸n seria, en los casos en que giran millones, donde el costo de un error se mide entre cinco y seis caracteres.

Durante mucho tiempo, JavaScript fue percibido como un juguete. Debido a esto (no porque no nos lo tomemos en serio), todav铆a tenemos problemas con la falta de herramientas.

Por lo tanto, para abordar esta raz贸n, que es el principio fundamental fundamental de todo lo que hablar茅 hoy, trat茅 de formular las reglas de confiabilidad que podr铆a imponer en mi empresa o transferir como consultor a otros. Como dice el refr谩n, "la regla n煤mero uno es no hablar de confiabilidad". Pero m谩s en serio, entonces ...

Regla de confiabilidad n. 掳 1: todo lo que se puede automatizar debe automatizarse


Incluyendo, por cierto, y la correcci贸n ortogr谩fica:

Texto oculto
Regla de confiabilidad n. 掳 1: todo lo que se puede automatizar debe automatizarse

Todo comienza con las cosas m谩s simples. Parece que todos han estado escribiendo Prettier durante mucho tiempo. Pero solo en 2018, esto que todos usamos, bueno y s贸lido, aprendi贸 a trabajar con git add -p cuando agregamos parcialmente archivos al repositorio de git, y queremos formatear bien el c贸digo, por ejemplo, antes de enviarlo al repositorio principal. La utilidad realinstaged bastante conocida, que le permite verificar solo aquellos archivos que han sido modificados, tiene exactamente el mismo problema.



Continuar jugando Captain Evidence: ESLint. No preguntar茅 qui茅n lo usa aqu铆, porque no tiene sentido que toda la audiencia levante la mano (bueno, eso espero y no quiero decepcionarme). Mejor levante la mano, ya que tienen sus propias reglas escritas personalizadas en ESLint.

Dichas reglas son una de las formas muy poderosas de automatizar el desorden que ocurre en los proyectos donde las personas escriben en el nivel junior y similares.

Todos queremos un cierto nivel de aislamiento, pero tarde o temprano surge una situaci贸n: 鈥淢ira, este ayudante Vasya vendi贸 muy cerca en el directorio de su componente. No lo sacar茅 en com煤n, entonces lo har茅 鈥. La palabra m谩gica es "m谩s tarde". Esto lleva al hecho de que no comienzan a aparecer dependencias verticales en el proyecto (cuando los elementos superiores conectan a los inferiores, los inferiores nunca trepan detr谩s de los superiores), pero el componente A depende del componente B, que se encuentra en una rama completamente diferente. Como resultado, el componente A no se transporta tan f谩cilmente a otros componentes.

Por cierto, expreso mi respeto por Alfa-Bank, tienen una biblioteca de componentes muy bien escrita en React, es un placer usarla precisamente en t茅rminos de dise帽o de la calidad del c贸digo.

La regla banal de ESLint, que realiza un seguimiento de d贸nde importa las entidades, le permite aumentar significativamente la calidad del c贸digo y guardar el modelo mental durante la revisi贸n del c贸digo.

Ya estoy desde el punto de vista del mundo de los front-end de edad. Recientemente, en la regi贸n de Kharkov, una compa帽铆a grande y seria, PricewaterhouseCoopers, ha completado un estudio, y la edad promedio del proveedor es de 24 a 25 a帽os. Ya es dif铆cil para m铆 pensar en todo esto, quiero centrarme en la l贸gica empresarial durante una revisi贸n de solicitud de extracci贸n. Por lo tanto, me complace escribir las reglas de ESLint para no pensar en tales cosas.

Parece que puede ajustar las reglas habituales para esto, pero la realidad generalmente molesta mucho m谩s, porque resulta que se necesitan algunos selectores de Redux desde el componente de reacci贸n (desafortunadamente, todav铆a est谩 vivo). Y estos selectores est谩n en alg煤n lugar en una jerarqu铆a completamente diferente, as铆 que "../../../ ..".

O, peor a煤n, el alias de paquete web, que rompe aproximadamente el 20% de otras herramientas, porque no todos entienden c贸mo trabajar con 茅l. Por ejemplo, mi amado Flow.

Por lo tanto, la pr贸xima vez antes de querer gru帽ir en un junior (y el programador tiene un pasatiempo favorito), piense si de alguna manera puede automatizar esto para no cometer errores en el futuro. En un mundo ideal, por supuesto, escribir谩s instrucciones que nadie leer谩 de todos modos. Aqu铆 est谩n los oradores de HolyJS, especialistas talentosos con gran experiencia, pero cuando se propuso elaborar las instrucciones para los oradores en un mitin interno, dijeron "s铆, no lo leer谩n". 隆Y estas son las personas para tomar un ejemplo!

Lo 煤ltimo del banalismo, y pasar al esta帽o. Estas son herramientas para ejecutar ganchos de precompromiso. Usamos husky , y no pude evitar insertar esta hermosa foto de husky, pero puedes usar otra cosa.



Si crees que todo esto es muy simple, como dicen, espera mi cerveza, pronto descubriremos que todo es m谩s complicado de lo que piensas. Algunos puntos m谩s:

Escribiendo


Si no est谩 escribiendo TypeScript, es posible que desee pensarlo. No me gusta TypeScript, tradicionalmente flujo de alto flujo, pero hablaremos de esto m谩s adelante, pero aqu铆 desde la etapa promocionar茅 la soluci贸n convencional con disgusto.

Por qu茅 El comit茅 del programa TC39 recientemente tuvo una gran discusi贸n sobre hacia d贸nde va generalmente el idioma. Llegaron a una conclusi贸n muy divertida: en TC39 siempre hay un "cisne, c谩ncer y lucio", que arrastran la lengua en diferentes direcciones, pero hay una cosa que todos quieren y siempre es el rendimiento.

TC39 extraoficialmente, en una discusi贸n interna, emiti贸 esta diatriba: "Siempre haremos JavaScript para que siga siendo productivo, y aquellos a quienes no les guste tomar谩n un lenguaje que se compila en JavaScript".

TypeScript es una muy buena alternativa al ecosistema adulto. No puedo dejar de mencionar mi amor por GraphQL. Es realmente bueno, desafortunadamente, nadie permitir谩 que se implemente en una gran cantidad de proyectos existentes donde ya tenemos que trabajar.



Ya hubo informes sobre GraphQL en la conferencia, por lo tanto, solo hay un golpe espec铆fico para la cuesti贸n de la confiabilidad: si usa, por ejemplo, Express GraphQL, cada vez que adem谩s de un resolutor espec铆fico puede colgar ciertos validadores que le permiten ajustar los requisitos de valor en comparaci贸n con tipos est谩ndar de GraphQL.

Por ejemplo, me gustar铆a que el monto de la transferencia entre dos representantes de algunos bancos sea positivo. Porque a m谩s tardar ayer, la ventana emergente en mi banca por Internet anunci贸 alegremente que ten铆a -2 mensajes no le铆dos del banco. Y es como un banco l铆der en mi pa铆s.

En cuanto a estos validadores, que imponen un rigor adicional: usarlos es una buena y buena idea, simplemente no los use como sugiere, por ejemplo, GraphQL. Te encuentras muy apegado a GraphQL como plataforma. Al mismo tiempo, la validaci贸n que usted hace es necesaria en dos lugares al mismo tiempo: en el frontend antes de enviar y recibir datos, y en el backend.

Regularmente tengo que explicarle al cliente por qu茅 tomamos JavaScript y no el lenguaje X como back-end. Adem谩s, el lenguaje X suele ser alg煤n tipo de PHP, y no hermoso Go y similares. Debo explicar que podemos reutilizar el c贸digo de la manera m谩s eficiente posible, incluso entre el cliente y el servidor, debido al hecho de que est谩n escritos en el mismo lenguaje de programaci贸n. Desafortunadamente, como muestra la pr谩ctica, a menudo esta tesis sigue siendo solo una frase en la conferencia y no encuentra encarnaci贸n en la vida real.

Contratos


Ya he hablado sobre la juventud del ecosistema. La programaci贸n por contrato ha existido por m谩s de 25 a帽os como un enfoque principal. Si escribe en TypeScript, tome io-ts, si escribe en Flow, como yo, tome el contrato escrito, y obtendr谩 una cosa muy importante: la capacidad de describir contratos de tiempo de ejecuci贸n de los cuales derivar tipos est谩ticos.



No hay peor para un programador que tener m谩s de una fuente de verdad. Conozco personas que perdieron cantidades de cinco d铆gitos en d贸lares simplemente porque su tipo se describe en un lenguaje con tipeo est谩tico (usaron TypeScript; bueno, por supuesto, esto es solo una coincidencia) y el tipo de tiempo de ejecuci贸n (parece haber usado tcomb ) Un poco diferente.

Por lo tanto, el error no se detect贸 en tiempo de compilaci贸n, simplemente porque 驴por qu茅 verificarlo? No hubo pruebas unitarias para ello, porque fuimos verificados por un tipificador est谩tico. No tiene sentido probar cosas que han sido verificadas por la capa a continuaci贸n, todos recuerdan la jerarqu铆a de prueba.

Debido al hecho de que la sincronizaci贸n entre estos dos contratos se rompi贸 con el tiempo, un d铆a se realiz贸 una transferencia incorrecta a la direcci贸n que se dirigi贸 a la direcci贸n incorrecta. Como era una criptomoneda, es imposible revertir una transacci贸n un poco m谩s que en principio. Nadie volver谩 a bifurcar el aire por tu bien. Por lo tanto, los contratos y las interacciones en la programaci贸n de contratos son las primeras cosas que debe comenzar a hacer ma帽ana.

Por qu茅 sucede esto: aislamiento


El siguiente problema es el aislamiento. Es multifac茅tico y multifac茅tico. Cuando trabajaba para un hotel y una compa帽铆a de viajes a茅reos, ten铆an una aplicaci贸n en Angular 1. Eso fue hace mucho tiempo, as铆 que es excusable. Un equipo de 80 personas trabaj贸 en esta aplicaci贸n. Todo estaba cubierto de pruebas. todo estuvo bien hasta que un buen d铆a hice mi funci贸n, no la congel茅 y descubr铆 que, durante las pruebas, romp铆 lugares absolutamente incre铆bles en el sistema que ni siquiera toqu茅.

Result贸 que tengo problemas con la creatividad. Result贸 que accidentalmente llam茅 al servicio exactamente igual que otro servicio que exist铆a en el sistema. Como se trataba de Angular 1, y el sistema de servicio no estaba estrictamente escrito, pero se escrib铆a de forma secuencial, Angular comenz贸 a deslizar mi servicio con bastante calma en lugares completamente diferentes e, ir贸nicamente, coincidieron un par de m茅todos para nombrar.

Esto, por supuesto, no fue una coincidencia: usted comprende que si dos servicios reciben el mismo nombre, es probable que hagan lo mismo, m谩s o menos. Era un servicio relacionado con el c谩lculo de descuentos. Solo un m贸dulo estaba ocupado calculando descuentos para clientes corporativos, y el segundo m贸dulo con mi nombre estaba relacionado con el c谩lculo de descuentos en acciones.

Obviamente, cuando la aplicaci贸n es aserrada por 80 personas, esto significa que es grande. La divisi贸n de c贸digo se implement贸 en la aplicaci贸n, y esto significa que la secuencia de conexi贸n de los m贸dulos depend铆a directamente del viaje del usuario en el sitio. Para hacerlo a煤n m谩s interesante, sucedi贸 que ni una sola prueba de extremo a extremo que prob贸 el comportamiento y el paso del usuario por el sitio, es decir, un escenario empresarial espec铆fico, detect贸 este error. Porque parece que nadie tendr谩 que ponerse en contacto con ambos m贸dulos de descuento al mismo tiempo. Es cierto que esto paraliz贸 por completo el trabajo de los administradores del sitio, pero con quienes no sucede.

El problema de aislamiento est谩 muy bien ilustrado por el logotipo de uno de los proyectos que resuelve parcialmente este problema. Esta es Lerna



Lerna es una excelente herramienta para administrar m煤ltiples paquetes npm en un repositorio. Cuando tienes un martillo en tus manos, todo se vuelve sospechosamente como un clavo. Cuando tienes un sistema similar a Unix con la filosof铆a correcta, todo se vuelve sospechosamente como un archivo. Todo el mundo sabe que en los sistemas Unix todo es un archivo. Hay sistemas donde se lleva al m谩s alto grado (casi dije "hasta el punto de lo absurdo"), como el Plan 9 .

Conozco organizaciones que, despu茅s de sintonizarse para garantizar la confiabilidad de una aplicaci贸n gigante, se les ocurri贸 una idea simple: todo es un paquete.



Cuando saca alg煤n elemento de funcionalidad, ya sea un componente u otra cosa, en un paquete separado, autom谩ticamente proporciona una capa de aislamiento. Solo porque normalmente no puede llegar a otro desde un paquete. Y tambi茅n porque el sistema de trabajar con paquetes que se recopilan en un 煤nico repositorio a trav茅s de npm-link o Yarn Workspaces es tan horrible e impredecible en t茅rminos de c贸mo est谩 organizado internamente que ni siquiera puede recurrir a un hack y conectar alg煤n tipo de presentar a trav茅s de "node_modules algo", simplemente porque diferentes personas tienen todo en una estructura diferente. Esto depende especialmente de la versi贸n de Yarn. All铆, en una de las versiones, cambiaron por completo el mecanismo de c贸mo Yarn Workspaces organiza el trabajo con paquetes.

El segundo ejemplo de aislamiento para mostrar que el problema es multifac茅tico es el paquete que estoy tratando de usar en todas partes ahora, esto est谩 enganchado a cls . Es posible que conozca otro paquete que implementa lo mismo: este es el almacenamiento local de continuaci贸n . Resuelve un problema muy importante que, por ejemplo, los desarrolladores en PHP no enfrentan.

Se trata de aislar cada solicitud espec铆fica. En PHP, tenemos, en promedio, en un hospital, todas las solicitudes est谩n aisladas, interactuando entre ellas solo si no usa perversiones como Shared Memory, no podemos, todo est谩 bien, tranquilo, hermoso. En esencia, cls-hook agrega lo mismo, permiti茅ndole crear contextos de ejecuci贸n, poner variables locales en ellos y luego, lo m谩s importante, destruir autom谩ticamente estos contextos para que no contin煤en consumiendo su memoria.

cls-hooked async_hooks, node.js , , . , .

, , node-.

#2: 芦禄


, , . , JavaScript 鈥 , . grep-.

Que es esto vim. , - Language Server, - 鈥 , , grep. , , . grep- , grep. , , .

Sequelize . ORM . user.getProjects(). , getProjects? .



, Sequelize, , hasMany, belongsToMany. , , , . , .

code review, , . . 鈥 , .

, : 芦merge request 20 鈥 30 , merge request 5000 鈥 looks good to me禄. , .

JavaScript Ninja , , , junior-, . 芦 react redux禄, 8000 , 10 000 禄 , , 芦 禄. , , 芦 禄, , merge request .

, , merge request , , Linux. , , -. , git. , . , , . .

- . . - , , - .

, . Microsoft Surface Linux, . , , . - .

:




芦 禄, 芦 禄. , React. React, Fiber 鈥 .

, Fiber ( OCaml) JavaScript, . , . , 鈥 , proposal, JavaScript. Scheduler 鈥 proposal stage 0.

, React , - . , : , DOM. 鈥 . , .



鈥 Vue.js. Vue? , . Vue, , , .

Vue React. , Vue, , React.

. Vue , state, , state , . , . Vue .

. , , Web Components c , , . : , pop-up, , , - . 鈥 .

Vue 鈥 scoped slots. , - . scoped slot 鈥 , . . React Render Proper: , . Vue , -.

-, Vue . Vue : , child-, , scoped slots, forceUpdate. , child . .

React . , , shouldComponentUpdate(), . Vue , , , , . . Vue. , - .



Jest . Facebook. JavaScript: , , . . , .

, ECMAScript 2015 . , if, require. Require , . , , , . Jest Babel Require .

NGS- Node, proposal, . JavaScript : Require, . . , Jest c NGS- , , . , .

, , - . , Inversion of Control - Dependency Injection-.

IoC/DI


, , . Angular IoC/DI. React 鈥 , , React Vue? dan.church , evan.church .

, , React Dependency Injection, - . Vue inject provide. .

, , . , NestJS . InversifyJS . TypeScript, , , JavaScript. , .



Typescript, Inversify. , : inject (TYPES.Weapon) katana: Weapon. , , TYPES.Weapon Weapon? 鈥 .

, , , TypeScript ( Flow ) , inject dependency injection runtime, .

芦 禄? Weapon , , TypeScript , . TypeScript , first-class citizen JavaScript, . , , runtime , katana Weapon. .

- C++, , , RTTI: run-time type information, , . C# Java reflection, . TypeScript, 芦 禄, , RTTI.

. . Vue Vue 3 TypeScript, , Vue TypeScript , Microsoft: 芦 , TypeScript, ?禄 , Vue, : props, this. , props , this, . TypeScript , . .

Microsoft , : Vue , Angular, . , TypeScript. React, , .

, . , Dart, mirrors, , Flutter. mirrors, , , .

Inversify, Babel-, , , , runtime-, , .

: . . , , , . , V8 .

V8 , . , , V8, , , . , V8 , TypeScript.

. , , .

#3: 芦禄 , 芦禄


芦禄 芦禄 , , 芦禄 鈥 , . , Vue, . - , - props' .

. typed-css-modules? : CSS, CSS Modules, .



typed-css-modules , , css-, .

12 , CSS- , . 11 12 undefined, CSS- , , , , undefined, .



Yeoman , , , . , , . Angular CLI, Blueprints (, Angular, GDG SPB , , ).




Anguar , , . .

, 芦禄 , 芦禄 鈥 , . , 芦禄 鈥 . , , , , , , .

, 鈥 . junior', , , , . , , React- .

, , , - ESLInt, - , , .

, , . , NestJS Sails.js .



, , , , , - -. Sails ORM, . Waterline 鈥 , . , Sails.js . blueprint , . , , .



Nest, 鈥 , . Dependency Injection, , middleweight .

. , , , , , : 芦 - ?禄

Angular, 鈥 , , dependency injection, , .

- Vue (, ), , Vue . Vue, - , 鈥 Nest. , , , , TypeScript.



:


, JavaScript. , , , , , .

鈥 , , , , , : - . - , 鈥 .



Grafana, , 鈥 . , - , . speech recognition API Microsoft, , , 20 . , , , -.



: CI/CD. GitLab, , . GitLab, , JavaScript-friendly environment , , .

. , , 鈥 , -.



Blue/Green deployment: - , , . , , !


  • JavaScript , , . , , , JavaScript GitHub. 鈥 , , , .
  • JavaScript , ( , ). 芦 , 禄. , . DI , 芦 ?禄
  • , . TypeScript, Flow, Rizen 鈥 , runtime exception, , .

    , 鈥 -, .

HolyJS, : HolyJS 24-25 . 鈥 , ( MobX) ( Chrome DevTools). 鈥 .

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


All Articles