При поиске я обнаружил статьи, которые предлагают не использовать логику в * ngIf выражениях.
Я понимаю, чем автор статьи мотивировал , но я должен предупредить вас, что этот конкретный раздел, озаглавленный "Избегайте логики в шаблонах", является плохо сформулированным советом.
https://medium.com/free-code-camp/best-practices-for-a-clean-and-performant-angular-application-288e7b39eb6f
Если у вас есть какая-либо логика в ваших шаблонах, даже если это простое предложение &&, хорошо бы извлечь его из компонента.
Это не полностью верно.
Я бы не хотел бы поддерживать любые компоненты, разработанные человеком, который постоянно делал это. Их компоненты будут наполнены свойствами, и вы будете постоянно переключаться между файлом HTML и исходным кодом TypeScript, чтобы выяснить, что на самом деле представляет собой бизнес-логика .
Но в этом совете есть ценность, потому что он основан на проверенной практике для исходного кода в целом. Это практика, которая не относится к какому-либо конкретному языку программирования, а касается проблем if операторов в целом.
Например;
if(x > 1920 && y < 4 && p !== 'expand') {
// do work
} else {
// do work
}
В приведенном выше примере логическое условие невозможно понять. Выражение содержит неопределяемые переменные, магические буквальные значения и множественные условия. Мы также можем увидеть что-то подобное в угловом шаблоне как *ngIf="x > 1920 && y < 4 && p !== 'expand'".
Рекомендуемый подход состоит не в том, чтобы писать подобные условия, а в разбивке выражения на понятные человеку термины, объясняющие бизнес-логику.
Например;
const max_screen_size = 1920;
const min_device_count = 4;
const expanded_mode = 'expand';
const valid_screen = screen_size > max_screen_size && device_count < min_device_count;
const valid_mode = mode !== expanded_mode;
if(valid_screen && valid_mode) {
// do work
} else {
// do work
}
Вышеуказанное работает в большинстве языков программирования, но это трудно сделать в шаблонах Angular, потому что мы не можем вводить новые переменные.
Так что, я думаю, что автор рекомендует, чтобы вы добавили новые свойства в компонент, чтобы упростить бизнес-логику в шаблоне для чтения и поддержки .
Наличие логики в шаблоне означает, что его невозможно выполнить модульное тестирование, и поэтому оно более подвержено ошибкам при изменении кода шаблона.
Теперь это полностью false . Вы абсолютно можете модульные тестовые шаблоны в Angular. Вы можете проверить содержимое, условия и структуру. Понятия не имею, о чем он здесь говорит.
Мне кажется, он подразумевает, что наличие бизнес-логики в шаблонах делает компонент более подверженным ошибкам при изменении шаблона, но это глупый аргумент, потому что если вы переместите бизнес-логику к компоненту, который вы только что переместили, где ошибки склонны ...
Как я могу использовать эти утверждения для более чистого и качественного углового применения.
Попробуйте использовать функции шаблона, относящиеся к *ngIf, вместо простого добавления many , если условия. минимум используемая функция, которую я вижу в проектах, это условие else.
Например;
<div *ngIf="user_role === 'admin'>
Admin features
</div>
<div *ngIf="user_role !== 'admin'>
General features
</div>
Вышесказанное является проблемой, потому что теперь вы должны изменить два места, если бизнес-правила изменятся. Вместо этого используйте условие else.
Например;
<div *ngIf="user_role === 'admin; else general'>
Admin features
</div>
<ng-template #general>
General features
</ng-template>
Теперь есть только одно условие выше, и если вам придется изменить его, вы не пропустите второе условие по ошибке.
Кроме того, используйте as функцию ngIf для упрощения ваших шаблонов (прекрасно работает с async pipe).
Например;
<div *ngIf="data.user.permission">
<span>{{data.user.permission.title}}</span>
<span>{{data.user.permission.code}}</span>
</div>
Может быть переписано как:
<div *ngIf="data.user.permission as perm">
<span>{{perm.title}}</span>
<span>{{perm.code}}</span>
</div>