È meglio avere una singola direttiva più generale o più direttive di tipo multiplo in Angular?

-3

È considerata una buona pratica avere:

  1. Una singola direttiva generale che ha più dati * parametri e dati seriali è vincolata dal controllore
  2. Singola direttiva generale che ha dati di configurazione e seriali dal controller
  3. Direttive multiple che hanno alcune configurazioni predefinite all'interno della direttiva, alcune di configurazione sono dati- * parametri e dati seriali sono vincolati dal controllore

Ad esempio, ho un modello dovevo creare ~ 16 grafici (Highcharts / amCharts). Tutti loro non avranno la stessa configurazione e dati seriali.

Esempio di 1 opzione:

angular.module('myApp')
  .directive('ngHighcharts', () => ({
    restrict: 'AE',
    replace: 'true',
    scope: {
      data: '='
    },
    template: '<div></div>',
    link: function(scope, $elem, $attrs) {

      var chart, config;
      config = {
        chart: {
          renderTo: $elem[0],
          type: $attrs.type ? $attrs.type : 'bar'
        },
        exporting: {
          enabled: $attrs.exporting ? $attrs.exporting : false
        },
        title: {
          text: $attrs.title ? $attrs.title : ''
        },
        xAxis: {
          categories: $attrs.categories ? $attrs.categories : data[0]
        },
        tooltip: {
          valueSuffix: $attrs.valueSuffix ? $attrs.valueSuffix : ''
        },
        plotOptions: {
          bar: {
            dataLabels: {
              enabled: $attrs.dataLabels ? $attrs.dataLabels : false
            }
          }
        },
        series: scope.data
      };

      chart = new Highcharts.Chart(config);

      scope.$on('$destroy', function () {
        scope.$evalAsync(function () {
          chart.destroy ();
        });
      });

    }
   }));

Esempio di opzione 2:

angular.module('myApp')
  .directive('ngHighcharts', () => ({
    restrict: 'AE',
    replace: 'true',
    scope: {
      config: '=',
      data: '='
    },
    template: '<div></div>',
    link: function(scope, $elem, $attrs) {

      config.chart.renderTo = $elem[0];
      var chart = new Highcharts.Chart(config);

      scope.$on('$destroy', function () {
        scope.$evalAsync(function () {
          chart.destroy ();
        });
      });

    }
   }));

Esempio di opzione 3:

angular.module('myApp')
  .directive('ngHighcharts', () => ({
    restrict: 'AE',
    replace: 'true',
    scope: {
      data: '='
    },
    template: '<div></div>',
    link: function(scope, $elem, $attrs) {

      var chart, config;
      config = {
        chart: {
          renderTo: $elem[0],
          type: 'bar'
        },
        exporting: {
          enabled: true
        },
        title: {
          text: $attrs.title ? $attrs.title : ''
        },
        xAxis: {
          categories: $attrs.categories ? $attrs.categories : data[0]
        },
        tooltip: {
          valueSuffix: $attrs.valueSuffix ? $attrs.valueSuffix : ''
        },
        plotOptions: {
          bar: {
            dataLabels: {
              enabled: true
            }
          }
        },
        series: scope.data
      };

      chart = new Highcharts.Chart(config);

      scope.$on('$destroy', function () {
        scope.$evalAsync(function () {
          chart.destroy ();
        });
      });

    }
   }));

Quale sarebbe la migliore pratica in questa situazione?

    
posta Abdizriel 26.12.2015 - 17:44
fonte

1 risposta

1

Dipende davvero dal caso d'uso. Descrivi una direttiva per grafici. A prima vista, la sua configurazione sembra abbastanza statica. Cioè, puoi configurarlo per visualizzazione e non pensarci due volte. In tal caso, la configurazione basata su attributi è carina. Accoppiato con alcune impostazioni predefinite sensibili, riduce notevolmente le parti mobili dall'esterno della direttiva.

Il fatto è che raramente la vita è così semplice (o giusta). Immagina che il tuo capo arrivi un'ora prima della fine del lavoro di venerdì. È appena arrivata da una riunione di azionisti del progetto ed è stata resa cieca dal presupposto che i venditori potevano configurare i report (inclusi i grafici) come ritenevano opportuno. Ciò rende la tua configurazione basata sugli attributi non solo errata, ma meno semplice da "aggiustare". (Non chiamerò una vera correzione dal momento che è un nuovo requisito.) Se la configurazione fosse sempre stata data, sarebbe concettualmente semplice cambiare l'origine dei dati. (Non importa che ci siano nuove UI da costruire e ora ti mancherà l'Happy Hour allo Stumble Inn.)

Quindi, è un compromesso come tutto il resto. È flessibilità versus semplicità. La flessibilità è sempre interessante, ma il suo costo è la complessità. Devi decidere cosa apprezzi. Non puoi ottenere qualcosa gratuitamente. Ricorda TANSTAAFL .

    
risposta data 27.12.2015 - 07:13
fonte

Leggi altre domande sui tag