llamar - Aplicación impulsada por datos de organización de código JavaScript

llamar javascript desde html

Question

Actualmente estoy trabajando en el front-end de una aplicación Asp.net MVC a mediana / gran escala y tengo algunas dudas sobre el patrón correcto de organización / diseño de código a seguir. La aplicación web está compuesta por varias páginas que contienen muchos widgets Kendo UI MVC definidos con la plantilla Razor.

Para aquellos que no están familiarizados con Kendo, la sintaxis de la afeitadora se traduce a Javascript como el siguiente fragmento:

Definí dentro de mi carpeta Script dos carpetas principales, y estructuré mis archivos js de la siguiente manera:

• shared // Contiene los archivos js compartidos -file1.js -file2.js

• páginas // Un archivo por página

  • page1.js
  • page2.js
  • ...
  • Ticket.js // página 4 :)

Cada archivo js es un módulo separado definido con el siguiente patrón:
Nota : La función init interna se registra en cada función de devolución de llamada a los eventos de la ventana y ocasionalmente a un bloque $(document).ready(function(){}) .

;(function () {
    "use strict";

    function Ticket(settings) {
        this.currentPageUrls = settings.currentPageUrls;
        this.currentPageMessages = settings.currentPageMessages;
        this.currentPageEnums = settings.currentPageEnums;
        this.currentPageParameters = settings.currentPageParameters;         


        this.gridManager = new window.gridManager(); //usage of shared modules

        this.init();
    }

    Ticket.prototype.init = function () {           

            $("form").on("submit", function () {
                $(".window-content-sandbox").addClass("k-loading");
            });

            ...
    }    

    Ticket.prototype.onRequestStart = function (e) {

        ...
    }

    //private functions definition
    function private(a, b, c){

    }

    window.Ticket = Ticket;
}());   

Una vez que necesito las funciones de mi Javascript definidas en un módulo, incluyo el archivo Javascript asociado en la página. Una cantidad de mi objeto se almacena dentro de una variable y, además de eso, una función está vinculada al evento widget (ver: onRequestStart).

HTML / JAVASCRIPT

@(Html.Kendo().DropDownList()
      .Name("Users")
      .DataValueField("Id")
      .DataTextField("Username")
      .DataSource(d => d.Read(r => r.Action("UsersAsJson", "User"))
                        .Events(e => e.RequestStart("onRequestStart"))))



var settings = {};

var ticket = new window.Ticket(settings);

function onRequestStart(e){
    ticket.onRequestStart(e);
}

Siento que mi patrón de diseño puede ser hostil para otros delevoper front-end como lo soy, principalmente porque elijo no implementar los módulos de Javascript dentro del plugin de Jquery.

Primero , ¿estoy haciendo todo mal?
En segundo lugar , ¿mi patrón de diseño es adecuado para un marco de prueba de Javascript?
En tercer lugar , ¿cuáles son los escenarios imprescindibles para los complementos de Jquery?

Actualizar

Se agregó el resultado de Javascript con la sintaxis de Razor anterior.

Answer 1

Puedes intentar separar tus archivos en diferentes componentes asumiendo que cada componente tiene una carpeta.

por ejemplo: la página 1 trata de rectángulos, por lo que crea un rectángulo de llamada de carpeta dentro de esa carpeta, usted crea 3 archivos rectangle.component.html, rectangle.component.css, rectangle.component.js (opcional rectangle.spec.js para pruebas).

app
└───rectangle
        rectangle.component.css
        rectangle.component.html
        rectangle.component.js

así que si algo malo sucede en un rectángulo, sabes dónde está el problema

una buena forma de aislar variables y ejecutarlas en el lugar correcto es usar un enrutador, básicamente, lo que esto comprueba en la url y ejecuta la parte del código que asignas a esa página

Espero que me ayude a saber si necesita más ayuda.

Answer 2

La organización y el patrón parecen buenos, pero tengo algunos consejos:

