Cuando se habla de dependencias , se pueden utilizar ambos términos, a veces de forma (peligrosa) intercambiable. ¿ React es un marco o una biblioteca? ¿Qué pasa con Bootstrap o Lodash ? Ambos son " paquetes " después de todo, ¿verdad?

Claro, pero definitivamente no tienen el mismo impacto en su aplicación.

bibliotecas

Una biblioteca ("bibliothèque" en francés, pero la mayoría de los franceses dicen "librairie", que en realidad significa "librería" en francés, pero coincide con la pronunciación en inglés de "biblioteca") es un conjunto de funciones para propósitos generales (como guión bajo.js ) o especializados (como moment.js ).

Puede llamar a las funciones de la biblioteca siempre que las necesite, como elegir herramientas en una caja de herramientas. No requieren ningún cambio en el diseño de su software .

Llamadas propietarias

Sin embargo, como dependencia, requieren que llame a su API patentada, por lo que "bloquea" su código con ellos (o incluso posiblemente una versión de ellos), por lo que una llamada a la biblioteca debería verse así:

Dicho bloqueo aumentará con la cantidad de llamadas que esté emitiendo: cuanto más llame a la biblioteca, más dependerá su código de ella (o de una versión de ella):

Único punto de dependencia

Sin embargo, para limitar dicha dependencia, puede ocultarla detrás de un contenedor:

Tal envoltorio en realidad puede servir para más de un propósito. Además de reducir el bloqueo a un solo punto en su base de código, le permite exponer su propia API a las personas que llaman. Tal adaptación de la biblioteca solo incluirá la API que tenga sentido para su aplicación, así como los tipos de E/S que no son específicos de su aplicación ni de la biblioteca.

Sin embargo, hablando de implementación, paso a paso, su código aún depende del de la biblioteca.

API empresarial

Con suerte, como solía decir el difunto David J. Wheeler:

Todos los problemas en informática se pueden resolver mediante otro nivel de indirección .

De hecho, puede evitar tal dependencia agregando una interfaz :

• las personas que llaman dependerán de esa declaración API;
• el adaptador tendrá que implementarlo (tenga en cuenta que esto también facilitaría la simulación de bibliotecas durante la prueba).

Marcos

Los marcos ("quadriciels" en francés oficial, pero todo el mundo dice "marco") son diferentes, ya que brindan un tipo de servicio diferente: ofrecen administrar las cosas por usted, en lugar de permitirle decidir qué hacer.

entregando el control

Para hacerlo, implementan la columna vertebral (el "marco") de una aplicación y le permiten completar los espacios en blanco. Pero esos espacios en blanco se dejan en lugares definidos y tienen formas definidas.

Eso significa que:

• la aplicación comienza con el marco : tienes que entregar el volante.
• dado que el marco impulsa la aplicación, usted ya no es el que realiza las llamadas: en su lugar, el marco le devolverá la llamada cuando corresponda.

Contratos

Por supuesto, nada le impide llamar manualmente algún código propio, una biblioteca de terceros o incluso alguna API de marco, pero bajo su propio riesgo . Esto puede o no funcionar como esperas. Los marcos tienen reglas que se supone que debe seguir y, si las rompe, el marco no podría ser considerado responsable de ninguna falla.

Por lo general, un marco le permitirá escribir componentes que encajarán en sus contenedores a través de la implementación de un contrato :

El contenedor entonces podrá manejar su código como una pieza de software compatible con el marco cuyo ciclo de vida se puede administrar, y lo llamará en los momentos que sean relevantes para realizar algún tipo de operación u otra.

Como puede ver, esta es una opción mucho más estructural que las bibliotecas para el diseño de su aplicación: todos sus componentes se vuelven específicos para ese marco. No será portátil (es decir, no lo entenderá otro marco) ni interoperable (es decir, un componente Angular difícilmente interactuará con un componente React).

Sin embargo, se puede argumentar que el patrón del adaptador podría usarse para limitar la dependencia del marco, tal como lo hicimos para limitar la dependencia de las bibliotecas:

Esto puede parecer útil... si la dirección de dependencia fuera la misma. Pero no lo es: los adaptadores de bibliotecas solían tomar la forma requerida por la aplicación, mientras que aquí los adaptadores de componentes solo pueden tomar la forma que espera el marco. Como resultado, el componente de la aplicación supuestamente "gratuito" solo puede imitar el contrato inicial (ciclo de vida, semántica, granularidad).

Dentro de los marcos, los adaptadores de componentes serían capas innecesarias entonces.

Bibliotecas marco

Las bibliotecas también pueden cumplir con los marcos. En lugar de proporcionar una API, proporcionan implementaciones de componentes para un marco determinado.

A medida que los marcos se hicieron populares, se dispuso de una serie de bibliotecas de marcos. Sin embargo, la mayoría de ellos son sobre widgets: por ejemplo, los componentes de Material Design se han portado de Android a Web Components , Angular , React , Vue e incluso marcos de iOS .

Marcos estándar

Cualquiera puede imaginar el tremendo costo de portar la misma biblioteca (y sus versiones posteriores) en cada uno de esos marcos.

IBM ha ideado una solución para esto : en lugar de portar Carbon Design System en cada uno de los marcos publicitados pasados, actuales y futuros, invirtieron en un puerto en el marco estándar de componentes web , que se puede utilizar en cualquier contexto.

Entonces, no solo esto permite usar sus componentes desde marcos:

Pero los mismos componentes también se pueden usar desde una aplicación simple:

Conclusión

Los marcos y las bibliotecas son opciones de terceros muy diferentes:

• Los marcos le brindan planos de aplicaciones con servicios integrados, pero imponen contratos predefinidos para llamar a su código. Como tales, implican una fuerte dependencia .
• Las bibliotecas no lo ayudarán a diseñar su aplicación, pero solo se pueden llamar cuando las necesite. Puede idear un diseño que limite la dependencia a ellos.