Жалко не осветиили самый интересный момент, переключение между React и AngularJS. Как загружали фреймворки, оба сразу, или как-то по-ленивому?
Моя ошибка — использование в данном проекте CSS Modules.
Аргументы понятные, но спорные
Проблемы с кешированием – если делать иммутабельные файлы (с хешем контента в имени), то все будет кешироваться как надо?
Возможность отладки – решается сохранением исходных имен, просто дописываем уникальный хеш в конец (плюс React Devtools приходят на помощь, если что не так)
Переиспользование классов – так вместо классов теперь нужно переиспользовать компоненты! Это имеет смысл еще и потому, что редко требуется переиспользовать класс в одиночку (за такими штуками лучше к tailwind), а какой-то набор с состояниями. Завернуть их в переиспользуемый dumb component, даже если это будет один html-тэг, очень даже оправдано
У нас в проекте используются CSS-модули, уже 2 года как, и мы счастливы. Давайте обсуждать!
Это в вашем варианте использования не существенно. Но раз вы делаете библиотеку в общем доступе, то и конвенциям сообщества соотвествовать надо. Тем более, что от вас многого и не требуется – достаточно поменять терминологию
редьюсер toLocalStorage(), позволяющий сохранять Shared State в localStorage;
Редьюсер по определению своему - это чистая функция. Если у вас там возможны сайд-эффекты, то это уже middleware
Хук use() как функция-член объекта, а не как отдельная функция.
В реакте есть определенная конвенция, что хуками являются только функции, начинающиеся с use*. Своим именованием вы ломаете их eslint плагин, devtools и возможно еще всякий другой тулинг.
А зачем вы фризите входной объект? С одной стороны понятно, чтобы его никто не вздумал мутировать, но с другой стороны, это должно решаться иными средствами, например, типами.
Асинхронный scheduling внушает опасение. Можно попать в infinite loop, который очень сложно сдетектить, потому что из-за асинхронных обновлений переполнения стека не происходит. Кроме того, зомби-чилды из комментария выше так и возникают.
По-хорошему, лучше делегировать обновление стейта самому фреймворку. Сделать один Provider c useState, use-хук будет писать и читать из этого провайдера, а react сам разберется с порядком обновлений
Зачем все это? У меня нет задачи дотянуть этого конкретного кандидата до правильного ответа. При конкурсе несколько десятков человек на одно место это не имеет смысла.
Что-то вы перевираете. Ответ "я тут еще не очень долго работаю" невозможен в принципе, потому что к интервью сразу не допускают, а только спустя какое-то время.
Во-вторых, примеров реализации фичей по своей инициативе у меня тоже хватает. Это в первую очередь от самих людей зависит, а не компании.
В реальном мире у нас и задачи больше и сложнее, чем можно сделать за час на интервью. Поэтому правильная экстраполяция будет такая – получил задачу на неделю, из них 3 дня тупил. А это уже ощутимая разница
+1 про бесполезные useCallback. Дело в том что коллбек зависит от getFilterQuery, а его вполне могут передавать вот так
useFiltersQuery(filter => /* do something */)
В этой ситуации, все эти useCallback оказываются мартышкиным трудом, безо всякой пользы.
Более того, даже в идеальном случае useCallback не покажут никаких улучшений. @Roman9131 у вас есть бенчмарк показывающий пользу useCallback? А если нет, зачем вы чинили то что не сломано?
когда Вы идёте не туда со своими размышлениями, интервьюер даёт Вам подсказку, но Вы её игнорируете (в лучшем случае), а в худшем еще и настаиваете на неправильном ответе.
не стоит додумывать чего там не было (про листочки). Давайте все-таки подразумевать хорошие намерения обеих сторон. Например, что в задаче есть несколько правильных решений и несколько тупиковых (которые кажутся верными, но заваливаются на сложных граничных случаях).
У меня в практике такое бывало, кандидат выбирает тупиковое решение, ты ему подсказываешь, намекаешь про граничные случаи, но он все равно идёт напролом со своим решением. Спустя пол-интервью, он таки осознает что его подход не годится, но отведенное время уже вышло, и на нормальное решение его уже нет. ССЗБ, получается.
Даже нанимая эксперта, все равно от него не ожидают работы оракула "будем делать так, но почему – я рассказывать не буду", а последовательного объяснения своих решений.
Поэтому и интервью – это диалог и обсуждение разных альтернатив, а если кандидат уперся в одно решение и не хочет с него сворачивать, то это красный флаг.
Если кандидатам не интересен этот сторителлинг, они могут проходить мимо и работать в других компаниях.
А если уж захотели в эту конкретную – то придется рассказать то что им нужно. Более того, сторителлинг не заканчивается после собеседования, все повышения внутри компании тоже нужно подкреплять примерами и историями, показывающими ваш достойный уровень.
Если вам такие процессы не по душе, дело ваше, можно найти и другие места
В статье не хватает реального примера истории, которую вы ожидаете от кандидата. В теории оно выглядит как "расскажи про все хорошее в лучшем свете, а плохое рассказывать не надо". Нужен практический пример.
Ещё по своему опыту проведения собеседований в FAANG замечу, что ответы по STAR не какая-то супер сложная штука. Это задача собеседующего разложить ответ кандидата по полочкам STAR. От вас требуется только отвечать на наводящие вопросы.
Подобное уже случалось во фронтенде. Была библиотека libsass, написанная на C++. Однако из-за неудобного стека, новые фичи добавлялись катастрофически медленно. В результате, libsass всё, закрылся.
Возможно библиотекам на Rust повезет больше, потому что язык более дружелюбный, но время покажет
Спасибо за статью, интересный контент!
Жалко не осветиили самый интересный момент, переключение между React и AngularJS. Как загружали фреймворки, оба сразу, или как-то по-ленивому?
Аргументы понятные, но спорные
Проблемы с кешированием – если делать иммутабельные файлы (с хешем контента в имени), то все будет кешироваться как надо?
Возможность отладки – решается сохранением исходных имен, просто дописываем уникальный хеш в конец (плюс React Devtools приходят на помощь, если что не так)
Переиспользование классов – так вместо классов теперь нужно переиспользовать компоненты! Это имеет смысл еще и потому, что редко требуется переиспользовать класс в одиночку (за такими штуками лучше к tailwind), а какой-то набор с состояниями. Завернуть их в переиспользуемый dumb component, даже если это будет один html-тэг, очень даже оправдано
У нас в проекте используются CSS-модули, уже 2 года как, и мы счастливы. Давайте обсуждать!
На самом деле очень мутная история
Дата его твита – Jan 6, 2022, 10:18 PM
При этом в colors.js он коммитил уже после этого твита – Jan 8, 2022, 5:22 AM
Если Гитхаб его реально заблокировал, то как ему удалось коммитить? Скорее всего, он просто п****т
Судя по всему, статья – конспект этого видео
Это в вашем варианте использования не существенно. Но раз вы делаете библиотеку в общем доступе, то и конвенциям сообщества соотвествовать надо. Тем более, что от вас многого и не требуется – достаточно поменять терминологию
Извините пожалуйста, но разрешите докопаться.
Редьюсер по определению своему - это чистая функция. Если у вас там возможны сайд-эффекты, то это уже middleware
В реакте есть определенная конвенция, что хуками являются только функции, начинающиеся с
use*. Своим именованием вы ломаете их eslint плагин, devtools и возможно еще всякий другой тулинг.А зачем вы фризите входной объект? С одной стороны понятно, чтобы его никто не вздумал мутировать, но с другой стороны, это должно решаться иными средствами, например, типами.
Асинхронный scheduling внушает опасение. Можно попать в infinite loop, который очень сложно сдетектить, потому что из-за асинхронных обновлений переполнения стека не происходит. Кроме того, зомби-чилды из комментария выше так и возникают.
По-хорошему, лучше делегировать обновление стейта самому фреймворку. Сделать один Provider c useState, use-хук будет писать и читать из этого провайдера, а react сам разберется с порядком обновлений
Ясное дело, что нужно проследить всю цепочку. Но это приводит к очень хрупкому коду. При этом выгода от всего этого совершенно не понятна
Чтобы что? Вы можете в реальных цифрах показать, что это улучшает?
Все надеятся получить первоклассного хирурга, хоть и матершинника, но на самом деле получают посредственного специалиста, только к тому же еще и хамло
А у вас есть какие-то экспериментальные данные подтверждающие вот это:
Зачем все это? У меня нет задачи дотянуть этого конкретного кандидата до правильного ответа. При конкурсе несколько десятков человек на одно место это не имеет смысла.
Что-то вы перевираете. Ответ "я тут еще не очень долго работаю" невозможен в принципе, потому что к интервью сразу не допускают, а только спустя какое-то время.
Во-вторых, примеров реализации фичей по своей инициативе у меня тоже хватает. Это в первую очередь от самих людей зависит, а не компании.
В реальном мире у нас и задачи больше и сложнее, чем можно сделать за час на интервью. Поэтому правильная экстраполяция будет такая – получил задачу на неделю, из них 3 дня тупил. А это уже ощутимая разница
+1 про бесполезные useCallback. Дело в том что коллбек зависит от getFilterQuery, а его вполне могут передавать вот так
В этой ситуации, все эти useCallback оказываются мартышкиным трудом, безо всякой пользы.
Более того, даже в идеальном случае useCallback не покажут никаких улучшений. @Roman9131 у вас есть бенчмарк показывающий пользу useCallback? А если нет, зачем вы чинили то что не сломано?
Видимо, речь про это
не стоит додумывать чего там не было (про листочки). Давайте все-таки подразумевать хорошие намерения обеих сторон. Например, что в задаче есть несколько правильных решений и несколько тупиковых (которые кажутся верными, но заваливаются на сложных граничных случаях).
У меня в практике такое бывало, кандидат выбирает тупиковое решение, ты ему подсказываешь, намекаешь про граничные случаи, но он все равно идёт напролом со своим решением. Спустя пол-интервью, он таки осознает что его подход не годится, но отведенное время уже вышло, и на нормальное решение его уже нет. ССЗБ, получается.
Даже нанимая эксперта, все равно от него не ожидают работы оракула "будем делать так, но почему – я рассказывать не буду", а последовательного объяснения своих решений.
Поэтому и интервью – это диалог и обсуждение разных альтернатив, а если кандидат уперся в одно решение и не хочет с него сворачивать, то это красный флаг.
Если кандидатам не интересен этот сторителлинг, они могут проходить мимо и работать в других компаниях.
А если уж захотели в эту конкретную – то придется рассказать то что им нужно. Более того, сторителлинг не заканчивается после собеседования, все повышения внутри компании тоже нужно подкреплять примерами и историями, показывающими ваш достойный уровень.
Если вам такие процессы не по душе, дело ваше, можно найти и другие места
В статье не хватает реального примера истории, которую вы ожидаете от кандидата. В теории оно выглядит как "расскажи про все хорошее в лучшем свете, а плохое рассказывать не надо". Нужен практический пример.
Ещё по своему опыту проведения собеседований в FAANG замечу, что ответы по STAR не какая-то супер сложная штука. Это задача собеседующего разложить ответ кандидата по полочкам STAR. От вас требуется только отвечать на наводящие вопросы.
Возможности транспайлера в esbuild настолько ограниченные, что я бы их всерьез рассматривать бы и не стал.
Более того, сам Эван так и говорит – хотите нормальный транспайлер, берите swc
Подобное уже случалось во фронтенде. Была библиотека libsass, написанная на C++. Однако из-за неудобного стека, новые фичи добавлялись катастрофически медленно. В результате, libsass всё, закрылся.
Возможно библиотекам на Rust повезет больше, потому что язык более дружелюбный, но время покажет
esbuild и swc - это не аналоги, один инструмент другой не заменяет. esbuild – это бандлер (вроде webpack), а swc – транспайлер (вроде babel)