Затащил inspector в effector-logger.
Пока что в next версии в npm.

yarn add effector-logger@next

Прошу проверить его работоспособность.
https://github.com/sergeysova/effector-logger#inspector

Нужно добавить createInspector() после инициализации приложения, а после запуска, в браузере нажать CTRL+B

Узнал, что с помощью Intl.Collator можно вменяемым способом сравнивать локализованные строки.

Сохраните себе на заметку, если не знали раньше

Я и раньше занимался личными консультациями, но только сейчас осмелился выложить лот на страничку в Buymeacoffee.

Пообщаюсь о том как писать React-приложения, строить архитектуру, зачем нужна структура проекта, как можно организовать команду и как решать конфликты с коллегами. С удовольствием поболтаю на свободную тему, если хочется)

https://www.buymeacoffee.com/sergeysova — Консультация в Zoom

Второй выпуск подкаста «Сова говорит...»
React hooks, classes and bad practice

Поговорим об истории React, как появились хуки, чем плохи классы и ХОКи, разберем построение систем на примере ракет, и как работает развитие технологий на примере репейника.

https://podcast.sova.dev/episodes/1-1-react-hooks-classes-and-bad-practice

Слушать подкаст можно по этим ссылкам

Яндекс.Музыка
https://music.yandex.ru/album/8469435

Google Podcasts
https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS8xeHRNRlZWcA

Apple Podcasts
https://podcasts.apple.com/us/podcast/%D1%81%D0%BE%D0%B2%D0%B0-%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B8%D1%82/id1476506663

VK
https://vk.com/podcasts-188742863

Stitcher
https://www.stitcher.com/podcast/sergey-sova/sova-speaking?refid=stpr

А теперь на SoundCloud
https://soundcloud.com/sergeysova/11-react-hooks-classes-and-bad-practices

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

В примере выше, все четыре таски будут ждать, пока builder-image и start-tools-image соберутся параллельно.

То есть, не нужно указывать, что собирать паралельно, а что последовательно, CI сам разберется как собирать и в каком порядке. Вот это декларативный подход во все поля.

Недавно столкнулся с необходимостью точно узнать во что разворачиваются короткие CSS-свойства. Например: padding в padding-top, padding-right, padding-bottom, padding-left

В интернетах нашел сниппет, который обращается в document.body.style, но оказалось, что на типичной странице в этом поле уже куча стилей, и сниппет не работает одинаково во всех кейсах. Мне пришлось поправить этот сниппет, чтобы он работал на всех страницах одинаково и предсказуемо. Подумал, что и вам это может быть удобно.

https://gist.github.com/sergeysova/b003fae5670a476c28ff2ff972ec7fbc

Вернемся к CRA.
Этим рассадником я конечно же больше пользоваться не буду. Потому что есть альтернативы:

1. Parcel — самый простой и быстрый старт, но не так всё хорошо с кастомизацией. Лично мой хейт за тильды ~ в качестве несменяемых алиасов для корня проекта. Ещё Parcel не умеет работать с file:../.. зависимостями, по тихому подменяет на версию и устанавливает из интернетов. При всех минусах я его активно юзаю

2. Razzle — да, мы все привыкли, что он не очень хорошо развивается и нужен только для SSR, но на самом деле в него добавляются новые фичи, замержили шаблоны в стиле CRA, а также есть SPA mode. Собственно теперь Razzle является полноценной заменой CRA, при этом без его проблем с кастомизацией и навязываением своих проблем. Используйте babel как удобно. Самое важное, что Razzle поддерживает не только React, ещё и preact, elm, inferno, rax, angular, vue и что-нибудь своё. Например, можно легко сделать шаблон для forest.

Я очень рад, что отвратительное отношение авторов CRA к своим пользователям это не единственный вариант из списка готовых стартеров.

Ещё один сниппет, на этот раз для простого чтения CSS-переменных из js.

trim() нужен, чтобы убрать всякий мусор, а reader облегчает обработку значений.

https://gist.github.com/sergeysova/f1f4d34c59514201494f99c98291185e

Switch

Многие часто воспринимают его как замену Checkbox — выбор true/false значения в форме, но семантика и UX отличается у этих компонентов.

Было бы странно создать новый компонент, который ведет себя также как и привычный всем Checkbox. Для начала нужно вспомнить, где используется Checkbox:
- в формах входа "Запомнить пароль"
- во время регистрации "Принимаю соглашение"
- в качестве флага включающего часть формы "Нужна доставка"
Самое важное — чекбокс сам по себе не изменяет внешнее состояние, то есть не отправляет данные куда-либо, то есть ведет себя как обычный input — отправляется как часть формы при нажатии на кнопку "Отправить" или "Сохранить".

Switch напротив, является самостоятельным компонентом, он изменяет внешнее состояние сразу после изменения. Ему не нужна форма или отдельный сабмит, ведь свитч сам по себе сигнализирует о своем состоянии и меняет его мгновенно. Примеры:
- frozen в codesandbox
- WiFi в iOS
- Персонализация для бизнеса в myaccount Google

Детали реализации
Зачастую изменение состояния на сервере требует времени, и иногда эту задержку полезно показать на самом компоненте — задержать переключение тумблера в Switch на середине в состоянии loading, а также показать легкое оповещение "Изменено", так пользователь точно поймет, что изменение происходит не мгновенно и действительно что-то меняет, нет необходимости применять изменения.

Switch должен быть доступен через клавиатуру, пробел или space должны переключать его.

Полезные ссылки по компоненту Switch

https://material.io/components/selection-controls#radio-buttons
https://developer.apple.com/design/human-interface-guidelines/ios/controls/switches/
https://ant.design/components/switch/

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

По сути это следствие отсутствия эксепшенов в языке, все ошибки возвращаются через тип Result<T, E>. И зачастую сами ошибки тоже описываются в виде enum:

enum UserGetError {
InvalidUsername,
UserNotFound,
Unexpected,
}

при попытке получить значение из функции возвращающей Result, раст заставит обработать ситуацию, если вернулась ошибка, а при обработке ошибок заставит обработать все из списка.

Чем это полезно. Если в слое базы данных появится новая ошибка, раст заставит во всех местах обработать эту новую ошибку. Это вынудит добавить новый тип ошибки в слое бизнес-логики и обработать правильно. Тоже самое будет в слое веб-фреймворка. А значит, пользователь увидит вменяемую ошибку, корректно обработанную на каждом шаге.

ОЧЕНЬ ХОЧУ ПОДОБНЫЙ МЕХАНИЗМ В TypeScript.
Хочу, чтобы ts заставил меня обработать все варианты ошибок. Сколько же проблем этот механизм снял бы. Хоть пиши свой язык поверх тс, или жс.