S
В коде. Можно и без геттеров написать код, который будет тормозить. Не так разве?
с геттерами гораздо проще)
Size: a a a
2019 October 28
Вキ
с геттерами гораздо проще)
+ и с геттерами код ставится сложнее
AI
Ваше право не соглашаться. Я из своего опыта говорю, что мне в моей практике этот подход очень помогает и при грамотном использовании он не является проблемой в производительности. На примере геттера выше его надо переписать на чистую функцию и передавать зависимости на вход.
E
Да, эту тему не расписал, потому что и так большая статья вышла. В будущем обязательно напишу статью о производительности. Такой вариант, конечно, неверный, это лучше делать через пайп. Поставлю там коммент, чтобы не смущать народ.
на изображении фильтрация. фильтрацию лучше не делать через пайп.
AI
на изображении фильтрация. фильтрацию лучше не делать через пайп.
Почему?
E
Почему?
вернее не так, можно делать, но советуя делать фильтрацию через пайп, добавляйте, что данные должны быть иммутабельны а пайпы pure
E
иначе срань, простите, получится
AI
Да, всё верно.
E
+ в доке ангуляра написано, что пайпы для фильтрации в принципе использовать не рекомендуется
E
это размазывание логики
В
а для чего их тогда еще юзать?
YK
а для чего их тогда еще юзать?
когда тебе простенькое текстовое преобразование нужно
Y
+ в доке ангуляра написано, что пайпы для фильтрации в принципе использовать не рекомендуется
Может Я путаю, но фильтрацию ведь в основном на стороне сервера делают? Зачем эту логику выносить в целом на фронт?
AI
Одно время у меня был паттерн такой — был пайп, который на вход просто принимает функцию для фильтрации. Так логика не выходила в шаблон, а оставалась в компоненте и не пересчитывалась без изменений входных данных для фильтрации. То, что данные должны быть немутабельные и используется OnPush у нас просто априори, но в следующей статье обязательно отражу, спасибо за подмеченный момент.
E
Может Я путаю, но фильтрацию ведь в основном на стороне сервера делают? Зачем эту логику выносить в целом на фронт?
ну почему, бывают ситуации, когда фильтровать нужно на стороне фронта
E
Одно время у меня был паттерн такой — был пайп, который на вход просто принимает функцию для фильтрации. Так логика не выходила в шаблон, а оставалась в компоненте и не пересчитывалась без изменений входных данных для фильтрации. То, что данные должны быть немутабельные и используется OnPush у нас просто априори, но в следующей статье обязательно отражу, спасибо за подмеченный момент.
а зачем тогда пайп-то вообще? если есть функция в коде компонента, почему не засунуть ее в поток?
YK
Одно время у меня был паттерн такой — был пайп, который на вход просто принимает функцию для фильтрации. Так логика не выходила в шаблон, а оставалась в компоненте и не пересчитывалась без изменений входных данных для фильтрации. То, что данные должны быть немутабельные и используется OnPush у нас просто априори, но в следующей статье обязательно отражу, спасибо за подмеченный момент.
насколько часто такая штука вызывалась в процессе lifecycle?
E
насколько часто такая штука вызывалась в процессе lifecycle?
если данные иммутабельны, а пайп pure - то только тогда когда нужно
AI
Если у нас в пайпе функция как в том геттере, то только если поменялся пользовательский ввод, поменялся массив вариантов или поменялась функция привода варианта к строке.
YK
если данные иммутабельны, а пайп pure - то только тогда когда нужно
то есть onChanges?