Pull to refresh
179
0
Boris Serdiuk @justboris

Front-end engineer

Send message

Спасибо за статью, интересный контент!

Жалко не осветиили самый интересный момент, переключение между React и AngularJS. Как загружали фреймворки, оба сразу, или как-то по-ленивому?

Моя ошибка — использование в данном проекте CSS Modules.

Аргументы понятные, но спорные

  • Проблемы с кешированием – если делать иммутабельные файлы (с хешем контента в имени), то все будет кешироваться как надо?

  • Возможность отладки – решается сохранением исходных имен, просто дописываем уникальный хеш в конец (плюс React Devtools приходят на помощь, если что не так)

  • Переиспользование классов – так вместо классов теперь нужно переиспользовать компоненты! Это имеет смысл еще и потому, что редко требуется переиспользовать класс в одиночку (за такими штуками лучше к tailwind), а какой-то набор с состояниями. Завернуть их в переиспользуемый dumb component, даже если это будет один html-тэг, очень даже оправдано

У нас в проекте используются CSS-модули, уже 2 года как, и мы счастливы. Давайте обсуждать!

На самом деле очень мутная история

Если Гитхаб его реально заблокировал, то как ему удалось коммитить? Скорее всего, он просто п****т

Судя по всему, статья – конспект этого видео

Это в вашем варианте использования не существенно. Но раз вы делаете библиотеку в общем доступе, то и конвенциям сообщества соотвествовать надо. Тем более, что от вас многого и не требуется – достаточно поменять терминологию

Извините пожалуйста, но разрешите докопаться.

редьюсер toLocalStorage(), позволяющий сохранять Shared State в localStorage;

Редьюсер по определению своему - это чистая функция. Если у вас там возможны сайд-эффекты, то это уже middleware

Хук use() как функция-член объекта, а не как отдельная функция.

В реакте есть определенная конвенция, что хуками являются только функции, начинающиеся с use*. Своим именованием вы ломаете их eslint плагин, devtools и возможно еще всякий другой тулинг.

https://github.com/AlexIII/whoosh/blob/main/src/whoosh.ts#L58

А зачем вы фризите входной объект? С одной стороны понятно, чтобы его никто не вздумал мутировать, но с другой стороны, это должно решаться иными средствами, например, типами.

https://github.com/AlexIII/whoosh/blob/main/src/whoosh.ts#L37

Асинхронный scheduling внушает опасение. Можно попать в infinite loop, который очень сложно сдетектить, потому что из-за асинхронных обновлений переполнения стека не происходит. Кроме того, зомби-чилды из комментария выше так и возникают.

По-хорошему, лучше делегировать обновление стейта самому фреймворку. Сделать один Provider c useState, use-хук будет писать и читать из этого провайдера, а react сам разберется с порядком обновлений

Ясное дело, что нужно проследить всю цепочку. Но это приводит к очень хрупкому коду. При этом выгода от всего этого совершенно не понятна

Идея добавление useCallback, как раз была именно в том, чтобы исключить рередер дочерних компонентов

Чтобы что? Вы можете в реальных цифрах показать, что это улучшает?

Все надеятся получить первоклассного хирурга, хоть и матершинника, но на самом деле получают посредственного специалиста, только к тому же еще и хамло

А у вас есть какие-то экспериментальные данные подтверждающие вот это:

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

Зачем все это? У меня нет задачи дотянуть этого конкретного кандидата до правильного ответа. При конкурсе несколько десятков человек на одно место это не имеет смысла.

Что-то вы перевираете. Ответ "я тут еще не очень долго работаю" невозможен в принципе, потому что к интервью сразу не допускают, а только спустя какое-то время.

Во-вторых, примеров реализации фичей по своей инициативе у меня тоже хватает. Это в первую очередь от самих людей зависит, а не компании.

В реальном мире у нас и задачи больше и сложнее, чем можно сделать за час на интервью. Поэтому правильная экстраполяция будет такая – получил задачу на неделю, из них 3 дня тупил. А это уже ощутимая разница

+1 про бесполезные useCallback. Дело в том что коллбек зависит от getFilterQuery, а его вполне могут передавать вот так

useFiltersQuery(filter => /* do something */)

В этой ситуации, все эти useCallback оказываются мартышкиным трудом, безо всякой пользы.

Более того, даже в идеальном случае useCallback не покажут никаких улучшений. @Roman9131 у вас есть бенчмарк показывающий пользу useCallback? А если нет, зачем вы чинили то что не сломано?

Видимо, речь про это

когда Вы идёте не туда со своими размышлениями, интервьюер даёт Вам подсказку, но Вы её игнорируете (в лучшем случае), а в худшем еще и настаиваете на неправильном ответе.

не стоит додумывать чего там не было (про листочки). Давайте все-таки подразумевать хорошие намерения обеих сторон. Например, что в задаче есть несколько правильных решений и несколько тупиковых (которые кажутся верными, но заваливаются на сложных граничных случаях).

У меня в практике такое бывало, кандидат выбирает тупиковое решение, ты ему подсказываешь, намекаешь про граничные случаи, но он все равно идёт напролом со своим решением. Спустя пол-интервью, он таки осознает что его подход не годится, но отведенное время уже вышло, и на нормальное решение его уже нет. ССЗБ, получается.

Даже нанимая эксперта, все равно от него не ожидают работы оракула "будем делать так, но почему – я рассказывать не буду", а последовательного объяснения своих решений.

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

Если кандидатам не интересен этот сторителлинг, они могут проходить мимо и работать в других компаниях.

А если уж захотели в эту конкретную – то придется рассказать то что им нужно. Более того, сторителлинг не заканчивается после собеседования, все повышения внутри компании тоже нужно подкреплять примерами и историями, показывающими ваш достойный уровень.

Если вам такие процессы не по душе, дело ваше, можно найти и другие места

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

Ещё по своему опыту проведения собеседований в FAANG замечу, что ответы по STAR не какая-то супер сложная штука. Это задача собеседующего разложить ответ кандидата по полочкам STAR. От вас требуется только отвечать на наводящие вопросы.

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

Более того, сам Эван так и говорит – хотите нормальный транспайлер, берите swc

Подобное уже случалось во фронтенде. Была библиотека libsass, написанная на C++. Однако из-за неудобного стека, новые фичи добавлялись катастрофически медленно. В результате, libsass всё, закрылся.

Возможно библиотекам на Rust повезет больше, потому что язык более дружелюбный, но время покажет

esbuild и swc - это не аналоги, один инструмент другой не заменяет. esbuild – это бандлер (вроде webpack), а swc – транспайлер (вроде babel)

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity