Comments 63
"главный вопрос" - не такой уж устаревший. При использовании useSelector тоже все селекторы вызываются, если поменялся стейт в редуксе.
Какой первый параметр принимает connect
Считаю что на подобные вопросы кандидаты уровня мида и выше могут с уверенностью отвечать "не помню, щас загуглю".
Лично я бы такой вопрос даже не задавал. Лучше узнать умеет ли человек спроектировать хранилище данных впринципе и начать задание примерно с середины статьи, в ключе "нужно сделать страничку со списками пользователей, питомцев и квартир с возможностью удаления элементов списка. Реализуйте в том, в чем вы уверенно себя чувствуете"
Мне как собеседующему важнее понять умеет ли человек в то о чем он рассказывает (в резюме, например) и как он будет рассуждать, решая подобные задачи, какие сценарии он предусмотрит (те же чрезмерные обновления стейта или вызовы функций без мемоизации или подписки на изменения).
А зазубренное знание API и кишочков конкретного фреймворка - очень ограничивает интервьювера в объективности оценки да и в понимании кандидата в целом.
Принцип работы стоит знать, это же основной инструмент. Я много раз видел, как в корневом компоненте в useSelector возвращают объект, который не меморизируется, из-за этого обновляется все дерево компонентов, это создаёт тормоза на больших приложениях.
Но нужно ли такое задавать на собеседовании, тоже не уверен. Разве что в контексте "проведите ревью кода", и в одну из проблем вставить эту. Тот, кто сталкивался/знает, сразу обратит внимание.
Каждая команда нуждается в разных специалистах, но обратите внимание на это:
Тот, кто сталкивался/знает, сразу обратит внимание.
Если выбирать специалиста по критериям вроде "сталкивались ли вы с вот такой проблемой" - будет очень трудно либо найти подходящего человека, либо если человек найдется, но окажется крайне специфичным, неспособным решать разнообразные задачи. Но зато заточенным под конкретные несколько навыков. Такие люди приходят и уходят, а процесс найма и введения нового человека в дела - дорогое и долгое удовольствие.
если человек найдется, но окажется крайне специфичным
Пример с созданным на лету и незамемоизеным объектом абсолютно типовой (как для реакта, так и для js в целом), и это может заметить даже чел, который новичок в реакте, но толковый и шарит в js.
сталкивались ли вы с вот такой проблемой
Если человек долго писал на redux, то точно сталкивался и запомнил до конца жизни. Это не мелочь, а один из ключевых моментов технологии. Ну либо это свидетельство того, что человек вообще не вникает в то, чем он занимается. Такой человек будет головной болью.
Просто интервьювер должен заранее выяснить, область компетенции кандидата и задавать ему соответствующие вопросы. Например, если человек долго пишет на MobX или Vue, я спрашиваю:
- Опишите, пожалуйста, в двух словах как работает паттерн observable
Если он даёт хороший ответ, я спрошу:
- А как бы вы реализовали механизм tracking dependencies (в двух словах)
Если отвечает на оба, то видно, что с таким человеком можно сварить кашу. Можно уйти в отпуск и оставить его за главного. Если же нет, то пристальное внимание на каждом MR.
Если есть тестовое задание, то лучше оставить выбор технологии на выбор кандидата. Мне присылали решения, где человек руками писал EventEmmiter и строил вокруг него свой микро-фреймворк. Не трудно догадаться, что к такому кандидату особо пристальный интерес.
А если человек со всем работал, ничего толком не помнит, нигде ни во что не вникал, умеет строить простые формочки на чём угодно… А последние два года писал micro-services с "кафкой", так что даже синтаксис JS\TS забыл и цикл написать не может… То может быть чувак и хорош, но это как минное поле.
А можно ваш ответ на оба этих вопроса (в двух словах)?
А можно ваш ответ на оба этих вопроса (в двух словах)?
Простейшая имплементация:
- пишем класс
- у класс есть массив:
subscriptions: (() => void)[] - есть значение
value: T - есть метод задающий значение
setValue(newValue: T): void - есть метод для получения текущего значения
getValue(): T - есть метод для подписки:
subscribe(fn: () => void): void - при подписке
fnзаносится вsubscriptions - при установке значения оно записывается в
this.valueи всеthis.subscriptionsвызываются (уведомляются об изменении значения) - ещё можно отписаться
- всё
Эту простую схему можно многократно усложнить. И добавить сахару. Например посредством proxy, или get-set-ов. Или как в Knockout-е за счёт того что сам observer это метод. Но это уже не основы, а немного дальше.
По 2-му вопросу — в самом простом случае имеем глобальный массив, куда записываем все затронутые чтения observables. По окончанию вычисления computed-метода просто автоматически на них подписываемся. Ну и не забываем отписаться от предыдущих лишних observables, т.к. их число могло измениться. В самом упрощённом виде он так и работает.
Мне присылали решения, где человек руками писал EventEmmiter и строил вокруг него свой микро-фреймворк. Не трудно догадаться, что к такому кандидату особо пристальный интерес.
Я когда-то писал стейт-менеджер и успешно использовал его в парочке проектов, да и другие вещи писал. Но вот в тестовом не стал бы использовать (хотя сейчас и на тестовое не стал бы тратить время). В мире, в котором я живу, использование самописных решений вместо популярных готовых считается признаком неопытности.
В мире, в котором я живу, использование самописных решений вместо популярных готовых считается признаком неопытности.
Это потому что уровень подавляющего числа разработчиков низкий и крайне низкий, поэтому если вы среди них выделяетесь, то вы для них белая ворона которая сошла с ума. Но на самом деле проблема не в вас, а в них) Не стоит падать до их уровня и ставить крест на том, где у вас есть реальная предрасположенность и вы одарены, а для них это лишь промысел за который они получают ЗП выше чем на кассе в магазине. Если вы считаете что ваш подход, ваше решение, ваша архитектура лучше чем то, что сейчас в основном применяется, то это нормально и 99% ваше версия и правда будет лучше, т.к. всё общепринятое обычно рассчитано на, что по максимуму загнать в угол джунов и не давать сделать шаг влево/вправо.
использование самописных решений вместо популярных готовых считается признаком неопытности
На самом деле это неплохой фильтр со стороны кандидата. Если интервьювер на полном серьёзе гонит на то, что вы вместо того, чтобы задействовать условный Vue, реализовали его сами, то это отличный повод им не перезвонить ;-)
это же основной инструмент
Что? Основной инструмент? Redux давно умер, по инерции до сих пор кто-то его юзает конечно из-за незнания альтернатив. А все нормальные люди уже много лет используют MobX.
А все нормальные люди уже много лет используют MobX.
На прошлом проекте 1.5 года использовали mobX, не понравилось)
И все новые вакансии, почему просят Redux. Вероятно не так уж и умер)
А в комментариях под моими видео, уже фанаты Effector во всю просят сделать видосы на эту тему. Так что даже и не знаю, что будет в будущем
Сбер, Яндекс, Ржд, ещё несколько крупных банков. Везде redux, часто с тулкитом или рематчем.
Проста, удобство и предсказуемость
1.5 года использовали mobX, не понравилось)
Почему не понравилось? Субъективно, или были какие-то проблемы с мобиксом в конкретных случаях? Не холивара ради, а просто интересно )
Я думаю, об этом в будущем написать. Там много мелких моментов:
- возникла проблема потери контроля над рендерингом. Там observer управляет обновлять компонент или нет. В итоге при обновлении версии mobX. У нас приложение не запустилось. Т.к. порядок рендеринга компонентов изменился и наш код к такому не готов. Это было очень стремно. Мы не знали где еще отломится.
- нет best practice. Ребята из командыы начали активно продвигать идею использовать активно подписки, чтобы реагировать на все. В итоге, опять вышла потеря контроля, над тем в каком порядке код выполняется. И зачастую выполняется лишний код, который в такой ситуации не нужно реагировать.
- идеалогия не декомпозировать стор, а прокидывать весь стор в компоненты, так же накладывает сложности
- опять же отсутствие бест практис. И предыдущая команда в сторах хранила не только данные а и всю бизнес логику. Приложение было очень связанным и в итоге сторы уже включали часть логики других сторов.
- с памятью проблемы начались. То инстансы где то в реакциях зависали, то реакцию повесить можно внутри например User. И если юзеров кол-во растест сильно, то реакции тоже сильно растут и мы сравнивали сколько памяти это съедает
Я думаю, об этом в будущем написать.
Интересно будет почитать. В идеале - с компактными примерами, иллюстрирующими суть проблемы.
Все что вы описали это проблемы чисто в вас и вашей команде как разработчиков, не достаточно опыта, не достаточно квалификации и т.п. Ни одной проблемы связанной с MobX'ом нету, только проблемы вытекшие из вашего кода и подхода. Если не думать головой, то можно и забивая гвоздь в доску пробить себе голову)
И предыдущая команда в сторах хранила не только данные а и всю бизнес логику. Приложение было очень связанным и в итоге сторы уже включали часть логики других сторов.
Почему-то не получилось добавить коммент к вашему видео. В общем, если интересно, можете взглянуть на пару последних моих статей на хабре. Использую небольшие сторы только для данных и работой с этими данными (чтение/запись). Поток данных как в redux, но нет этих избыточных actions и dispatch. Пришел к такой архитектуре до того, как стал использовать Mobx, но она хорошо применима к нему и не только.
Ну а так, согласен, что из-за отсутствия best practices у большинства получаются раздутые сторы с хаотичными связями и потоком данных.
Ребята из команды начали активно продвигать идею использовать активно подписки, чтобы реагировать на все. В итоге, опять вышла потеря контроля, над тем в каком порядке код выполняется. И зачастую выполняется лишний код, который в такой ситуации не нужно реагировать.
Не понял про идею, но по-моему, сейчас это стандартная ситуация практически на любом проекте с хуками) Обязательно в проекте присутствуют компоненты с несколькими хуками, у которых по несколько переменных в массиве зависимостей. И получается, что компонент зависит от нескольких десятков переменных. Ну и обычное дело, когда при вводе в input обновляется вся форма.
Это случаем не вы https://habr.com/en/users/MaZaAa/? :)
А зазубренное знание API и кишочков конкретного фреймворка
Я думаю это вопрос для тех, кто "да я на redux собаку съел". От такого человека ожидаешь понимания, используемой им технологии. Если же человек, претендующий на архитекторскую позицию, говорит, что годами пишет на redux, но не знает таких элементарных вещей (которые описаны в этой статье), то он или вам нагло врёт, или его познания ниже плинтуса. Вы не можете писать на redux хоть сколько-нибудь адекватный код не зная этих вещей.
Т.е. речь идёт не о знании кишочков конкретного фреймворка, а проверка на общую адекватность человека, которые заявляет что использует redux в своей практике широко.
Можно ответить:
- я плохо помню, давно писал на redux, с тех пор столько воды утекло
И тогда к нему никаких претензий. Но такого человека наверняка спросят:
- скажите, а с какой технологией вы работали наиболее плотно?
- гхм… rxJS
- хардкорный вопрос по rxJS
хардкорный вопрос по rxJS
Это если собеседующие шарят в rxJS. Так что, тут как повезет.
Если же человек, претендующий на архитекторскую позицию, говорит, что годами пишет на redux, но не знает таких элементарных вещей (которые описаны в этой статье),
У каждого своя шкало и матрица компетенций, но по-моему, архитекторы впринципе не должны отвечать на вопросы по параметрам функций конкретного фреймворка - они должны знать преимущества и недостатки такого фреймворка максимум. Решение задач "как написать код оптимально" и "как удовлетворить документированные и недокументированные запросы клиента при этом не выкопав себе яму на будущее" - разного уровня компетенции. И знания тут нужно оценивать разные. Ну да я отвлекся.
В остальном - да, именно то что вы написали - если человек заявляет что лучше всего владеет redux, то имеет смысл. Но опять-таки, смотря на каком уровне - сениора я бы больше проверял на решение сложных задач и широту познаний. Грубо говоря "не писал, но щас разберемся" - приемлемый ответ.
хардкорный вопрос по rxJS
Опять же, хардкорные вопросы на знание конкретных инструментов позволят узнать сколько в последнее время кандидат _писал код_ с использованием данного инструмента. Часто сениоры не столько пишут код, сколько планируют проект, обсуждают архитектуру решения, интервьювят, лидят пару человек на небольших проектах, менторят людей и решают сложные проблемы вида "вот у нас перформанс резко падает и никто не знает как оно воспроизводится". Но опять же, у каждого свое видение сениора.
сениора я бы больше проверял на решение сложных задач и широту познаний
По сути вопрос в статье как раз из той самой широты познаний. Просто оформлен по тупому (заход через аргумент функции). В react и redux балом правит иммутабельность. На её основе делается мемоизация, что является в них краегоульным камнем производительности и построения архитектуры.
Вот вы пишете:
они должны знать преимущества и недостатки такого фреймворка максимум
Не зная всего того ^ человек не сможет рассуждать о преимуществах и недостатках. Откуда ему знать о проблеме O(n) подписчиков в redux, чтобы не взять его в проект, если он не понимает, как в общих чертах, работает redux. Откуда ему знать о паттернах проектирования React приложения, если он не знает как работает context в React (а к нему те же вопросы). Как человек сможет выстроить архитектуру на mobX или Vue, если observables для него магия.
Т.е. это не вопрос вида: каков 2-й аргумент в parseInt и для чего он нужен? А скорее: что такое индексы в РСУБД и как ими пользоваться? Просто автор вместо прямого вопроса в лоб, решил зайти издалека, взяв конкретную функцию и контр-примеры к ней.
решают сложные проблемы вида "вот у нас перформанс резко падает и никто не знает как оно воспроизводится"
Не может человек решать такие вопросы не зная основ того, чем он пользуется.
Не может человек решать такие вопросы не зная основ того, чем он пользуется.
Могут и решают. Локализация проблемы перформанса никак не зависит от основ.
Моя практика показывает, что люди без основ не могут двух циклов связать, какая уж там локализация проблем перформанса. А попытка ими дебажить сторонний код чужой библиотеки обречена на провал, ибо буквы в коде видят, смысла за буквами не видят. В общем не согласен с вами. Не могут и не решают.
Вообще я очень удивлён увидеть на хабре позицию, что не нужно знать как работают твои инструменты.
Ну, я просто говорю про примеры, которые видел в жизни, что ваше категоричное заявление противоречит моей наблюдаемой реальности.
Не может человек решать такие вопросы не зная основ того, чем он пользуется.
Я видел, как решаются такие проблемы без понимания глубоких основ- через поиск боттлнека (дебажа библиотеки и понимая смысл) и гугления возможных проблем. Уже после этого человек приобретал более глубокое знание.
Потратил ли человек больше времени, чем тот, кто вызубрил от и до свою технологию- в подавляещем большинстве да. Однако он может и решает проблемы перформанса.
Вообще я очень удивлён увидеть на хабре позицию, что не нужно знать как работают твои инструменты.
Я этого не писал, вы за меня что-то придумали, но этому я не удивляюсь. Моя позиция в том, что для среднестатистического мидла/сеньора не обязательно знать досконально на 100% свою технологию, как выше уже писали "кишки", что бы выполнять свои задачи.
Моя позиция в том, что для среднестатистического мидла/сеньора не обязательно знать досконально на 100% свою технологию, как выше уже писали "кишки", что бы выполнять свои задачи.
Мне кажется вы делаете подмену понятий. "знание основ" и "знать досконально на 100% свою технологию". Это две разные вещи.
Если привести аналог на языке JS, я бы сравнивал свой вопрос, как "Как работает всплытие событий?". Нам так или иначе приходится с этим взаимодействовать. Без глубоких знаний можно ли решить эту проблему. Конечно можно. Загуглить на stackoverflow что-то, вставить и вуаля заработало! Нужен ли мне на позиции Senior JS developer, такой человек. Мои проекты чаще всего очень сложные и такие люди без основ будут отнимать у меня много времени.
А если говорить, про 100% знания языка. Я мог бы спросить про то как работают генераторы в JS. Насовать кучу примеров. Я ведь этого не делаю. Я ожидаю от кандидата, что бы он умел решать базовые задачи уверенно, а не кое как с гуглом и вопросами справился. А потом еще на ревью 3 раунда переделывал
Я мог бы спросить про то как работают генераторы в JS.
У меня был случай, когда коллега для того чтобы задать 3 разных classNames в props, исходя из 3 разных boolean флагов, написал генератор. А потом ещё тесты на генератор.
Т.е. условный:
[a && 'a', b && 'b', c && 'c'].filter(Boolean).join(' ');превратился в 70+ строк кода в двух файлах :)
Мои проекты чаще всего очень сложные и такие люди без основ будут отнимать у меня много времени.
Мне было бы интересно услышать о ваших проектах и/или в чем их сложность? Как и где искать такие проекты и как туда попасть?) Я понимаю, что есть сложные проекты, но я за почти 10 лет работы веб-разработчиком только один свой проект могу назвать сложным. В других если и была сложность, то только по причине большего количества спагетти кода на момент моего прихода. Собеседования были гораздо сложнее, чем сами проекты.
Если брать из последних проектов то было следующее:
- мессенджер (конкурент телеграмам вайберам и т.д.). Это один из самых сложных для фронтендера проектов в принципе
- проект состоящих из двух проектов. При том каждый проект как в браузере так и на React Native. И нужно было выделить пере используемые части в lerna. Что-то пере используется между браузером и мобилкой. Что-то между двумя RN проектами. Что-то между двумя браузерными проектами. Я активно принимал участие в проектировании этой архитектуры.
- создание платфомы кодовой базы, через lerna. У продукта есть запрос, выпускать десятки похожих проектов, с немного отличающейся бизнес логикой. Поэтому нужно создать своеобразный конструктор.
Как их искать. Ну... я при поиске всегда обсуждаю, чтобы проект был хардовый. В итоге соглашаюсь, только на те проекты, где мне кажется, что будет очень увлекательно девелопить
Спасибо!
Месседжер - довольно интересно.
А вот с lerna не знаком, поэтому сложно представить. Конструктор для этого - имеется ввиду на формах сделанный?
Нет. Это значит весь твой проект состоит из npm пакетов. Представь, что у тебя есть форма регистрации. Ты ее берешь и выносишь в npm пакет. Потом ты можешь подключить форму регистрации в несколько проектов твоей компании, т.к. всем проектам нужна одинаковая регистрация. Таких npm пакетов у тебя становится штук 20-30. Управлять ими по отдельности сложновато. Поэтому придумали инструмент lerna, который позволяет управляться с этими npm пакетами проще и быстрее.
В итоге ваша компания например хочет создать еще один похожий проект. Вы создаете еще один проект и начинаете подключать те npm пакеты, которые требуются, как в конструкторе. Дайте мне форму регистрации, профайл пользователя и что-то там еще.
Просто выбирайте компании, которые занимаются чем-нибудь амбициозным. Например напроситесь в 2gis. Это картография, она всегда сложная. Или наймитесь писать какую-нибудь соц. сетку. Это тоже большой пласт интересных знаний. Или какой-нибудь GUI редактор, например web-версия условного Word/Excel-я. Найдите компанию, которая что-нибудь архитектурное (всякие 3д редакторы) пишет.
На самом деле не понятно, как люди умудряются избегать интересных задач. У меня их была уйма. И очень интересный иерархические virtual-scroll, и объектные визивиг-редакторы, и соц. сеть, и редактор уроков для школьников, и UI штука для составления расписаний занятий и пр… Оно как-то само находит тебя, когда ты готов заниматься чем-нибудь интересным. Обычно это многолетние проекты с большими кодовыми базами и сложной предметной областью.
Если же верстать лендинги целыми днями, то можно ж со скуки умереть :)
Спасибо за совет! Вот некий редактор и был единственным интересным веб проектом. Жаль, что там был слишком плохой код и я не стал там задерживаться. А так, больше половины моих проектов - админки.
Тут еще момент, что с React почти везде используется Redux (в 2gis тоже) со своим зоопарком технологий, а мне он никогда не нравился. Не горю желанием тратить время на технологию, которая мне не интересна, диктует мне свою архитектуру, и без которой получается делать проще и быстрее.
то только по причине большего количества спагетти кода на момент моего прихода
Если ваша роль при этом заключается в том, чтобы всё исправить, то это может быть весьма увлекательным. У меня был один такой проект. Это был качественный скачок в развитии архитекторских навыков. Одно дело знать грабли на которые не стоит наступать, и не наступать на них самому. И другое дело вкусить наполную уже результат наступания (причём не наступая самому), и научиться всё это дело исправлять. Это такой интересный урок. Теоретические познания мгновенно отражаются на пратике. Ты знаешь, что подход Х, тут исправит такие-то проблемы. Ты его внедряешь, проблемы исправляются, ты в первых рядах — понимаешь всё в деталях. Прямо подлинное понимание приходит. И соответственно крепкий навык. Когда в голове что-то из категории "догма" переходит в категорию "полезный инструмент".
Но если лечить проект не позволяют и заставляют писать всё ту же лапшу, то лучше сразу свалить.
Такой роли у меня не было. Бывало пару раз, что на масштабный рефакторинг выделяли месяц-два.
Архитектурные навыки я неплохо прокачал другим способом. И итак нарефачился за свою жизнь) В одном проекте кто-то ключевой функционал сделал одной функцией на 800+ строк, плюс хватало проблем и в других местах. В другом - реакт с ангуляром вместе использовался и потом это переписывали на es6 и попутно избавлялись от angular. В третьем - с jquery на react переписывали.
Что важно знать, не бывает сложных проектов бывают сложные задачи. Если проект сложный значит у него плохая архитектура. В наши дни когда каждый второй программист иметь сложные проекты просто не выгодно компании. Если для выпуска каждой задачи в прод требует вмешательство человека с знаниями sen+ то это не значит что нужно в команду одних сеньоров набирать, а значит что нужно пересмотреть архитектуру.
Уже после этого человек приобретал более глубокое знание.
Ну т.е. не зная основ, человек должен приобретать эти основы. И вот тут всё упирается в то, насколько легко понять основы. Чем менее прямолинейная логика, тем сложнее.
Вот скажем дебажить React будет "одно удовольствие", т.к. там Fiber-ы с дроблённым рендером и несколькими фазами. Можно утонуть просто по уши. И профилировать такое сложно, т.к. оно реально дробится на чанки длинной не более кадра. Простые механизмы не работают. КПД такого дебага будет очень низким.
В случае MobX, Knockout, Vue свои приколы. Скажем дебаг computedObservables из нокаута, когда они там разного вида (асинхронные, debounced, синхронные), да ещё и с массивами — то получается такая лютая каша, что даже зная, как это всё работает, часы дебага могут привести ни к чему. А учитывая что там ну ничего не детерминировано, то прямо печаль. Зубами приходится впиваться в каждый кейс, боясь перезагрузить вкладку.
В общем вы описываете человека, который глубоко разбирается в теме, просто в немного другой теме. Скажем он хорошо владеет похожими инструментами, но не конкретно этими. И тогда свои знания он использует в том же ключе, и с болью и потом, пробирается сквозь тернии к результату. Желательно чтобы такой человек был очень опытным, а то может и на две недели утонуть в коде.
Про таких людей я и писал выше, что им нужно задавать вопросы не абы какие, а связанные с теми технологиями, с которыми они очень плотно работали. Тогда и легко становится понять, на что способен человек. Не приходится гадать. Человек съевший собаку на технологии Х, может вам часами про неё говорить.
что для среднестатистического мидла/сеньора не обязательно знать досконально на 100% свою технологию
Зачем здесь слово досконально? Мы ведь говорим про основы. Основы это не досконально. Это… основы. Азы.
Уточню — эта статья описывает азы.
Считаю что на подобные вопросы кандидаты уровня мида и выше могут с уверенностью отвечать "не помню, щас загуглю".
Считаю, что синьоры на подобные вопросы могут с уверенностью отвечать встречным вопросом "а какой третий параметр принимает функция имя_функции", чтобы спрашивающий уже сам начал бормотать про гугл)
Задавать вопросы, на которые легко отвечает любое IDE, — это та ещё пустая трата времени.
Так делать не рекомендуется
А почему просто "не рекомендуется", вместо "за это бьют ногами"?
P.S. обсуждаемая тема хорошо описана в первых подкастах "Пятиминутка React".
Не увидел главного тезиса - "вызов dispatch - потенциально очень дорогой, чем больше компонентов с редаксом (connect/useSelector) - тем дороже dispatch". Начиная с какого-то уровня, мемоизация тоже не очень спасает (особенно то, что есть в createSelector).
Сам давно мигрировал на vue+vuex, но там та же ситуация. Построение зависимостей от объектов, а объекты создаются налету (через {...}), или новые массивы создаются налету через .filter, и все computed начинают перестраиваться чаще, чем требуется. Я про это тоже писал в разрезе vue, https://habr.com/ru/post/587946/, https://habr.com/ru/post/543298/.
Я обычно спрашивал: “Какой первый параметр принимает connect?”
Бессмысленные и беспощадные собеседования. Еще бы спросил - на какой странице и какой строке в оф. доке это написано?
А будет считаться правильным ответом, что в redux вообще нет функций `mapStateToProps` и `connect`? Это явно про какую-то другую библиотеку.
Я конечно не реакт профи, но на моменте о 3 независимых компонентах, и глобальном стейте из которого они тащат данные я бы закрыл окошко с зумом. Если хотите сэкономить время на интервью, можете дать HR ссылку на документацию редакса, пусть он/она выбирает из неё рандомным функцию и спрашивает сколько там параметров 😄 сразу половину кандидатов отсеете, удобно!
А что вы найдете в документации? как работают 3 независимых компонента?
Вероятно вы ожидаете, что вам будут задавать вопросы, которые вам нравятся, а не те вопросы, которые нужны, чтобы оценить подходите ли для этой позиции
Вопрос о 3 независимых компонентах - это совсем не про апишку, а именно о принципе работы инструмента (если дать развернутый ответ).
Вот, к примеру, просить подробно рассказать про четвертый параметр функции connect действительно было бы неуместным задротством, потому что эти знания сиюминутно под рукой, и их не надо помнить наизусть. Или, допустим, спрашивать какие-нибудь малоизвестные синтаксические тонкости. Это всё хрень, которую не отходя от кассы подскажет ВебШторм или этот ваш ВСКод.
Вопросы на понимание сути, 1-2 задачки на умение кодить, и что-нибудь про архитектуру/декомпозицию/чистый_код - вот золотая триада хорошего собеса. Всё в меру, конечно.
Ну дак вы спрашиваете у человека вопросы про стейт менеджмент, и ваши вопросы все вокруг того что у вас есть 3 независимых компонента, которые почему то шарят один глобальный стейт между собой. Конечно важно знать как обойти проблему с тем что у вас все компоненты обновляются вместо одного. Чего этого можно было избежать например не имея глобальный стейт, там где он не нужен. Мой поинт в том что автор преподносит его ответы как единственно верные и вопросы важными.
[Redux] Мой любимый устаревший вопрос на собеседовании