В Chrome, начиная с версии 79, появилась поддержка экспериментального Keyboard Lock API, которое позволяет отлавливать нажатия системных горячих клавиш для переопределения их в приложении. Это API в данный момент не поддерживается другими вендорами и находится в стадии черновика в Web Platform Incubator Community Group, поэтому сильно завязываться на него не рекомендуется.

https://web.dev/keyboard-lock/

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

Отсюда часто возникает ощущение, что делаю что-то не так, хотя приложение работает.

Возможно существуют какие-то статьи, бест практисы, советы как здесь стоит поступать?
Какой-нибудь аналог пошаговой нормализации таблиц в БД? Чтобы взять общую идею стейта приложения и привести его в нормальный вид?

ахуитильна, блокируешь alt+f4, ctrl alt del и лочишь мышь😂

тесты пишешь?

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

Я только когда начал тестировать "reducer" - понял что хреново спроектировал стейт.

Он получился просто кучей несвязанных моделек, которые вообще UI не выражают.
В итоге оказалась что у меня куча логики во View слое - сейчас переписываю.

(кэп) Когда появляются тесты - сразу начинается "переиспользование кода" и находишь все его минусы.

ждал, когда ты Domain Modelling in F# начнешь советовать

Да я ее сам не читал 😺 и в f# чатике у не спорные отзывы (потому-что люди слишком упарываются).
Но в принципе да - можно почитать. Я жду когда она на русском выйдет.

а такое будет вообще? (вот бы еще в epub вышла)

Пока новостей про это нет, но дк прес всякую дичь переводит)

по элму много докладов про это

У меня даже больше проблем с обработкой этого дела.

Из банального: сейчас в приложении может быть несколько пользователей, соответственно прилетают события типа AddUserEvent и DeleteUserEvent.

Из стейтов есть два возможных состояния DataIsLoading и DataLoaded.

Раньше, при любых изменениях в коллекции пользователей я обновлял все данные целиком, благодаря чему спокойно во всех кейсах выдавал DataIsLoading и DataLoaded.

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

Т.е. при DeleteUserEvent — лишь удалить данные исчезнувшего пользователя, здесь всё просто.
А при AddUserEvent обновить данные для нового пользователя не затрагивая тех, кто уже и так обновлён.

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

Насколько это нормально? Мне просто казалось, что мы должны оперировать только последним стейтом.

чет нихера не понял кейс

> чтобы при изменении в пользователях затрагивались и обновлялись только необходимые.

а зачем?

Я элм слабо вдупляю пока.
Как кто-то выдал тут, что tea == mvi с effect handler суть стала ясна, но синтаксис элма какой-то хаскеле-образно-вырвиглазный

насчёт предыдущего стейта – если он нужен, то никто не мешает его хранить прямо в стейте

> чтобы при изменении в пользователях затрагивались и обновлялись только необходимые.

А зачем обновлять 10 пользователей, когда нужно всего одного?

MVU, а не MVI. MVI про реактивщину в пользовательском коде.
</зануда-mode>

потому что это проще?

что значит "обновлять"?