¿Cómo se supone que se estructuran las grandes aplicaciones de JavaScript?

Recientemente me han mostrado algunos complementos de JavaScript escritos para OBIEE Mobile App Developer, así como algunas bibliotecas personalizadas para varios proyectos.

Viniendo de un fondo de OOP, estoy un poco confundido acerca de la estructura de estos proyectos. Estoy viendo archivos que tienen miles de líneas de largo. Estoy acostumbrado a dividir las cosas en archivos y clases, pero entiendo que este es un marco diferente , por ejemplo, el tamaño del archivo es un problema, pero ¿debe haber una mejor manera de hacerlo todo?

La longitud de los scripts afecta no solo la lectura y la facilidad de mantenimiento, sino también la comprensión general de una persona de cómo funciona el programa.

¿Cómo se estructuran las grandes aplicaciones? ¿Algún patrón de diseño general de OOP para esto?

Si no está familiarizado con los patrones de JavaScript, puedo decirle que muchas aplicaciones y bibliotecas grandes están utilizando Revealing Module Pattern , pero hay muchos otros patrones que puede usar según sus necesidades.

Sin embargo, el Patrón de módulo revelador debería darle una buena manera de dividir archivos grandes y organizarlos lógicamente; Sin embargo, cuando trabaje con cualquier patrón de diseño en JavaScript, tenga en cuenta que esto puede ser muy confuso. Trate de usar esto , nuevo , prototipo , .call()y .apply()sabiamente.

Mientras trabaja en proyectos grandes, estos pueden ser útiles también:

• Si es posible, cambie a TypeScript o ES6.
• Escribir código modular . Hay varias formas y bibliotecas de terceros, pero cualquiera de ellas es mejor que nada.
• Use un Task Runner / Build System para automatizar tareas.
• Lea sobre Patrones de diseño . Este podría ser un buen comienzo. Como dije anteriormente, el Patrón del módulo revelador es muy útil, especialmente si cree que necesita tiempo para dominar todos los patrones populares.
• Escribir pruebas unitarias . Trabajar con un lenguaje dinámico puede ser más desafiante. Probar las partes cruciales de su aplicación puede ahorrarle mucho tiempo.
• Use un IDE o editor de texto que realmente pueda ayudarlo tanto a escribir código como a detectar errores. WebStorm es una buena opción. Sublime Text también.
• Si su IDE no ofrece un depurador, intente dominar el depurador de su navegador web favorito.
• Utiliza bibliotecas. Dependiendo de la naturaleza del proyecto, intente emplear el mejor código de terceros que pueda encontrar. Si está escribiendo una aplicación web, eche un vistazo a Angular , React y el antiguo backbone.js . Si está escribiendo una aplicación Node.js, tómese su tiempo para buscar en el repositorio de NPM . Se sorprenderá de cuántos paquetes ya están haciendo lo que estaba a punto de hacer.
• Incluso si usted es la única persona que está trabajando en el proyecto, aún use un sistema de control de versiones como Git y siga un Estándar de codificación que no sea demasiado estricto y obstinado, pero que a la vez proporcione una buena guía que sus compañeros de equipo también estarán felices de hacer. seguir.
• Incluso si opta por TypeScript o ES6, aún entendiendo la OOP sin clase de JavaScript, Protopypal OOP puede ser útil, especialmente durante la depuración.

Soy desarrollador de C ++ y últimamente he comenzado a hacer desarrollo web. Estoy portando una gran aplicación de escritorio al entorno web. Estructuro mi código JavaScript exactamente como estructuré el código C ++, usando los mismos patrones. Tengo alrededor de 25-30 archivos en total, pero eventualmente los reduciré a 3-5 haciendo clubbing según corresponda y los minimizaré a todos.

Para mí, es solo el lenguaje que ha cambiado, para bien o para mal, pero no el paradigma. JavaScript, a pesar de todas sus fallas y frustraciones, es una buena combinación de estilo funcional y OOP. Las cosas han funcionado bien hasta ahora.

Por último, una cosa de la que me di cuenta al principio fue que JavaScript permite escribir un código mucho más conciso que C ++, por lo que a veces tener una gran cantidad de LOC provenientes de un lenguaje que no es JS podría deberse a apegarse a la forma antigua de hacer las cosas. Una vez que se aborda este asunto, no veo nada que realmente deba ser diferente. El diseño y los algoritmos son, después de todo, independientes del lenguaje.

Varía mucho de un proyecto a otro, por supuesto, pero la práctica generalmente aceptada es que, para cosas que están destinadas a funcionar como bibliotecas o módulos, colocarlas en un solo archivo grande y usar la encapsulación para evitar su funcionamiento interno ("privado" ) interfaz de fugas al exterior. También es útil para los desarrolladores que desean usar la biblioteca / módulo: un archivo para agregar a la configuración de la aplicación o al fragmento de encabezado en lugar de una jerarquía completa de carpetas y archivos para copiar y pegar. También refleja el hecho de que, con la minimización y la agrupación, en un sitio de producción lo más probable es que todos se combinen en un solo archivo para reducir la cantidad de solicitudes HTTP.

Su propio código de aplicación no necesita seguir esta práctica, y probablemente no debería. Como su aplicación es la única que la usa, solo tiene que agregar los archivos una vez y probablemente pueda contar con la plataforma para manejar la minimización y la agrupación por usted.

Cuando se trabaja en el código, los diferentes componentes generalmente se dividen en módulos, cada uno implementando típicamente una sola clase y cada uno vive en un archivo separado. Durante la producción, estos archivos se agrupan en un solo archivo (de ahí las miles de líneas de código que está viendo) usando algo como Browserify ( http://browserify.org/ ) o RequireJS para reducir la cantidad de solicitudes HTTP, pero también para asegurar que las dependencias se carguen en el orden correcto

En cuanto a cómo se implementan las clases para estos módulos, es un poco diferente de OOP en la mecánica subyacente, pero no es tan diferente en la superficie. ES6 incluso introdujo la classpalabra clave, por lo que debería parecer bastante familiar. Este artículo sobre MDN es útil para comenzar: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Utilizo elementos y anotaciones netas (de Petri) para organizar o "estructurar" software para mis aplicaciones de formularios PDF: programas de JavaScript que usan la API de Acrobat / JavaScript. Quizás pueda ser útil en su situación.

Se utiliza un diagrama para establecer las relaciones de entrada-salida de elementos netos y dos vistas de forma de las anotaciones. Según las vistas de diagrama y formulario, es posible crear sistemáticamente programas JavaScript para aplicaciones de formulario PDF. Por lo tanto, "leer" el código fuente se reduce a verificar que coincida con las especificaciones: el diagrama y dos vistas de formulario.

La implementación de mi software utiliza constructores y prototipos. Si el rendimiento se convierte en un problema, reemplazar los prototipos con miembros de la instancia puede mejorar el rendimiento a expensas de un mayor uso de memoria. También se utilizan matrices. Si el rendimiento se convierte en un problema, se utilizan referencias directas.

Algunas de las propiedades se crean usando eval; para objetos con muchas propiedades, esto reduciría la cantidad de código en el archivo fuente y la cantidad de escritura por parte del programador.

Todavía es posible y se recomienda escribir JavaScript en la forma en que estás acostumbrado. Aquí hay un buen libro que revisa los patrones de diseño más importantes en JavaScript.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

También hay muchos marcos de JavaScript donde el objetivo principal es poder dividir el código en diferentes archivos y módulos. Si el marco particular en el que está trabajando requiere que tenga todo su código en un archivo, entonces definitivamente debería buscar cambiar.