AngularJS - Por que es AngularJS tan complejo ?

Introducción

Hace unos dias conversaba con un amigo sobre AngularJS y la razon de su complejidad. En si no es complejo del todo, tiene que ver mas bien con previas experiencias que el equipo de AngularJS obtuvo en proyectos anteriores (por ejemplo Google Closure, quizas GWT). Pero mis puntos claves que he descubierto son los siguientes.

Tiempo de curva de aprendizaje vs tiempo al mercado

Yo estuve en un proyecto de 24 a 28 meses usando Backbone, jQuery y Bootstrap. Al principio seguiamos todos los patrones y mejores practicas. El codigo era escalable. Pero fallamos en varios aspectos que a continuacion describo:

Entrenamiento y divulgacion interna

Eramos malos documentando el API recien creado. Otros equipos encontraron dificultad en adaptarse.

Obsolesencia

A los seis meses, el mismo Backbone de nuestro framework nunca lo actualizamos.

Tiempo al mercado (Time to Market)

Cuando finalmente llego AngularJS al cliente, la entrega de los otros equipos de algun modo era mas rapida que la nuestra. Seguramente porque evitaron el sindrome NIH (Not Invented Here).

La curva

Obsolesencia y divulgacion son dos puntos claves. Pero no explica por si solo el "Time to Market". Es aqui la diferencia de "Angular Way" vs tu framework con librerias. AngularJS "normaliza" el conocimiento, al tener directivas como la forma para interactuar con jQuery y factorias/servicios como la forma de creacion de objetos. Esto permite desarrollar sumamente rapido con los mismos conceptos entre equipos. De tal modo que con 100 horas (casi un mes solo en Angular) obtienes un conocimiento intermedio al que obtendrias con la misma cantidad que con Backbone, jQuery y todo lo relacionado (templates, grunt, requirejs, stickit, marionette, thorax, etc)

La curva de aprendizaje siempre va ser importante como tambien el time to market. Yo lo veo como un Ying Yang. Hay un balance entre estos dos.

Realmente debo usar AngularJS para todo emprendimiento?

La respuesta es facil, todo va depender de tu escenario, en las habilidades de tu equipo, el presupuesto y la crema, que tanto "edgy" o en boga quieran usar tecnologia innovadora (Polymer WebComponents, ES6 transpiler, ClojureScript/Om)

En las siguientes entregas tocare brevemente el tema del empleo y los informales, despues continuo con mas AngularJS y posteriormente un poco de HapiJS y Joi

Hasta la siguiente entrega

AngularJS - Validaciones de formularios #1

Introducción

En este articulo explicamos brevemente ciertas cualidades de AngularJS 1.3.x

Validar debería ser fácil con Angular

Sin embargo, hay flujos de validaciones que no son soportados, por ejemplo:

• Cargar formulario con campos "required": En Angular, siempre son mostrados. No hay forma sencilla de decirle después que salga del foco.
• Validaciones cuando haces clic el botón de submit o un botón cualquiera.

Usando Angular 1.3 ngMessages

Yearofmoo describe ngMessages de una manera correcta. Lo esencial es que ngMessages lee el $error del campo (ejemplo form.campo.$error) y toma el primer key/value y presenta este error en caso de estar activo.

Lo cual funciona de perfectamente bien. Hasta que queremos resolver los dos casos extremos mencionados (que en Backbone son fáciles de implementar ciertamente).

Caso #1 - Solo debe mostrarme requerido al perder el foco

Mi solución rudimentaria fue usar un combo de ng-blur y ng-change, mantener el required message en el conjunto de ng-messages y tener una simple función en el controller. Esto se puede mejorar mucho mas con un Angular Directive.

Ahora, al cargar el formulario, solo se muestra requerido al perder el foco (blur). Lo bueno de esto es que reusamos ngMessages tal como esta.

En la próxima entrega explicaremos como resolver el Caso #2 con el submit.

Correciones: En vez de setear invalid = true, debe usarse $setValidity

Hasta la siguiente entrega
Rogelio Morrell