Добавлю свои пять копеек: на XigmaNAS (ex Nas4Free) конфиг можно забекапить. И восстановить за пять минут, мне это доводилось делать - работает. На OMV такого нет и не будет (их ответ в одной из тем) ввиду того, как OMV построен. Для меня это один из аргументов против.
Можете пояснить? SSC framework - это вроде как вообще набор практик по работе с open source software. Там есть какие-то рекомендации по работе с формами?
Внутри ведь происходит ровно то же самое: react ловит submit event, и если action - это функция, то вызывает ее. Но ловить submit могу я и сам...
Если у вас есть IDE, то она подскажет порядок и для массивов. Если вы используете TS, то там еще проще - можно указать название каждого элемента.
Меня лично не напрягают висящие запятые, они не мешают чтению кода.
А вообще, ситуация несколько надуманная. В рамках одного проекта обычно используется ограниченное количество хуков, и запоминание сигнатуры часто используемых происходит само собой.
Собственно, этим. Неудобство использования с множественными хуками. Тот же useState не случайно возвращает массив, а не что-то вроде {state, setState}. Представьте, как выглядел бы код, будь оно так.
В остальном, никто не мешает использовать объекты, особенно, если есть уверенность, что таковой хук будет использовать только единожды в компоненте. Например, значение возвращаемое useContext.
И массив избавляет от глупых переименований, когда используются несколько таких хуков. Если бы возвращали объект, то пример выше надо было бы переписать так:
Всё тоже самое можно делать с 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 надо уметь готовить, тогда не будет никакого особого бойлерплейта, ведь, полагаю, именно это является объектом критики.
У них было время с июня, чтобы найти и пофиксить баги. Тем более такие явные, как скроллинг карты. Чего они ждали?
UPD: комментарий ниже несколько проясняет суть проблемы.
Не, похожая у меня: тоже есть wallet.dat, только вот ключа не помню :) Вроде есть брутфорсеры, да и примерно ключ помню, но пока ради 1.5 биткойнов напрягаться времени нет.
В спб есть еще и igooods, а у самоката странная зона работы. И если еще можно понять (но не простить) отсутствие рыбацкого, то за что выкусили кусок весёлого поселка (между подвойского и коллонтай) — вообще непонятно.
Ставишь промежуточную точку — получаешь меньшее время.
Емнип, у них там были критерии «комфортности» маршрута. Т.е., например, маршрут прокладывается так, чтобы на нем было меньше поворотов.
Я тоже знаю такие места, где можно проехать быстрее, но они требуют несколько лишних поворотов или проездов по небольшим улочкам, хоть я и не против. А яндекс по ним не прокладывает.
Да! Их легко находить на ощупь и легко перемещать палец с кнопок лево/право на вверх/вниз, т.к. ты всегда знаешь их относительное расположение. Я вообще очень расстроился, когда в новых клавиатурах стали ставить огромные кнопки лево/право. Но, похоже, что не все еще потеряно.
про сохранение/восстановление конфигурации
Добавлю свои пять копеек: на 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.
Не надо использовать объект, это зло. С массивом вам тоже никто не запрещает брать только то, что нужно:
И массив избавляет от глупых переименований, когда используются несколько таких хуков. Если бы возвращали объект, то пример выше надо было бы переписать так:
С какого количества пропсов начинается hell? Почему вообще использование props считается чем-то плохим, ведь в этом вся фишка реакта - черная коробочка pure function, в которую на вход даешь одно и всегда получаешь одно и то же.
Есть какой-нибудь пример кода с mobx, который вам не кажется говнокодом? Может быть некий open source проект.
Сходу две проблемы:
- с mobx вы адаптируете код под mobx. В отличии от redux'а, где компоненты продолжают использовать пропсы и им начхать откуда они пришли и куда ведут колбеки. При желании можно заменить стор.
- из-за использования observable, стор mobx не может хранить большую коллекцию сложных объектов (это касается любых подобных решений, в т.ч., например, redux toolkit). Несколько лет назад я проводил тестирование: mobx со скрипом позволял обрабатывать 50к таких объектов, redux с легкостью 200к.
Но это не значит, что mobx надо хоронить, как вы спешите хоронить redux. Полагаю, mobx прекрасно себя показывает в небольших приложениях.
Redux надо уметь готовить, тогда не будет никакого особого бойлерплейта, ведь, полагаю, именно это является объектом критики.
что вы можете предложить в качестве альтернативы?
UPD: комментарий ниже несколько проясняет суть проблемы.
Емнип, у них там были критерии «комфортности» маршрута. Т.е., например, маршрут прокладывается так, чтобы на нем было меньше поворотов.
Я тоже знаю такие места, где можно проехать быстрее, но они требуют несколько лишних поворотов или проездов по небольшим улочкам, хоть я и не против. А яндекс по ним не прокладывает.
Да! Их легко находить на ощупь и легко перемещать палец с кнопок лево/право на вверх/вниз, т.к. ты всегда знаешь их относительное расположение. Я вообще очень расстроился, когда в новых клавиатурах стали ставить огромные кнопки лево/право. Но, похоже, что не все еще потеряно.