Почему лучше? Я буквально неделю назад купил такой же как и у ТС, работает хорошо. Правда, я его использую с ESPHome, где дополнительно настроено устранение дребезга и все такое.

Бывает такое. Когда я ещё пользовался windows, для просмотра картинок всегда использовал ACDSee 3.1, хотя были гораздо более свежие версии. Но те комбайны мне были не нужны, а просмотр идеально работал и в 3.11 давая мне все что нужно.

конфиг можно забекапить

про сохранение/восстановление конфигурации

Добавлю свои пять копеек: на XigmaNAS (ex Nas4Free) конфиг можно забекапить. И восстановить за пять минут, мне это доводилось делать - работает. На OMV такого нет и не будет (их ответ в одной из тем) ввиду того, как OMV построен. Для меня это один из аргументов против.

Какие датчики присутствия вы использовали? Если это FP2, то где достали? :) И с каким регионом. Спасибо

Установите keka и забудьте о проблемах с архивами на маке

Можете пояснить? SSC framework - это вроде как вообще набор практик по работе с open source software. Там есть какие-то рекомендации по работе с формами?

Внутри ведь происходит ровно то же самое: react ловит submit event, и если action - это функция, то вызывает ее. Но ловить submit могу я и сам...

в чем преимущество использования form.action над form.onSubmit?

Я почему-то думал, что для грязной воды вывод будет толще. Не засориться ли эта белая трубочка?

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

Вы не знаете, есть ли ограничение на длину трассы? Извините, что столько вопросов, сам подумывал о покупке пылесоса с подключением к канализации.

Если у вас есть IDE, то она подскажет порядок и для массивов. Если вы используете TS, то там еще проще - можно указать название каждого элемента.

Меня лично не напрягают висящие запятые, они не мешают чтению кода.

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

Собственно, этим. Неудобство использования с множественными хуками. Тот же useState не случайно возвращает массив, а не что-то вроде {state, setState}. Представьте, как выглядел бы код, будь оно так.

В остальном, никто не мешает использовать объекты, особенно, если есть уверенность, что таковой хук будет использовать только единожды в компоненте. Например, значение возвращаемое useContext.

Не надо использовать объект, это зло. С массивом вам тоже никто не запрещает брать только то, что нужно:

const [myData] = useFetch(...);
const [anotherData,, error] = useFetch(...);
const [, loading] = useFetch(...);

И массив избавляет от глупых переименований, когда используются несколько таких хуков. Если бы возвращали объект, то пример выше надо было бы переписать так:

const { data: myData } = useFetch(...);
const { data: anotherData, error } = useFetch(...);

Всё тоже самое можно делать с MobX. Только вот props hell это дичь и от этого много лет назад ушли.

С какого количества пропсов начинается hell? Почему вообще использование props считается чем-то плохим, ведь в этом вся фишка реакта - черная коробочка pure function, в которую на вход даешь одно и всегда получаешь одно и то же.

Про вынужденный говнокод (и как бы ты не старался он 10000% будет говнокодом) из-за этого подхода я вообще молчу.

Есть какой-нибудь пример кода с mobx, который вам не кажется говнокодом? Может быть некий open source проект.

Сходу две проблемы:
- с mobx вы адаптируете код под mobx. В отличии от redux'а, где компоненты продолжают использовать пропсы и им начхать откуда они пришли и куда ведут колбеки. При желании можно заменить стор.
- из-за использования observable, стор mobx не может хранить большую коллекцию сложных объектов (это касается любых подобных решений, в т.ч., например, redux toolkit). Несколько лет назад я проводил тестирование: mobx со скрипом позволял обрабатывать 50к таких объектов, redux с легкостью 200к.

Но это не значит, что mobx надо хоронить, как вы спешите хоронить redux. Полагаю, mobx прекрасно себя показывает в небольших приложениях.
Redux надо уметь готовить, тогда не будет никакого особого бойлерплейта, ведь, полагаю, именно это является объектом критики.

что вы можете предложить в качестве альтернативы?