Una directiva es mejor (como regla general) cuando es corta (en cuanto a código), (potencialmente) reutilizable, y tiene un alcance limitado en términos de funcionalidad. Hacer una directiva que incluye la interfaz de usuario y depende de un servicio (que supongo que maneja la conexión con el backend), no solo le da 2 funciones funcionales, a saber:
- Controlar la interfaz de usuario para la visualización / entrada de datos para el widget.
- Envío al backend (a través del servicio).
pero también lo hace menos reutilizable, ya que no puede volver a usarlo con otro servicio o con una IU diferente (al menos no fácilmente).
Al tomar estas decisiones, a menudo me comparo con los elementos HTML integrados: por ejemplo <input>, <textarea>o <form>: son completamente independientes de cualquier backend específico. HTML5 le ha dado al <input>elemento algunos tipos adicionales, por ejemplo date, que aún es independiente del backend, y dónde van exactamente los datos o cómo se usan. Son puramente elementos de interfaz. Sus widgets personalizados, construidos usando directivas, creo que deberían seguir el mismo patrón, si es posible.
Sin embargo, este no es el final de la historia. Yendo más allá de la analogía con los elementos HTML incorporados, puede crear directivas reutilizables que llaman a los servicios y usar una directiva puramente de interfaz de usuario, al igual que podría usar a <textarea>. Digamos que quiere usar algo de HTML de la siguiente manera:
<document document-url="'documents/3345.html'">
<document-data></document-data>
<comments></comments>
<comment-entry></comment-entry>
</document>
Para codificar la commentEntrydirectiva, puede crear una directiva muy pequeña que solo contenga el controlador que vincula un servicio con un widget de interfaz de usuario. Algo como:
app.directive('commentEntry', function (myService) {
return {
restrict: 'E',
template: '<comment-widget on-save="save(data)" on-cancel="cancel()"></comment-widget>',
require: '^document',
link: function (scope, iElement, iAttrs, documentController) {
// Allow the controller here to access the document controller
scope.documentController = documentController;
},
controller: function ($scope) {
$scope.save = function (data) {
// Assuming the document controller exposes a function "getUrl"
var url = $scope.documentController.getUrl();
myService.saveComments(url, data).then(function (result) {
// Do something
});
};
}
};
});
Llevando esto al extremo, es posible que nunca necesite tener un ng-controlleratributo manual en el HTML: puede hacerlo todo utilizando directivas, siempre que cada una tenga directamente una función clara de "interfaz de usuario" o una función clara de "datos".
Hay un inconveniente que debo mencionar: le da más "partes móviles" a la aplicación, lo que agrega un poco de complejidad. Sin embargo, si cada parte tiene un papel claro y está bien (unidad + E2E probado), diría que vale la pena y que es un beneficio general a largo plazo.