Сова пишет…
3.13K subscribers
345 photos
37 videos
5 files
417 links
Frontend Senior Fullstack Backend Lead и прочие слова.
Изучаю самые современные технологии.
Обучаю разработчиков как стать сильнее — https://frontend.vision.

По коллаборациям и сотрудничеству пишите в сообщения канала!
Download Telegram
Ещё один сниппет, на этот раз для простого чтения CSS-переменных из js.

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

https://gist.github.com/sergeysova/f1f4d34c59514201494f99c98291185e
Какой кейс проще читается для имен файлов и директорий?
Anonymous Quiz
13%
Смешанный, где как
15%
PascalCase
19%
camelCase
14%
underscore_case
38%
kebab-case
Выползли на выходных на финский залив возле Сестрорецка. Существенный глоток свежего воздуха, после изоляции в душном городе.

Круто, что днём было не жарко, около 23 градусов и ветрено. Гулять сплошное удовольствие.

Хочется выбраться куда-нибудь подальше... из России
This media is not supported in your browser
VIEW IN TELEGRAM
Switch

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

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

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

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

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

enum UserGetError {
InvalidUsername,
UserNotFound,
Unexpected,
}


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

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

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

Если проект с SSR, то проще всего установить effector-root и заменить все импорты на него. Этот пакет заворачивает все сущности в root домен.
Если без SSR, то замените все свои импорты “effector” на “effector-root”, хоть вручную, хоть babel-плагином.

А затем добавьте следующий код в файл инициализации приложения:
import { root } from ‘effector-root’
import { attachLogger } from 'effector-logger/attach';

if (process.env.NODE_ENV !== ‘production’) {
attachLogger(root);
}
Простейший сниппет для чтения кук в браузере или как обойтись без библиотеки.

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

На сервере тоже можно
Forwarded from Dmitriy Shuleshov
Вот моя ментальная модель.

В нашей системе постоянно происходят **события*". Что то пришло по сети, юзер упал лицом лицом в клаву, процессор начал простаивать, etc...

Ивенты эффектора - это события именно в мире эффектора. Апи эффектора:
- позволяет связывать ивенты эффектора по различным сценариям
- позволяет связывать ивенты эффектора с реальными событиями
- позволяет описывать схемы реакции сторов на ивенты

C моей точки зрения, фраза - "апи эффектора создает ивенты" (например фабрикой createEvent), не совсем точно отображает действительность. Хотя эффектор и создает то что более похоже по существу на события, но они скрыты от нас внутри ядра библиотеки. То что называется событием эффектора, на самом деле более точно можно описать как ссылка на событие, которая является индикатором и инициализатором в одном флаконе.

То есть получив ссылку от фабрики таким образом:
const eventLink = createEvent()
мы ее можем использовать двумя способами:
1. Как инициализатор:
document.addEventListener('click', DOMevent => evenLink(DOMevent))
2. Как индикатор:
evenLink.watch((
DOMevent
) => alert(`User clicked on element!`))

Для того что бы связать реальное событие с событием эффектора ментально нужно выполнить следующую операцию:
КОГДА произошло реальное событие, ИНИЦИАЛИЗИРУЙ
запуск ивента эффектора.

Хотя эффектор не накладывает никаких ограничений, но логично когда реальные ивенты связываются только с ссылками ивентов эффектора, произведенных фабрикой createEvent (кроме прочего новые ивенты могут производить такие api методы как sample, guard, merge, event.map, event.prepend, event.filter, event.filterMap, store.updates и набор ивентов производимых эффектом). Или другими словами, реальные ивенты должны инициализировать событие эффектора, только посредством ссылки из фабрики createEvent. Это упрощает ментальное восприятие связей системы и увеличивает предсказуемость ее работы.
То есть в телегу завезли треды
ОХ, ну случилось таки
let app_data: Data<Arc<Mutex<App<Database>>>>

Волшебный тип
Accesso имеет логотип из трех точек разного формата.

Я слегка упоролся и сделал loader в этом формате, но в двух вариантах: все точки одинаковые и точки повторяют логотип
Благодаря помощи чата, вспомнил простую истину анимаций: не надо вызывать reflow анимируемого элемента. В прошлой реализации я менял положение элемента среди других элементов, что вызывало пересчет положений, а следствие подергивание анимации, которое видно в предыдущем посте.

Когда вся анимация стала только transform, пересчета положений нет, сдвигается только само изображение элемента, хотя "физически" элемент остается на месте — в центре блока.

Собственно изменения можно заметить по замедленной увеличенной анимации. Кстати, эту вкладку можно открыть в выпадающей по Esc панели chrome devtools.

Всем спасибо!