interfaces for modules dependencies injection

En el ejemplo anterior dejábamos de la mano del programador la responsabilidad de respetar las apis de los módulos que contienen las implementaciones que queremos inyectar para aislar nuestra lógica de negocio.

Tenemos una aproximación un tanto diferente, que simularía algo así como las interfaces para homogeneizar el api de todas las implementaciones.

definiríamos nuestra interfaz, definiríamos nuestro objeto donde apilaremos nuestras implementaciones, en este caso, de librerías para manejar el dom:

var interface = {};
var implementation = {};
implementation.dom = {};

Definiriamos nuestra interfaz, así como sus métodos

interface.dom = {
   onDocumentIsReady : function(callback){},
   onWindowIsLoad:function(callback){}
};

Definimos nuestra implementación de jquery, notar como extendemos al prototype los métodos de nuestra interfaz. Una vez estoy seguro que tengo los métodos, implemento en ellos mi implementación con la biblioteca en concreto, en este caso jquery, que cubre la funcionalidad requerida

implementation.dom.jquery = function(){};
implementation.dom.jquery.prototype = Object.create(interface.dom);
implementation.dom.jquery.prototype.onDocumentIsReady = function(callback) {
		'use strict';
  	$( document ).ready( function () {
  		callback();
  	} );
  };	
implementation.dom.jquery.prototype.onWindowIsLoad = function(callback) {
		'use strict';
  	$( window ).load( function () {
  		callback();
  	} );
  };

Lo mismo exactamente para dojo, otra implementación para manejar el dom que cumple mi interfaz

implementation.dom.dojo = function(){};
implementation.dom.dojo.prototype = Object.create(interface.dom);
implementation.dom.dojo.prototype.onDocumentIsReady = function(callback) {
		'use strict';
  	dojo.addOnLoad(
 			function(){						
    		callback();
  	} );  	
  };	
implementation.dom.dojo.prototype.onWindowIsLoad = function(callback) {
		'use strict';
  	window.onload = function () {
  		callback();
  	};
  };

Definimos nuestro módulo, donde inyectamos la implementación que necesitemos

var moduleExample = function(domImplementation) {
	'use strict';
  var sayIfDocumentIsReady = function() {		
    domImplementation.onDocumentIsReady (function () {
      console.log('DOCUMENT IS READY WITH LOGIC CLOSED');
    });
  };
	var sayIfWindowIsLoad = function() {
    domImplementation.onWindowIsLoad(function () {
      console.log('WINDOW IS LOAD WITH LOGIC CLOSED');
    });   
  };
  var initialize = function(){    
		sayIfWindowIsLoad();
    sayIfDocumentIsReady();		
  }; 
  initialize();
};	

Y solo nos queda inicializar nuestro modulo e inyectarle la implementación que queramos

var jqueryImplementation = new implementation.dom.jquery();
var dojoImplementation = new implementation.dom.dojo();
var module = new moduleExample(dojoImplementation);

Como veis, hay muchas maneras de solucionar una misma problemática, por eso es importante analizarlas y adoptar la que mejor resuelva nuestras necesidades.

Como siempre os dejo los ejemplos en jsbin

http://jsbin.com/favale/1
http://jsbin.com/favale/1/edit?js,output

Custom ports/events/callbacks II for modules dependencies injection

Cada vez hay más frameworks que nos hacen tener un ancla extremadamente fuerte de nuestra lógica con él, esta lógica de negocio se ve altamente contaminada por implementaciones de librerías que son difíciles y farragosas de actualizar. Ahora que estoy muy focalizado en la arquitectura modular reactiva he intentado que estos acaben teniendo una implementación propia, esto sería mucho más sencillo, casi nativo, si no tuviese que dar soporte a IE>=8.

Os presento un muy muy muy simple ejemplo de módulo que usa la implementación de la librería externa con una lógica de negocio propia ( en este caso la funcionalidad es simplemente detectar la carga del document o del window usando jquery), inyectándole otro módulo que tiene la implementación propia de la librería en cuestión.

Inicializamos el objeto ui y su objeto jquery, observar que dentro de este objeto del namespace podemos apilar nuestras implementaciones en este caso, de jquery, notar que con un buen trabajo de closure compiler y una buena arquitectura modular podemos inyectar de fuera a dentro las implementaciones necesarias para cada módulo y sus dependencias.

var ui = {};
ui.jquery = {};
ui.dojo = {};

tendríamos por tanto los siguientes módulos:

El modulo onLoadPage que tiene las implementaciones de inyección del callback (ifDocumentIsReady) y escucha del «custom port event» (onDocumentIsReady) que vimos en el ejemplo anterior:

ui.jquery.onLoadPage = ( function () {
  'use strict';
  var exports = {};
  var onDocumentIsReady = function() {
  	$( document ).ready( function () {
  		exports.ifDocumentIsReady();
  	} );
  };
  var onWindowIsLoad = function() {
  	$( window ).load( function () {
  		exports.ifWindowIsLoad();
  	} );
  };
  exports = {
    ifDocumentIsReady : function() {},
    ifWindowIsLoad:function() {},
    onDocumentIsReady: onDocumentIsReady,
    onWindowIsLoad: onWindowIsLoad
  };
  return exports;
} )();

