Лучшие практики для модулей расширяемого и модифицируемого узла (npm) - PullRequest
Новая
       15

Лучшие практики для модулей расширяемого и модифицируемого узла (npm)

1 голос
/ 15 июня 2019

Мне нужен совет от более опытных разработчиков javascript (машинопись) / nodejs.В течение нескольких месяцев я пытаюсь найти лучшие практики для создания расширяемых и модифицируемых модулей узлов (npm).

Для лучшего понимания: в большинстве сред PHP (таких как Symfony, Laravel, Nette) мы имеемDI-контейнер, который можно использовать для изменения или добавления собственной реализации для сервисов, поступающих из пакетов.Например.У меня есть пакет корзины, в котором реализован сервис для расчета цены корзины и применения налогов.Когда мне нужно изменить расчет налогов, я могу изменить реализацию через DI-контейнер, например, 

services:
      myTaxCalculator:
    class: MyTaxCalculator
      Package\Taxes\CalculatorInterface: ‘@myTaxCalculator’

, и теперь, когда пакет работает с Package \ Taxes \ CalculatorInterface, вместо реализации по умолчанию используется мой собственный калькулятор.

И я искал что-то подобное в javascript (машинопись) / nodejs.Если я собираю какой-либо пакет и в нем мне нужна функция для расчета налогов, используйте этот const taxCalculator = require ('...'), но теперь я не могу изменить реализацию этой функции.

Конечно, я могу сделатьПакет настраивается.Добавьте некоторый механизм для установки пользовательской функции для конкретных случаев, но я думаю, что мне нужна эта логика для всех классов / функций, которые используются в приложении, чтобы никогда не вызывать require ('кое-что').

Суть в том, чтобы построить базовый и стандартный пакет с логикой по умолчанию, которую можно изменить в конкретном приложении для решения проблем клиента, не создавая новый пакет с 90% -ным кодом.Я знаю, что существует некоторая реализация IoC / DI для javascript (typcript) / nodejs, например, InversifyJS, но я не уверен, когда это лучший способ для приложений javascript (typcript) / nodejs.Есть ли у вас опыт с этим?Как вы решаете эти проблемы?

Спасибо за любой ответ!

1 Ответ

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

Я бы не сказал, что я эксперт или «гуру лучших практик», но я думаю, что три сценария довольно распространены. Я не буду копаться в Inversify, потому что вы уже знаете об этом.

  1. Возьмите объект с конфигурацией в точке / классе функции входа. По умолчанию для вашей реализации. 
interface TaxCalculator { /* tax related stuff */ }

interface CalculateCartPriceArgs {
  taxCalculator: TaxCalculator,
  // probably lots of other stuff
}

export function calculateCartPrice({
  taxCalculator = defaultTaxCalculator
}: CalculateCartPriceArgs) {
  // implementation
}
  1. Плагины / промежуточное ПО.
  2. Разоблачить внутренности, чтобы позволить пользователю создать свою собственную версию вашей вещи.
...