Какие факторы влияют на размер пакета продукта, а не на компиляцию и сборку для организации по сценарию ниже? - PullRequest
Новая
       52

Какие факторы влияют на размер пакета продукта, а не на компиляцию и сборку для организации по сценарию ниже?

0 голосов
/ 26 июня 2019

Каковы оптимальные методы организации компонентов, сервисов в сценариях beolw.

В наших продуктах 70-80 компонентов, и каждый компонент имеет одну инъекционную сервировку.

и максимум все параметры выпадающего списка получают динамически через API

означает 

  AComponent - Aservice,
  BComponent-Bservice,
  CComponent-Cservice
  DComponent-Dservice..................

Случай: как я уже говорил выше, все выпадающие списки являются динамическими средствами и AComponent впрыскивает Aservice, Bservice, Dservice и т. Д.

Текущий код теперь организован так, как показано на обещаниях 

 class Acomponent {
  constructor(private aservice: Aservice, private bservice: Bservice, private dservice: Dservice....) {}
  ngOnInit() {
   this.loading = true;
   this.aservice.getAData().then(res => {
    this.bservice.getBData().then(res => {
     this.cservice.getCData().then(res => {
      this.loading = false;

     })
    })
   })
  }
 }

 Aservice:
  class Aservice {
   getAData() {
    return this.http.get(appSettings.apiUrl + '/RMAN_PRODUCTS')
   }

   class Bservice {
    getBData() {
     return this.http.get(appSettings.apiUrl + '/RMAN_CUSTOMES')
    }

    class Cservice {
     getCData() {
      return this.http.get(appSettings.apiUrl + '/RMAN_PRICELIST')
     }

    }

appsettings.ts 

 export var apiUrl = 'http://localhost:8081/api';

В приведенном выше случае все являются независимыми сервисными функциями, между ними нет зависимости. Одна вещь, которую нужно помнить после получения всех данных от всех API, только мне нужно загрузить страницу, и в apiurl в http, пока номер порта одна постоянная переменная, используемая после этого маршрута, жестко задана

Итак, я хочу очистить код, используя угловое ответвление , используя подписчиков. в нижеприведенных решениях, что является лучшей практикой

Solution1: в самом компоненте используйте fork join 

   class Acomponent {
    constructor(private aservice: Aservice, private bservice: Bservice, private dservice: Dservice....) {}
    ngOnInit() {
     this.loading = true;
     forkJoin(
      this.aservice.getData(),
      this.bservice.getBData() this.cservice.getCData()
     )
     responses.subscribe(res => {
      console.log(res) // [{}, {}, {}] // lenght 3
     })



    }
   }


   Solution2:
    (a) class Aservice {
     getData() {
       return forkJoin(this.http.get(appSettings.apiUrl + '/RMAN_PRODUCTS/producttype="xoc"',
          this.http.get(appSettings.apiUrl + '/RMAN_CUSTOMES/customertype="bix"'
           this.http.get(appSettings.apiUrl + '/RMAN_PRICELIST')
          }
         }
         (or)
         (b) apiurls.ts
         export var apis = {
          produts: '/RMAN_PRODUCTS/RMAN_PRODUCTS/producttype="xoc"',
          customers: '/RMAN_CUSTOMES/customertype="bix"',
          pricelist: '/RMAN_PRICELIST'
         }
         A.service.ts

         class Aservice {

          getData() {
            return forkJoin(this.http.get(appSettings.apiUrl + apis.produts: ,
               this.http.get(appSettings.apiUrl + apis.customers:
                this.http.get(appSettings.apiUrl + apis.pricelist)
               }
              }
              class Acomponent {
               constructor(private aservice: Aservice) {}
               ngOnInit() {
                this.aservice: getData().subscibe(res => {
                 console.log(res) // [{}, {}, {}] // lenght 3
                })
               }

Замечания

Во всех компонентах 

 . Above two approaches are doing same but my dought is which will be better and best practice? and why?

 . with  solution1 there is less work modify code in all components(60-80)

 . In solution 2 (a), (b) we can remove services like Bservice, Cservice from componentA

 . with Solution 2 (a) api urls are hard coded, twise, thires if required more time time .

Мой менеджер сказал, что меньше шансов изменить значения параметров в API, как например: '/RMAN_PRODUCTS/RMAN_PRODUCTS/producttype="xoc"' // "xoc"(parameter)

. Но даже я думаю, что если я буду следовать подходу secode (решение 2 (b)), даже если я изменю param или route, его «очень легко и меньше времени потребуется для его изменения) 

 >Doubts:::
   1. Inject the services in componets is the good approch or not ?
   2. Is many services injcetion will take more time to bundle and comipe?
   3. Which solution is good and why in your words with clear explation?

 Please help me, Before Going to work I want to consider all facts. 

  Thanks in advance
...