En los dos anteriores post, donde comenzaba planteando la idea de que un buen desarrollo no depende del framework más moderno sino de nuestra capacidad de escribir código, hasta comenzar a diagramar, en el segundo post, cómo podríamos lograr esto con un framework que muchos, en el mundo del desarrollo front end consideran muerto o de poco prestigio, en este post vamos a mover un poco más allá la idea tratando de mostrar que, como ya comenté, depende de cómo escribamos código y no de la herramienta
(Vuelvo al disclaimer: Que sí, que no es ser fundamentalista de lo viejo, solo reservado con lo nuevo)
Entonces, cómo hacemos para desacoplar, en la mayor medida posible, el DOM de nuestro código HTML?
Si revisamos React o Angular o Vue (Nombro estos porque son los más populares) todos estos, en sus implementaciones más comunes, cometen un error (Sí, un error) en forzar un lenguaje de etiquetas con funcionalidad. Tal vez el más límpio de los tres sea Vue, pero en todos los casos siempre tendremos algo que no es HTML dentro del HTML. Y, nuevamente, esto es un error. Los frameworks se transforman en virus que estiran sus tentáculos más allá del dominio de JavaScript e infectan el HTML.
En realidad, lo que quiero decir es que, si haces una página o sitio con Angular, no puedes cambiarlo en un futuro a React o Vue o lo que venga nuevo ya que no solo tu código JavaScript sigue un patrón específico y esperado por el framework usado sino que incluso el código HTML está intoxicado de dicho framework. O sea, el nivel de acoplamiento entre dos mundos totalmente distintos es absoluto y, por lo tanto, va en contra de cualquier patrón básico de desarrollo de software.
Entonces necesitamos crear código que desacoplado: Código no infectado.
Desacoplando la vista (Ahora sí)
Para desacoplar la vista (HTML) es necesario pensar en esta como lo que es: Una definición del aspecto visual, no del comportamiento de las reglas de negocio.
La vista debe utilizar solo contenido HTML y que no sea relevante para ningún contexto en particular. O sea, que no esté atado a ningún framework.
<textarea :value="input" @input="update"></textarea>
Código propuesto por Vue
<input type="text" ng-model="name">
Código propuesto por Angular (Aunque mejor, sigue siendo propiedad de Angular)
render() {
return (
<div>
<input onChange={this.handleChange} />
</div>
);
}
React…
En los tres casos, todos intentan tomar control acoplándose de forma directa al HTML. Tal vez, Angular, sea el que mejor se aproxima a un modelo desacoplado ya que mediante el uso de atributos define el comportamiento. En este caso “ng-model” no significa nada para el navegador, salvo que Angular entre en acción, y esto, claramente, es algo bueno. Por supuesto, luego comienza a ponerse más intrincado al tener que proveer toda funcionalidad posible y, por lo tanto, terminaremos teniendo definiciones no HTML para hacer bucles, mostrar textos, calcular resultados, etc. Lo que nos trae un acoplamiento duro nuevamente.
Pero, sigamos por este camino, que es el que, decíamos, mejor se aproxima. Cómo haríamos esto, entonces, si queremos asegurarnos que no estamos acoplando nuestro desarrollo (Código JavaScript) e infectando el HTML?
<button
data-control="button"
data-event="click"
data-name="boton1">
Click me!
</button>
En este caso, una implementación simple podría usar los atributos tipo “data-*” que, de acuerdo a la documentación, se crearon para esto: Contener información extra y extender el HTML sin causar mayor daño mediante atributos personalizados (Lo de daño es una interpretación libre personal).
Luego, nuestro botón (Que veíamos en el post pasado) puede ser escrito (De forma muy grosera) así:
var button = function (DOMElement) {
this._element = $(DOMElement);
this.name = this._element.data('name');
this._event = this._element.data('event');
this._initialize();
};
button.prototype._initialize = function () {
$(this._element).on(this._event, function () {
console.log("test");
});
}
Recordemos que nosotros inyectábamos jQuery y lo transformábamos en el símbolo $. Si revisamos nuevamente esa propuesta, quiere decir que el símbolo $ podría ser cualquier cosa que nos permita seleccionar o trabajar de la forma en la que propone el código. Con esto quiero decir que si bien he escrito el código pensando en jQuery, podría ser pensado de forma en que se inyectase cualquier otro framework o mecanismo para realizar las tareas básicas de selección de elementos del DOM y asociación de eventos. En todo caso, lo importante en este punto es que el comportamiento del botón estará definido en su totalidad en JavaScript y no en el DOM.
Por último, y para ir cerrando este primer acercamiento, necesitaremos que alguien cree las instancias de estos posibles botones. Para el caso, el controlador de la página que lo requiera.
(function (w, $, button) {
var buttons = $('[data-control=button]');
w.botones = {};
for (var i = 0; i < buttons.length; i++) {
var button = new button(buttons[i]);
w.botones[button.name] = button;
}
}(window, jQuery, MyApp.components.button));
Está claro que esto se puede generalizar y obviar la creación de estos botones en cada controlador, pero sirve, como decía, de primer acercamiento.
Y, como venimos con esta serie… Continuará!
En unos días estaremos llevando adelante un evento muy grande. Se viene la STEMFest por esta zona del planeta (Tauranga, New Zealand).