Consejo 1:

En lugar de establecer variables globales específicas dentro de su módulo, quizás podría devolver el objeto en su lugar. Entonces, en lugar de hacer esto:

;(function () {
"use strict";

    function Ticket(settings) {
        console.log("ticket created", settings);
    }
    ...
    window.Ticket = Ticket;
}()); 

Tú harías esto:

;window.Ticket = (function () {
"use strict";

    function Ticket(settings) {
        console.log("ticket created", settings);
    }
    ...
    return Ticket;
}()); 

La razón para esto es poder tomar el código de su módulo y darle un nombre de variable global diferente si es necesario. Si hay un conflicto de nombre, puede cambiarle el nombre a MyTicket o lo que sea sin cambiar realmente el código interno del módulo.

Consejo 2:

Olvide el consejo 1, las variables globales apestan. En lugar de crear una variable global separada para cada tipo de objeto, ¿por qué no crear un administrador de objetos y usar una única variable global para administrar todos sus objetos?

window.myCompany = (function () {
    function ObjectManager(modules) {
        this.modules = modules || {};
    }

    ObjectManager.prototype.getInstance = function(type, settings) {
        if (!type || !this.modules.hasOwnProperty(type)) {
            throw "Unrecognized object type:";
        }
        return new this.modules[type](settings);
    };

    ObjectManager.prototype.addObjectType = function(type, object) {
        if (!type) {
            throw "Type is required";
        }
        if(!object) {
            throw "Object is required";
        }
        this.modules[type] = object;
    };

    return new ObjectManager();
}());

Ahora cada uno de sus módulos se puede administrar con este único objeto global que tiene asociado el nombre de su empresa.

;(function () {
"use strict";

    function Ticket(settings) {
        console.log("ticket created", settings);
    }
    ...
    window.myCompany.addObjectType("Ticket", Ticket);
}()); 

Ahora puede obtener fácilmente una instancia para cada tipo de objeto individual como este:

var settings = {test: true};
var ticket = window.myCompany.getInstance("Ticket", settings);

Y solo tienes una variable global de la que preocuparte.

Answer 3

Estructura de la carpeta

En términos de funcionalidad (compartida) y módulos (enfoque modular), el código de desarrollo o aplicación debe representar lo que puede encontrar en HTML. Un simple ctrl + f sobre su solución debería producir todos los cambios posibles. De esa experiencia a través de los años, personalmente prefiero dividirla en:

• aplicación (código de la aplicación)
  • clases (reutilizables)
  • módulos (singleton)
• lib (gestor de paquetes / gruñido / trago / ...)
  • jquery (nombres de biblioteca apropiados / archivo de dist. no minificado o archivo raíz)
  • kendo

Nombres de archivo

Representar lo que hace algo y poder reutilizarlo en un abrir y cerrar de ojos es lo que reducirá su tiempo de desarrollo. Elegir nombres propios tiene valor, estoy seguro de que lo sabes. Mis nombres de archivo siempre comienzan con el namespace generalmente en corto seguido de un término de "búsqueda" reutilizable:

• aplicación / prototipos
  • ns.calendar.js (múltiples configuraciones)
  • ns.maps.js (combinaciones o usos únicos)
  • ns.places.js (formularios o complementos del mapa)
  • ns.validation.js (formularios múltiples y manejo general)
• aplicación / singletons
  • ns.cookiebox.js (configuración única)
  • ns.socialmedia.js (configuración única)
  • ns.dom.js (proporciona un lugar para correcciones dom, eventos de cambio de tamaño global, pequeños widgets, ...)

Para agregar, lo que llamaste compartido, es una funcionalidad que debe ser global. Un buen ejemplo sería usar la biblioteca de guiones bajos. O cree una colección de funciones (detección de dispositivos, acelerador, ayudantes en general) por su cuenta para reutilizar en proyectos => ns.fn.js Puesto que los agrega solo una vez en su espacio de nombres, también está construido como singleton y se puede agregar a la carpeta de módulos o directamente en la raíz de la aplicación.

