Эта статья предназначена для обучения реализации многоразового конвейера, который вы можете использовать в своих компонентах настраиваемой таблицы для выполнения таких вещей, как фильтр по столбцам и фильтр всех данных.
import { Pipe, PipeTransform } from '@angular/core';
Импорт - это то, что необходимо для начала, Pipe - это класс, которым вы аннотируете свой преобразователь, чтобы код знал, а PipeTransform - это интерфейс, который реализует ваш код,
transform() // method in PipeTransform Interface
мы будем называть нашу трубу «Поиск», потому что это то, что она делает.
Здесь функция преобразования принимает записи, которые представляют собой весь набор данных в JSON, keys - это массив ключей, на основе которых вы будете использовать фильтрацию, searchKey будет фактической строкой поиска, а searchCriteria - ключом из всех ключей поиска для выполнения поиска по столбцам.
<tr *ngFor="let row of rows | search : ['name', 'description']: searchKey : 'name'; (click)="select($event, row)">
здесь searchKey имеет двустороннюю привязку к TextBox, следующие строки таблицы будут отфильтрованы в соответствии с именем, теперь все, что введено в текстовое поле, будет запускать функцию onSearchKeyChange.
Функция onSearchKeyChange имеет очень простую логику, нам нужно передать имя ключа в таблице, к которой был применен поиск, как только значение существует, searchCriteria теперь будет назначен новому SearchText, предоставленному из текстового поля в поиске по столбцу. и searchkey также будут присвоены значению, указанному в текстовом поле.
если значение не изменилось, то searchCriteria будет удален, т.е. когда поисковые запросы будут очищены или страница будет обновлена.
Вот как мы создаем собственный чистый канал, но что именно такое чистый канал,
чистый канал - это канал, который запускает изменения только при изменении модели, а не наоборот, другими словами, канал, который мы создали можно также записать как,
@Pipe({
name: 'search',pure: true
})
В нашем случае канал будет вызывать изменения фильтра только в том случае, если значения в searchCriteria viz. столбец таблицы отличается от значения, существующего в searchCriteria любого другого столбца, например,
Эта таблица содержит 2 значения, INDIA-1 и INDIA-2. Если я предпочитаю искать INDIA-1, как только пользователь вводит INDIA-1, останется только 1 строка с описанием как searchCriteria,
Теперь, принимая во внимание картинку и для ясности, параметры, которые мы передали нашей трубе:
записи: все записи в таблице, по-видимому, JSON,
ключи: - это столбцы, украшенные текстовым полем, в нашем случае это [имя, описание ],
searchKey: будет «INDIA-1» в описании,
searchCriteria: В нашем случае критерием поиска в настоящее время будет описание как пользователь вводит searchKey в описание.
Как только пользователь выполняет INDIA-1, остается только 1 строка, теперь, если пользователь выполняет фильтр по имени, он должен фильтровать отфильтрованные строки на основе имени сейчас,
Что ж, это ожидаемо, но и большая часть о сохранении нашей трубы » search » заключается в том, что изменения модели будут инициированы только в соответствии с методом onSearchKeyChange, когда значение модели действительно отличается.
Однако в этом случае это может быть не очень полезно для нас, поскольку мы действительно хотим, чтобы наши данные возвращались, как только пользователь удаляет строки поиска из столбцов критериев, но вместо этого происходит следующее:
Когда пользователь удаляет значение из описания, он делает значение searchCriteria равным «» (пустая строка), что теперь происходит, когда пользователь удаляет строку поиска и из другого столбца поиска. Как мы и предсказывали, данные действительно вернулись, поскольку текущие критерии поиска, которые были пустыми, на самом деле отслеживаются на предмет изменений, когда мы удаляем значение в столбце имени, поиск превращает значение в пустую строку, которая уже является существующим значением searchCriteria .
Я знаю, что это очень подробное описание проблемы, но это только для ясности случая, когда мы пытаемся избежать использования нечистых каналов, которые легко объявить, единственная разница заключается в объявлении,
@Pipe(
{
name: 'search',
pure: false
}
)
Знаете, что мы используем , когда используем нечистую трубку? но давайте поговорим о том, почему нам не следует использовать нечистые каналы, ответ прост, ради производительности. История, которую вы все читаете, - это хитрость, нечистые трубки обеспечат вам результат, который не запутан, но не полезен для здоровья, на самом деле, наоборот, как angular 2 оптимизировал часы и увеличил их количество. из них, которые могут вызвать снижение производительности. Нечистые каналы вызывают изменения и вызывают преобразование () для каждой вещи, если текстовое поле щелкает, зависает, фокусируется или размывается.
поместите отладчик в функцию преобразования и проверьте сами.
Как только вы нажмете текстовые поля в столбцах, код начнет останавливаться в отладчике,
Даже в случае размытия, фокуса и фокусировки код остановится на отладчике, поскольку он все время вызывает функцию преобразования.
Любое значение будет запускать изменение, и каждое изменение отслеживается, что делает сделку техническим долгом. Однако, если объем данных меньше, а страница более простая, то не повредит использовать нечистую трубу.
Подробнее см. Https://angular.io/guide/pipes
Надеюсь, статья была полезной. Если вы сочли ее полезной, нажмите «хлопать» и оставьте свои предложения ниже в комментариях. Чао!
