Lens JS как менеджер состояния приложения

Линза — это хорошая сказка для тех, кто уже устал от MobX

Когда устану — лет через 150, — пренепременно запилю стейт на линзах.

Фронтендеры — герои. Yehuda Katz объясняет почему

«что, если случайные 5% моих SQL-запросов в Rails фейлятся». Начинающие фронтендеры не думают об этом, но более опытные — точно учитывают такие кейсы.

Постоянно сталкиваюсь с тем, что об этом забывают дизайнеры. Ну никак не могут усвоить и принять для себя классическую асинхронную триаду "waiting/success/failure". На картинках всегда только "success", остальных состояний нет, приходится пинать.

Впечатления о Vue.js после React

Vue правильнее сравнивать не с Реактом, а с божественной связкой React+MobX, тогда будет что-то схожее.
По поводу шаблонов я так и не понял вот что:

v-on:change="todo.completed = !todo.completed"

-будет ли внутри кавычек работать тайпчекинг (TS) и автокомплит (WebStorm, к примеру)?

Вообще субъективно мне не нравится код в строке. Непонятно, что за переменные, из какого они скоупа, и т.д. Вот чем хорош JSX/TSX — там всё как в обычном JS/TS, с переменными понятно, в частности.

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

Возможно, автор перепутал сеньора с тим-лидом. Последний да, часто раздает задачи и командует разрабами (не всегда пишет код), но сеньор — это всё-таки именно программист, просто очень скилловый, и решить простенькую задачку с собеса (оценив асимптотику решения) должен уметь.

Вопросы для собеседования по хукам React

на mobx — классы без вариантов

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

Вопросы для собеседования по хукам React

В последнем примере useCallback как раз не нужен — не дает никакого бонуса.

Вопросы для собеседования по хукам React

Навскидку:
1) Для чего нужен useCallback. Вопрос хорош тем, что можно развернуть тему оптимизации и мемоизации в Реакте.
2) Попросить рассказать, как примерно устроены хуки изнутри. Если пациент не знает (не читал), то неплохой повод порассуждать.

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

Столбиком делить не умею, только уголком. Такое прокатит?

В чем разница между useLayoutEffect, componentDidMount, useEffect

Заходя в статью, ожидал увидеть какую-нибудь тонкую разницу между useLayoutEffect и componentDidMount, но "чуда не произошло")

А то что классы не будут развиваться — это не кажется, так прямо написано где-то в официальных доках.

Brython: заменяем JavaScript на Python на фронтенде

Согласен. По сути единственной серьезной претензией к js на фронте было отсутствие типизации, ts эту проблему решил. Скорость выполнения? Ну это точно не про сабж.

Все ли вы знаете о useCallback

Делал похожую штуку для viewModel к реактовским компонентам, тоже на useRef (модель была мобиксовым стором со своими экшенами, и жила, пока жил компонент). То есть специальный хук создавал и поддерживал постоянный экземпляр, да ещё и вызывал у него метод clean при наличии такового, если модели нужна очистка, допустим таймер прибить. Как бы двустороннее сотрудничество компонента и модели — модель рулит логику и уведомляет вьюху, а компонент через хук предоставляет жизненный цикл.

Все ли вы знаете о useCallback

После нажатия на кнопку, разумеется, многое меняется. Мой поинт немного о другом. Поясню кодом (упрощенно):

...
const handleUserSelect = useCallback(answer => {
   // здесь некий код, использующий props.someProp
}, [props.someProp]);

return (
   ...
   <Footer onUserSelect={handleUserSelect} loading={loading} />
);

someProp меняется часто, ещё ДО нажатия на кнопку. Footer не зависит от someProp, но в приведенном коде всё равно будет вынужден зря реконсилиться, потому что изменение someProp, видите ли, привело к замене handleUserSelect. Мой велосипед как раз для такого кейса.

Все ли вы знаете о useCallback

Да ничего особенного. Последний пример — у компонента есть свой memo(Footer), в который уехали кнопки "да/нет/наверно". Соответственно в пропсах футера есть колбэк onUserSelect, в который передается функция, работающая c некоторыми объектами, но сами эти объекты не передаются, ибо футеру они без надобности, он только сообщает о выборе пользователя. Таким образом, футеру нет нужды перерисовываться, если объекты поменялись.
Я полагаю, этот кейс не выглядит каким-то совсем уж странным.

Все ли вы знаете о useCallback

У меня в использовании useCallback иногда всплывал такой кейс: функция зависит от пропа, который часто меняется, из-за этого useCallback часто отдает новую функцию, и имеем лишние рендеры компонента, который получает на вход этот колбэк, но напрямую не зависит от того меняющегося пропа. Написал свой довольно простой аналог useCallback с блэкджеком и без депенденсов, который всегда возвращает одну и ту же функцию:

export function usePersistentCallback(func) {
  const ref = useRef(null);
  if (!ref.current) {
    ref.current = {
      callee: func,
      caller: function() {
        return ref.current.callee.apply(this, arguments);
      }
    };
  }
  ref.current.callee = func;
  return ref.current.caller;
}

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

Все ли вы знаете о useCallback

У нас просто очень большой опыт работы с мемоизацией и React. Мы на ней собаку съели.

Интересно у вас… Прямо свою предыдущую работу вспомнил (там вебсокет-пулеметчик, тоже приходилось упарываться в мемо и вообще включать голову).

JS и его запретные тайны

У неизменяемых строк есть и другие бонусы, например, можно пошарить строковые буферы. Мистер Алеф, помнится, писал о некоторых деталях реализации в V8, например, когда берем substr, новая строка юзает тот же буфер.

JS и его запретные тайны

Автор того комментария уже объяснился.

JS и его запретные тайны

Смутно припоминаю, что эта ветка комментов начиналась со слов "== хорош только для null" (или как-то так), так что о верхней картинке можно забыть.

Все ли вы знаете о React key?

Тоже было дело, таким образом избавился от анимации, которая в определенном случае была не нужна.

Простая математическая задача, которую мы все еще не в состоянии решить

Увидев заголовок, почему-то сразу подумал про "3n+1" )