Como última adición, un archivo de cargador para iniciar su punto de control => ns.load.js en la raíz de la aplicación. Este archivo contiene el único evento listo para DOM para enlazar prototipos y módulos.

Por lo que es posible que desee replantearse su idea de dividir en páginas. Confía en mí, he estado allí. En algún momento, notará cómo la funcionalidad crece demasiado para configurar todas las páginas por separado y para eso repetidamente.

Estructura de archivo

Para ser sincero, me gusta que la sugerencia 1 de @TxRegex responda al máximo, con una pequeña adición para enlazar el espacio de nombres y pasarlo de un archivo a otro a medida que se carga.

Principio básico: IIFE vinculado al objeto ventana

window.NameSpace = (function($, ns){
    ''strict''
    function private(){}
    var x;
    ns.SearchTerm = {};
    return ns;
}(window.jQuery, window.NameSpace || {}));

Para obtener más código de ejemplo, me gustaría señalar mi cuenta de github .

Agrupamiento

Intente obtener un único archivo empaquetado y minificado de lib a app, cargado en la head async para lanzamientos de producción. Utilice archivos de script separados y no miniados en defer para fines de desarrollo y depuración. Debe evitar la secuencia de comandos en línea con dependencias globales en todo el proyecto si hace esto.

• ruta a js / lib / ** / *. js (generalmente separados para mantener el orden secuencial)
• ruta a js / app / ns.load.js
• ruta a js / app / ns.fn.js
• ruta a js / app / ** / *. js (actualización automática del paquete)

Salida => ns.bundle.js => ns.bundle.min.js

De esta forma, evitará los problemas de bloqueo de la presentación en JavaScript y acelerará el proceso de carga, lo que a su vez impulsa el SEO. También le permite combinar funcionalidades para diseños móviles y diseños de escritorio sobre la marcha sin problemas de memoria o comportamiento irregular. Minifica muy bien y genera poca sobrecarga en las instancias de llamadas desde el archivo de carga. Como un solo paquete se almacenará en caché en todas sus páginas, todo depende de la cantidad de dependencias o bibliotecas que pueda cortar del paquete. Idealmente para proyectos medianos y grandes donde el código puede ser compartido y conectado a diferentes proyectos.

Más información sobre esto en otra publicación .

Conclusión

Primero, ¿estoy haciendo todo mal?

• No del todo, su enfoque modular parece estar bien ...
• Falta un espacio de nombre global, que es difícil de evitar sin al menos uno. Puede crear uno para cada módulo, pero parece mejor agruparlos en un espacio de nombres para que pueda diferenciar el código de la biblioteca del código de la aplicación en el objeto de la ventana.
• Kendo parece crear scripts en línea? ¿No puedes contrarrestar el lado del servidor de colocación?

En segundo lugar, ¿mi patrón de diseño es adecuado para un marco de prueba de Javascript?

• A excepción de las instancias de Kendo, puede agregar una capa para fines de prueba. Recuerda que si jQuery es tu dependencia en línea, tendrás que renderizar el bloqueo que está cargando. De lo contrario => jQuery is undefined
• Excluya las dependencias de Kendo del paquete si no puede controlar el script en línea. Vaya a una solución incluida en el paquete </body> .

En tercer lugar, ¿cuáles son los escenarios imprescindibles para los complementos de Jquery?

• enfoque modular
• enfoque configurable para múltiples instancias (consejo: mover todas las cadenas desde su lógica, ver cómo Kendo usa literales de objeto)
• administrador de paquetes para separar el "junco" del "oro"
• grunt / gulp / ... configuración para separar scss y css de js
• intente obtener un enlace de atributos de datos, de modo que una vez que todo esté escrito, configure instancias nuevas a través de HTML.

¡Escriba una vez, adapte fácilmente donde sea necesario y configure mucho!