Слияние перечислений с методами - PullRequest
Новая
       11

Слияние перечислений с методами

2 голосов
/ 03 июня 2019

Мне показалась полезной практика объединения перечислений с пространствами имен.пример: 

enum Status : {
    OK = 1,
    NOT_OK = 2,
}

namespace Status {

    function Color(status : Status) {

        if(status == Status.OK)
            return 'green';
        else
            return 'red';

    }

}

Но я обнаружил, что tslint не любит их ... Какие другие методы я могу использовать вместо этого, чтобы получить такое же поведение?Я думал о замене пространства имен в классе статическими методами, но у него есть два недостатка:

1) Класс должен получить другое имя (например, StatusUtil) - хорошо, я могу жить с этим...

2) Класс StatusUtil (в отличие от пространства имен) не может быть вызван напрямую из HTML-файла при использовании Angular - это означает, что мне нужно написать дополнительные методы в каждом компоненте, что-то вроде этого: 

getColor(status : Status) {
    return StatusUtil(status);
}

Другой вариант, о котором я подумал, - это использование инжекции зависимости от угла вместо статического метода.Как вы думаете, будет лучшей практикой?

1 Ответ

2 голосов
/ 03 июня 2019

Я думаю, что это хороший случай, чтобы отключить предупреждение от tslint.Tslint должен указать на возможные проблемы с вашим кодом, но вы можете устранить их в коде с помощью комментария.

Существует правило, запрещающее использование пространств имен для организации кода, но в Typescript все еще есть сценарии, объединяющиеможет быть достигнуто только с использованием пространств имен.

Непосредственно из weswigham (член команды ts) в комментарии :

Объединяется ли пространство имен с классом,функционируют и перечисляют «хорошее» использование пространств имен?

Иногда - поскольку мы не можем распознать специальные вложения определенных типов статических свойств, это может быть оправдано - во многих случаяхОднако будет достаточно hoc-свойства для функции или статического класса (если только вам не нужно, чтобы оно содержало типы).Хотя вопрос о том, действительно ли вам нужно было начать слияние, так же уместен - если, например, вы хотите связать компонент и его тип аргумента, не достаточно ли экспортировать оба из одного и того же модуля?Зачем также заключать их в пространство имен?Там нет никакого смысла.

Это сводится к следующему:

Если вы планируете использовать пространства имен для организации кода: Не .Модули включили эту роль.Если вам нужна функциональность, которую могут обеспечить только пространства имен: Выполните , но убедитесь, что не выразительно выражать концепцию без пространства имен (например, со статическим или функциональным свойством класса или реэкспортированным модулем).Это также плохой стиль для смешивания пространств имен и модулей в одном проекте - это просто нехорошо, так как одной из основных особенностей пространств имен в традиционном смысле является слияние областей между файлами, которое не происходит в разных модулях (так какЯ сказал, что сам модуль на самом деле является пространством имен.)

Также в этом потоке пространства имен не будут удалены из языка, поэтому их использование в определенных сценариях вполне допустимо.

...