Мой поинт в том что автор преподносит его ответы как единственно верные и вопросы важными.
Из каких строк в моей статье, сложилось у вас такое впечатление? Более того, в комментариях я поддерживал другие иронические ответы. Мне действительно в этом вопросе интересны принципы работы.
Нет. Это значит весь твой проект состоит из npm пакетов. Представь, что у тебя есть форма регистрации. Ты ее берешь и выносишь в npm пакет. Потом ты можешь подключить форму регистрации в несколько проектов твоей компании, т.к. всем проектам нужна одинаковая регистрация. Таких npm пакетов у тебя становится штук 20-30. Управлять ими по отдельности сложновато. Поэтому придумали инструмент lerna, который позволяет управляться с этими npm пакетами проще и быстрее.
В итоге ваша компания например хочет создать еще один похожий проект. Вы создаете еще один проект и начинаете подключать те npm пакеты, которые требуются, как в конструкторе. Дайте мне форму регистрации, профайл пользователя и что-то там еще.
А что вы найдете в документации? как работают 3 независимых компонента?
Вероятно вы ожидаете, что вам будут задавать вопросы, которые вам нравятся, а не те вопросы, которые нужны, чтобы оценить подходите ли для этой позиции
Если брать из последних проектов то было следующее: - мессенджер (конкурент телеграмам вайберам и т.д.). Это один из самых сложных для фронтендера проектов в принципе - проект состоящих из двух проектов. При том каждый проект как в браузере так и на React Native. И нужно было выделить пере используемые части в lerna. Что-то пере используется между браузером и мобилкой. Что-то между двумя RN проектами. Что-то между двумя браузерными проектами. Я активно принимал участие в проектировании этой архитектуры. - создание платфомы кодовой базы, через lerna. У продукта есть запрос, выпускать десятки похожих проектов, с немного отличающейся бизнес логикой. Поэтому нужно создать своеобразный конструктор.
Как их искать. Ну... я при поиске всегда обсуждаю, чтобы проект был хардовый. В итоге соглашаюсь, только на те проекты, где мне кажется, что будет очень увлекательно девелопить
Я бы с радостью почитал подробный ответ на каждый из перечисленных мной пунктов, для повышение своей квалификации. Говорить, что все вокруг дураки каждый может
Я думаю, об этом в будущем написать. Там много мелких моментов: - возникла проблема потери контроля над рендерингом. Там observer управляет обновлять компонент или нет. В итоге при обновлении версии mobX. У нас приложение не запустилось. Т.к. порядок рендеринга компонентов изменился и наш код к такому не готов. Это было очень стремно. Мы не знали где еще отломится. - нет best practice. Ребята из командыы начали активно продвигать идею использовать активно подписки, чтобы реагировать на все. В итоге, опять вышла потеря контроля, над тем в каком порядке код выполняется. И зачастую выполняется лишний код, который в такой ситуации не нужно реагировать. - идеалогия не декомпозировать стор, а прокидывать весь стор в компоненты, так же накладывает сложности - опять же отсутствие бест практис. И предыдущая команда в сторах хранила не только данные а и всю бизнес логику. Приложение было очень связанным и в итоге сторы уже включали часть логики других сторов. - с памятью проблемы начались. То инстансы где то в реакциях зависали, то реакцию повесить можно внутри например User. И если юзеров кол-во растест сильно, то реакции тоже сильно растут и мы сравнивали сколько памяти это съедает
Моя позиция в том, что для среднестатистического мидла/сеньора не обязательно знать досконально на 100% свою технологию, как выше уже писали "кишки", что бы выполнять свои задачи.
Мне кажется вы делаете подмену понятий. "знание основ" и "знать досконально на 100% свою технологию". Это две разные вещи.
Если привести аналог на языке JS, я бы сравнивал свой вопрос, как "Как работает всплытие событий?". Нам так или иначе приходится с этим взаимодействовать. Без глубоких знаний можно ли решить эту проблему. Конечно можно. Загуглить на stackoverflow что-то, вставить и вуаля заработало! Нужен ли мне на позиции Senior JS developer, такой человек. Мои проекты чаще всего очень сложные и такие люди без основ будут отнимать у меня много времени.
А если говорить, про 100% знания языка. Я мог бы спросить про то как работают генераторы в JS. Насовать кучу примеров. Я ведь этого не делаю. Я ожидаю от кандидата, что бы он умел решать базовые задачи уверенно, а не кое как с гуглом и вопросами справился. А потом еще на ревью 3 раунда переделывал
А все нормальные люди уже много лет используют MobX.
На прошлом проекте 1.5 года использовали mobX, не понравилось) И все новые вакансии, почему просят Redux. Вероятно не так уж и умер) А в комментариях под моими видео, уже фанаты Effector во всю просят сделать видосы на эту тему. Так что даже и не знаю, что будет в будущем
Да, тут используется инверсия зависимостей) Но это лишь инструмент, как развернуть направление зависимостей. Статья была направлена на то чтобы люди немного больше уделяли внимания направлениям зависимостей в их проектах)
А то по вашей логике, если у меня есть http клиент который инжектится но изменяется часто, я должен инжектить бизнес логику в него?
а что значит инжектить бизнес логику? вы имеете ввиду создавать адаптеры, чтобы АПИшка готовила данные в нужном формате бизнес логике?
В любом нормально языке Circular Dependency решается 2мя способами.
1. Объединение 2ух файлов/классов вотевер в одине файл/класс/пекедж 2. Интерфейсами
Способ плох тем, что файл разрастается. И в одном файле, могут быть уже функции, которые крайне не связаны друг с другом. Я подразумеваю вы имели ввиду, то что работает вместе выделить из обоих файлов и поместить в третий файл
Сомнительный путь. Если я буду импортить только эту функцию из того файла, а тот файл будет импортить другую функцию из моего файла. Звучит как крайне скользкая дорожка. Если я правильно конечно понял идею
я все же придерживаюсь идеи, что "программировать на уровне интерфейсов" это идея, а инверсия зависимостей, это конкретный прием, помогающий воплатить тот или иной интерфейс. Я конечно могу ошибаться :)
Инверсия зависимостей является лишь инструментом программирования на уровне интерфейсов. Это статья скорее направлена на то чтобы люди мыслить начали чуть иначе. А когда захотят имплементить свои идеи, тогда и инверсия зависимостей пригодится
Вопросы у меня по двум моментам:
как скринридеры узнают, что hint это текст, который лежит после инпута в теге p?
label-ом оборачивать прям все, тоже не всегда хорошая идея, т.е. hint - это не label
Отличный пример чего?
Из каких строк в моей статье, сложилось у вас такое впечатление? Более того, в комментариях я поддерживал другие иронические ответы. Мне действительно в этом вопросе интересны принципы работы.
Нет. Это значит весь твой проект состоит из npm пакетов. Представь, что у тебя есть форма регистрации. Ты ее берешь и выносишь в npm пакет. Потом ты можешь подключить форму регистрации в несколько проектов твоей компании, т.к. всем проектам нужна одинаковая регистрация. Таких npm пакетов у тебя становится штук 20-30. Управлять ими по отдельности сложновато. Поэтому придумали инструмент lerna, который позволяет управляться с этими npm пакетами проще и быстрее.
В итоге ваша компания например хочет создать еще один похожий проект. Вы создаете еще один проект и начинаете подключать те npm пакеты, которые требуются, как в конструкторе. Дайте мне форму регистрации, профайл пользователя и что-то там еще.
А что вы найдете в документации? как работают 3 независимых компонента?
Вероятно вы ожидаете, что вам будут задавать вопросы, которые вам нравятся, а не те вопросы, которые нужны, чтобы оценить подходите ли для этой позиции
Однозначно будет :)
Про useSelector я запланировал делать отдельное видео. Уже изучил его исходники. Поэтому подписывайтесь на АйТи Синяка и все увидите)
Если брать из последних проектов то было следующее:
- мессенджер (конкурент телеграмам вайберам и т.д.). Это один из самых сложных для фронтендера проектов в принципе
- проект состоящих из двух проектов. При том каждый проект как в браузере так и на React Native. И нужно было выделить пере используемые части в lerna. Что-то пере используется между браузером и мобилкой. Что-то между двумя RN проектами. Что-то между двумя браузерными проектами. Я активно принимал участие в проектировании этой архитектуры.
- создание платфомы кодовой базы, через lerna. У продукта есть запрос, выпускать десятки похожих проектов, с немного отличающейся бизнес логикой. Поэтому нужно создать своеобразный конструктор.
Как их искать. Ну... я при поиске всегда обсуждаю, чтобы проект был хардовый. В итоге соглашаюсь, только на те проекты, где мне кажется, что будет очень увлекательно девелопить
Я бы с радостью почитал подробный ответ на каждый из перечисленных мной пунктов, для повышение своей квалификации. Говорить, что все вокруг дураки каждый может
жуть какая)
Я думаю, об этом в будущем написать. Там много мелких моментов:
- возникла проблема потери контроля над рендерингом. Там observer управляет обновлять компонент или нет. В итоге при обновлении версии mobX. У нас приложение не запустилось. Т.к. порядок рендеринга компонентов изменился и наш код к такому не готов. Это было очень стремно. Мы не знали где еще отломится.
- нет best practice. Ребята из командыы начали активно продвигать идею использовать активно подписки, чтобы реагировать на все. В итоге, опять вышла потеря контроля, над тем в каком порядке код выполняется. И зачастую выполняется лишний код, который в такой ситуации не нужно реагировать.
- идеалогия не декомпозировать стор, а прокидывать весь стор в компоненты, так же накладывает сложности
- опять же отсутствие бест практис. И предыдущая команда в сторах хранила не только данные а и всю бизнес логику. Приложение было очень связанным и в итоге сторы уже включали часть логики других сторов.
- с памятью проблемы начались. То инстансы где то в реакциях зависали, то реакцию повесить можно внутри например User. И если юзеров кол-во растест сильно, то реакции тоже сильно растут и мы сравнивали сколько памяти это съедает
Мне кажется вы делаете подмену понятий. "знание основ" и "знать досконально на 100% свою технологию". Это две разные вещи.
Если привести аналог на языке JS, я бы сравнивал свой вопрос, как "Как работает всплытие событий?". Нам так или иначе приходится с этим взаимодействовать. Без глубоких знаний можно ли решить эту проблему. Конечно можно. Загуглить на stackoverflow что-то, вставить и вуаля заработало! Нужен ли мне на позиции Senior JS developer, такой человек. Мои проекты чаще всего очень сложные и такие люди без основ будут отнимать у меня много времени.
А если говорить, про 100% знания языка. Я мог бы спросить про то как работают генераторы в JS. Насовать кучу примеров. Я ведь этого не делаю. Я ожидаю от кандидата, что бы он умел решать базовые задачи уверенно, а не кое как с гуглом и вопросами справился. А потом еще на ревью 3 раунда переделывал
На прошлом проекте 1.5 года использовали mobX, не понравилось)
И все новые вакансии, почему просят Redux. Вероятно не так уж и умер)
А в комментариях под моими видео, уже фанаты Effector во всю просят сделать видосы на эту тему. Так что даже и не знаю, что будет в будущем
Все верно) Я теперь спрашиваю про useSelector как работает))
На эту тему будет следующее видео / статья)
Да, тут используется инверсия зависимостей) Но это лишь инструмент, как развернуть направление зависимостей. Статья была направлена на то чтобы люди немного больше уделяли внимания направлениям зависимостей в их проектах)
а что значит инжектить бизнес логику? вы имеете ввиду создавать адаптеры, чтобы АПИшка готовила данные в нужном формате бизнес логике?
Способ плох тем, что файл разрастается. И в одном файле, могут быть уже функции, которые крайне не связаны друг с другом. Я подразумеваю вы имели ввиду, то что работает вместе выделить из обоих файлов и поместить в третий файл
Сомнительный путь. Если я буду импортить только эту функцию из того файла, а тот файл будет импортить другую функцию из моего файла. Звучит как крайне скользкая дорожка. Если я правильно конечно понял идею
Естественно вы правы. Но идею, которую я пытался передать, думаю вы уловили
я все же придерживаюсь идеи, что "программировать на уровне интерфейсов" это идея, а инверсия зависимостей, это конкретный прием, помогающий воплатить тот или иной интерфейс. Я конечно могу ошибаться :)
Я решил начать с чего-нибудь простого и понятного людям) а дальше попробую развить идею)
Инверсия зависимостей является лишь инструментом программирования на уровне интерфейсов. Это статья скорее направлена на то чтобы люди мыслить начали чуть иначе. А когда захотят имплементить свои идеи, тогда и инверсия зависимостей пригодится