¿Cómo interactúan Mithril y jQuery entre sí?

mithril.js

Question

Estoy usando Mithril como nuestro marco de trabajo de MVC y quiero aprovechar las ricas funcionalidades de JQuery / Jquery UI. Me gustaría entender el "hacer y no hacer" al combinar jQuery con Mithril

Lo que entiendo es que puedo usar la configuración de Mithril para acceder al elemento DOM real y enlazar a varias funciones de jQuery de forma segura.

Usando las funciones de jQuery UI con Mithril

Pero ¿qué pasa con el uso de los selectores jQuery en las clases o ids para localizar el elemento DOM real, como

adjuntando un selector de fecha jQuery

  beforeShow: function(input, inst) {
   $(''#ui-datepicker-div'').addClass("mydatepicker");
  },

o escondiendo un div

 $("#mydiv").hide();

¿Cuál es el peligro de que inprogress m.render cause $ (''blah'') === undefined?

Realmente me gustaría entender cómo estos 2 componentes podrían / ​​deberían interactuar entre sí.

Answer 1

En pocas palabras, se garantiza que todas las funciones de config se ejecutarán después de que se haya creado el árbol DOM. así que desde dentro de una configuración, puede llamar a $ (bla) sin preocuparse de si el elemento ha sido dibujado.

La advertencia con Mithril (o, para el caso, cualquier sistema que permita montar y desmontar los subtlajes) es que los elementos pueden eliminarse del DOM mediante lógica condicional. Debido a esto, se recomienda adjuntar config al elemento que se verá afectado por el complemento jQuery, o envolver un subárbol de elementos en una función para que sea más obvio que una configuración que utiliza querySelector se aplique a eso Gama específica de elementos.

Para una gran cantidad de llamadas a jQuery, en realidad no importa si el elemento que se consulta está allí o no (por ejemplo, $(".foo").hide() simplemente no hace nada si no hay .foo en la página. ).

Lo más importante de lo que debe preocuparse es que no desea conducir demasiado estado desde el propio DOM (que es algo idiomático en jQuery). Por ejemplo, alternar la visibilidad de un panel puede ser algo que se puede hacer más rápido en jQuery, pero es más difícil alcanzar estados visibles e invisibles desde, por ejemplo, una carga de página, si la fuente de datos canónica es la clase CSS en el DOM. que está controlado por el código jQuery, en lugar de un indicador de modelo de vista que fluye de manera unidireccional hacia la vista.

Answer 2

Primero averigüemos qué está haciendo cada biblioteca: Mithril es un andamio MVC que se utiliza para definir la estructura y el ciclo de vida de su aplicación. Las vistas de Mithril definen el DOM, incluidos los ID que tendrán los elementos del DOM, y también determinarán cuándo se eliminarán o cambiarán estos elementos; jQuery UI se utiliza para definir el comportamiento de los widgets que se encuentran dentro de su estructura de vista más amplia.

Mithril proporciona un atributo de config para exponer una función que le da acceso al "elemento DOM real" del que está hablando. La función se ejecuta siempre que la vista de Mithril se haya renderizado o cambiado: el primer argumento es el elemento DOM; el segundo argumento es false si el elemento se acaba de crear y true contrario; El tercer argumento es el context : le permite definir un comportamiento adicional antes de que el elemento se elimine del DOM.

config solo se ejecutará cuando el elemento realmente exista, y proporciona una referencia para él. Por este motivo, su código de jQuery UI debe estar dentro de esta función. Una ventaja de esto es que nunca necesita una referencia de estilo de selector CSS al elemento, porque config siempre proporciona una referencia directa como el primer argumento. Reescribamos tu primer fragmento de código para que funcione de esta manera:

m.module( document.body, {
  controller : function(){
  },
  // Because the view is generated by Mithril code 
  // (which could change the classes or IDs, or remove elements entirely...
  view       : function(){
    return m( ''.this'', 
             m( ''.is'', 
               m( ''.all'', 
                 m( ''.rendered'', 
                   m( ''.by'', 
                     m( ''.mithril'', 
                       // ...None of this is referenced by jQuery. 
                       m( ''input[placeholder=Rendering by Mithril!]'', {
                         // All jQuery happens in external functions, attached like this:
                         config : configDatePicker
                       } ) ) ) ) ) ) );
  }
} )

// ...Meanwhile...

function configDatePicker( element, init, context ){
  // We don''t want to add the class all the time, only the first time the element is created
  if( !init ){
    // Here we reference the element directly, and pass it to jQuery
    $( element ).datepicker().on( ''click'', function(){
      $( element ).val( ''Behaviour by jQuery!'' )
    } );
    
    // We can also bind an event to trigger behaviour when the element is destroyed
    context.onunload = function(){
      // …But this will never happen because our code doesn''t do that ;)
      alert( ''.mydatepicker is going to be destroyed!'' )
    };
  }
}

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<link href="https://code.jquery.com/ui/1.11.1/themes/smoothness/jquery-ui.css" rel="stylesheet"/>
<script src="http://cdnjs.cloudflare.com/ajax/libs/mithril/0.1.24/mithril.min.js"></script>
<script src="https://code.jquery.com/ui/1.11.2/jquery-ui.min.js"></script>

Probablemente la mejor manera de pensar esto de una manera jQuery es que la config es un poco como DOM listo:

$( document ).ready( function thisIsABitLikeAConfigFunction( element ){
  // Except that DOM ready only works on the document element
}  );