А сейчас будет мой любимый вопрос, который я задаю на

собесах, чтоб узнать насколько побитый ангуляр дев. Что скорее всего случится после 30-ти использованных на одном уровне операторов внутри одного пайпа?

там типизация до 8 или 11 вроде всего

Там от сложности операторов зависит

И что же случится?)

следующие операторы будут Unknown возвращать. Типизация теряется. Чтоб это пофиксить достаточно написать второй pipe и продолжить в нем писать операторы

А почему так происходит?

Не написали тип на такое количество аргументов

Справедливости ради, если у вас больше 10 операторов в пайпе, стоит задуматься кмк

как завалить нормально разраба тупым вопросом, часть первая)

ну, это рейр-кейс, так что да, вопрос хорошо проверяет попадал ли человек в мясорубку😁

это бы первое, что я сказал :)

Выглядит как типичный случай "угадай какую глупость задумал интервьювер". Если что, вопросы должны раскрывать личность кандидата, а не интервьювера. А что касается "мясорубки", я никогда не встречал нескольких десятков операторов в одном пайпе, но видел вещи НАМНОГО хуже ) Так что лучше просто спросить про самый всратый код, который кандидат видел. И опыт покажет и сам что-то новое узнаешь )

Вещи намного хуже это что.

Это один из вопросов со звездочкой, за него минусов нету). Человек ответил - хорошо, пошли дальше, нет - ок, пошли дальше. Собеседование же не состоит из одного вопроса. Заучить, что такое пайп и что он по дефолту пьюр может каждый. А пару таких вопросов среди стандартных составляют хорошую картину о кандидате.

У меня на данный момент два фаворита: 1. Абстрактная директива, в которую заинжекчены ВСЕ сервисы, от которой унаследованы ВСЕ компоненты 2. Один шаблон, использованный в трёх разных компонентах (конечно же, на 2000+ строк)

блин, ну первое прям как классика

поищу у себя, как оказалось, у меня расположенность

Стикер

принят

Можно ваш контакт, пожалуйста

Уволен

Стикер

а все потому что поддержать этот код сложно

а чего сложного, если... если: - это директива, то есть апи в 1 токен + конфиг

нечитаемо

ну эту тему мы уже обсуждали эта штука инкапсулирвоана. раз ее читать надо, да, но! раскиданную по методом читать еще больше.два (это вам не архитектура, тут одно полезное действие) загрузить все в мозг нужно, да, но зато весь код и перед глазами и в одном месте и лишен абстракций.три

ненене. раскиданное по методам давало бы понимание. тут скроллим. тут после скролла что-то делаем и тд. а так портянка в которой надо разбираться

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

что значит понятно что делает, а править то надо, функционал директивы имеет выский cohesion (что к слову хорошо) и переплетение поведения и состояния максимальное в каждом методе, ничего не понятно

почему у тебя isCurrentElement принимает событие? вот чисто логически. берем событие и поясняем является ли оно текущим элементом? текущим куда? 🙃

нет, у тебя глаголом обозначен сам класс

ну во-первых, это очень спорный момент invokable классы часто используются dsl свой "псевдоязык" на счет глагола во-втрых скролл не только глагол, а и существительое