Styled Components — идеальная стилизация React-приложения

Есть styled-components как паттерн, функция styled`...`, и у неё есть разные реализации, и styled-components тут не очень. Есть варианты получше, посмотрите на emotion или jss

20 вещей, которые я узнал за 20 лет работы инженером-программистом

Вы, наверное, из тех разработчиков, которые тесты тоже не пишут, потому что это задача QA? А задачи программистов – исключительно писать код и больше ничего?

Почему в Ember не нужны React-хуки

Автор делает две одинаковые реализации, через хук и через компонент. Реализация на хуках короче в 3 раза (25 строк против 73). При этом автор заявляет

Для меня реализация с использованием React-хуков не выглядит чище реализации на React.Component.

Что? Если в 3 раза более короткий код это не критерий чистоты, то что тогда?

Потом автор делает реализацию на Ember, сравнивает её с React.Component, Ember очевидно выигрывает, и на основании этого делается вывод, что хуки не нужны.

Вообще не понял логику этой статьи.

Old Skull — фронтенд-фреймворк из альтернативной вселенной

В статье пропустили самый важный момент успеха современных фреймворков и неуспеха Backbone – возможность создания переиспользуемых компонентов. Берем и пишем:

<div class="something">
  <Button>click me</Button>
</div>

В любом современном фреймворке можно вставить в HTML кастомный элемент, который отрендерит свою разметку и инициализирует свою логику. В Backbone/Marionette так не выйдет – извольте отрендерить контейнер (регион), а потом вручную в него примонтировать компонент.

Видели хоть одну библиотеку UI-компонентов на Backbone? То-то и оно, что на нём такие вещи невозможны в принципе. А на Angular/React/Svelte/Vue/etc – запросто.

Namespaces в JavaScript. Ставим точку в вопросе

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

А все потому что в документации они так явно и пишут:

we recommended modules over namespaces in modern code

А неймспейсы так и остались, как историческое легаси

Ещё 6 вещей, которые я узнал, доведя Snowpack до 20000 GitHub-звёзд

Там весь инструмент такой. В документации постоянно натыкаешься на то что их инструмент в 10 раз лучше чем "обычный порошок". А на деле ничего толком не работает. Один сплошной хайп на том что они новые и современные.

Пользуйтесь лучше vite.js

Создание веб-компонентов с помощью Vue 3.2

Маленькое пожелание – при использовании setInterval нужно не забывать их очищать при удалении компонента. Даже если это просто демка для примера, лучше следовать хорошим практикам

Построение библиотек компонентов и их организация. Или как извлечь максимальную пользу для бизнеса c React и Angular

Изначально вопрос стоял "как извлечь максимальную пользу для бизнеса". С этой точки зрения разнообразие фреймворков только идёт в минус

Построение библиотек компонентов и их организация. Или как извлечь максимальную пользу для бизнеса c React и Angular

Еще есть 4й вариант – собраться с силами и принять корпоративный стандарт по технологиям, и закончить с этим зоопарком.

Построение библиотек компонентов и их организация. Или как извлечь максимальную пользу для бизнеса c React и Angular

Веб-компоненты как стандарт зародился более 10 лет назад, и с тех пор современные подходы улетели далеко вперед, а веб-компоненты все никак не угонятся и по-прежнему предоставляют удобство на уровне AngularJS.

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

Интересный способ сделать config для web js библиотеки

Тем не менее, все объекты создадутся второй копией и все сайд-эффекты произойдут дважды

Интересный способ сделать config для web js библиотеки

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

Для такой ситуации лучше явные конструкторы создавать.

Интересный способ сделать config для web js библиотеки

Картинка про троллейбус из буханки

А почему нельзя сделать так?

<script defer src="https://mysite.github.io/script.js"></script>
<script>
  window.MyWidgetConfig = {
    color: "#fff",
    text: "Hello JS world!",
  }
</script>

Вышла Vue 3.2

Использовать веб-компоненты как общую базу для всех фреймворков – это очень утопичная идея, в реальности не работает. Вместо использования всех возможностей Vue, вам придется искать общий знаменатель и бороться с причудами как других фреймворков, так и самих веб-компонентов. Пару лет назад я об этом написал цикл статей с детальным разбором: часть 1, часть 2 и еще один перевод на эту же тему.

JavaScript: как из Fetch сделать Axios?

simpleFetch.cancel() очень странно работает в случае нескольких параллельных запросов. Получается, что он отменит их все сразу. Правильнее было бы сделать какой-то более гранулярный контроль.

И еще пара рационализаторских предложений:

1. Для собирания baseUrl можно было взять нативное API: new URL(options.url, baseUrl)

2. Для параметров тоже есть нативный URLSearchParams

P.S. и совсем маленькое замечание – сократили вы бы пост в два раза, в ценности бы он совсем не потерял. Не обязательно комментировать каждую строку кода, можно только про самое важное рассказать.

Как написать свою онлайн-песочницу с поддержкой React и популярных библиотек

А зачем в этой связке нужен esbuild? Если это для того чтобы собирать код для запуска, то в браузере же уже нативные es-модули есть, поэтому достаточно только TS->JS сконвертировать, и не бандлить ничего

Кажется, мы стали забывать основы фронтенда

Если нам нужно вызвать callback из useEffect, то мы заворачиваем его в наш кастомный хук

const memoizedOnChange = useStableEventHandler(onChange);
useEffect(() => {
   if(someCondition) {
      memoizedOnChange();
   }
}, [memoizedOnChange])

Вот тут реализация useStableEventHandler. Основное преимущество – onChange, и всю цепочку зависимостей наверх мемоизировать не надо, мы получим актуальный инстанс в любом случае. Мемоизация скрывается внутри компонента и у его пользователей голова ни о чём не болит

Кажется, мы стали забывать основы фронтенда

Согласен, про "пару узких мест" я преувеличил. В реальности это сложнее.

Это про простоту отладки и про простоту реализации сильно перемудрёных компонент.

Интересно, что может быть проще обычных функций, и как memo-обертки упрощают это еще сильнее?

Кажется, мы стали забывать основы фронтенда

1/16 фрейма - это как раз 1 миллисекунда. 16 таких компонент, "которым оптимизация не нужна" и вы гарантированно получаете просадку fps.

Это в случае, если оптимизация гарантированно улучшает ситуацию. На самом деле этого нет. Моя демка показывает, что цифры там и там одинаковые

Кажется, мы стали забывать основы фронтенда

Речь о том, что как в первом случае никто в здравом уме не пишет. Вместо идиоматичного React сгруппированного в одном месте JSX мы получаем нечто странное. За этим лесом из memo становится не видно деревьев (собственно UI кода).

Достаточно оптимизировать пару узких мест, а не заниматься имитацией бурной деятельности и чинить несломанное.