También está el modulo que contiene las implementaciones para dojo de igual forma:

ui.dojo.onLoadPage = ( function () {
  'use strict';
  var exports = {};
  var onWindowIsLoad = function() {
  	window.onload = function () {
  		exports.ifWindowIsLoad();
  	};
  };	
  var onDocumentIsReady = function() {
  	dojo.addOnLoad(
 			function(){						
    		exports.ifDocumentIsReady();
  	} );  	
  };	
  exports = {
    ifDocumentIsReady : function() {},
    ifWindowIsLoad:function() {},
    onDocumentIsReady: onDocumentIsReady,
    onWindowIsLoad: onWindowIsLoad
  };
  return exports;
} )();

Y tendríamos el módulo donde inyectaríamos como dependencia esta implementación, que setearíamos en ya, nuestra propia lógica que no estaríamos obligados a modificar si la implementación lo hiciese, como veis al inicializar el módulo con el operador new, se inicializa, es decir, setea la implementación como suya y añade el callback que el modulo precisa y se pone a escuchar el «evento»:

ui.moduleExample = function(externalDependencie) {
	'use strict';
  var onLoadPage; 
  var injectExternalDependencies = function(){
    onLoadPage = externalDependencie; 
  };
  var sayIfDocumentIsReady = function() {		
    onLoadPage.ifDocumentIsReady = function () {
      console.log('DOCUMENT IS READY WITH LOGIC CLOSED');
    };
    onLoadPage.onDocumentIsReady();
  };
	var sayIfWindowIsLoad = function() {
    onLoadPage.ifWindowIsLoad = function () {
      console.log('WINDOW IS LOAD WITH LOGIC CLOSED');
    };   
    onLoadPage.onWindowIsLoad();
  };
  var initialize = function(){  
    injectExternalDependencies();
		sayIfWindowIsLoad();
    sayIfDocumentIsReady();		
  }; 
  initialize();
};

Una vez inicializadas las variables y definidos los módulos, usaríamos la implementación que quisiéramos en nuestro módulo 🙂

var loadPage = ui.jquery.onLoadPage;
//var loadPage = ui.dojo.onLoadPage;
var module = new ui.moduleExample(loadPage);

Como veis las implementaciones pueden ser más o menos complejas dependiendo de las librerías, intentaré seguir poniendo algunos ejemplos más, de momento podéis echar un vistazo a este ejemplo en jsbin como siempre

http://jsbin.com/voqisa/3
http://jsbin.com/voqisa/3/edit?js,output

How browsers work

Siempre que me quedo con los ojos como los conejos cuando les dan las largas al ver algún código o algún comportamiento que necesito para mi trabajo, procuro leer, estudiar acerca de ello, porque me supera la sensación que «eso» esté ahí y que pueda hacer cosas que no controlo en mi aplicación. Una de las cosas, sobre las que nunca había puesto hincapié, es sobre como funciona un navegador por dentro, cual es la forma en la que renderiza etc. Así que tenía en mi Pocket un artículo » for read later » que hablaba sobre esto y quizá os pueda servir para los que tenéis la misma curiosidad que yo.

How browsers work

Jornadas de Diseño en la escuela de arte de Toledo

Los próximo 4, 5, 6 de Marzo tendrán lugar las Jornadas de Diseño en la escuela de arte de Toledo. EL cartel es una obra maestra realizada por el alumnado de la misma escuela de arte.La Comunidad, que recién ha nacido de mi amigo Miguel Moreno, abre los ciclos de conferencias. Mucha suerte para esta nueva empresa de comunicación, falta le hacía a Toledo contar con su enorme talento.

Los diseñadores han muerto

Hoy estaba yo haciendo flipboarding y releyendo algunas webs, cuando al cuarto de hora he estallado y he tenido que tuitear esto :

píldora #3

«Las prisas no son buenas ni para coger dinero»

O eso dice mi abuelo, y de todo sabe un rato largo…

tómate el tiempo  necesario, haz un gran trabajo.

píldora #3

«El trabajo comparte piso alquilado con el triunfo y le toca todos los días tirar la basura»

La web como mera extensión de un producto

Veo 7 ha cambiado su web con una apuesta muy arriesgada. El concepto es el de una interface sencilla y funcional, que va al grano, que no distrae en los contenidos, más que un portal web, es una extensión de los controles del mando de televisión en la web. Su función es muy sencilla, estar informado de la programación. No sé hasta que punto esto no se podría conseguir con el mando de la televisión, siempre y cuando nuestros tdts no sean de los de todo a un euro, así pues, que desgraciadamente, viene siendo la tónica general, así que puede ser una forma muy acertada de conformar su servicio web como una extensión del hardware que tengamos en la tv.

píldora #2

«Claro que un proyecto tiene fecha de entrega, pero no la ponen ni los clientes, ni los diseñadores, la pone el proceso»

píldora #1

«En este país hay cuarenta millones de seleccionadores de fútbol, pero hay muchos más  diseñadores gráficos»