Завидую себе что давно завязал с нативной ios разработкой и использую React Native. Сам язык swift на начальном этапе дал понять, что инженеры в apple уже далеко не те, и будет хуже.
PS. Кстати многие нынче используют подход из JS/TS - ReSwift вместе с UIKit, и я бы так и делал.
Именно так, тем более всегда можно подменить любой запрос с фронта. Уже пугает что на хабре полно настолько некомпетентных статей, их уже намного больше чем нормальных.
Я честно засомневался - а вдруг действительно затраты на создание новых функций при каждом рендере не такие уж и крохотные, как мне кажется? Давайте разберёмся
"Задним умом все умные". Вы об этом не знали до публикации статьи и чтения комментов.
Ну зато теперь надеюсь запомнили. Правда для этого пришлось "замусорить" Хабр одной некомпетентной статьей.
Ситуация тут уж точно не на стороне автора статьи, он действительно не понимает базовых механизмов хуков, а именно предотвращают ли они создание функции на каждый рендер.
По тексту очевидно, что автор статьи действительно не понимает этого, а значит и самых базовых принципов работы хуков. Собеседующий так и не смог добиться от автора статьи правильного объяснения почему там useCallback не нужен, даже "забайтив" фразой/вопросом "ну функции же создаются заново".
PS. Количество лайков статьи многое говорит об аудитории хабра.
А если исключить ситуации когда водитель пьян, заснул за рулем, не обслуживал автомобиль, превышал сильно скорость в городе и на сложных участках, особенно в первые пару лет вождения, и тп? В общем те ситуации, в которые адекватный и ответственный водитель не попадает? Да еще и добавить сюда простые современные помощники вроде парктроников, камер и тп?
Может вполне оказаться что попасть в дтп в таком случае на "автопилоте" куда более вероятно чем без. Но такую статистику производители автопилотов не приводят.
Суть всей ситуации как раз в том, что полноценный «фикс» ты не получишь, невозможно сделать полноценный автопилот современными технологиями, который тебя гарантированно не попытается убить. И никакие багрепорты не помогут, а поможет либо держать руль и смотреть на дорогу, либо вообще его отключить.
Если вы этого так и не поняли, то лучше вам теслу не покупать.
Все эти горе-«автопилоты» это игра а русскую рулетку, 20 раз проедет, чем создаст иллюзию безопасности, 21 раз убьет.
По хорошему либо их запретить полностью, либо засудить на много миллиардов за то, что вводят в заблуждение пользователей названиями «автопилот» и используют недобросовестный маркетинг, и не заставляют водителя постоянно держать руки на руле, с отключением «автопилота» если это не так.
А настоящий автопилот на дорогах общего пользования с нынешними технологиями разработать невозможно, что было ясно еще много лет назад (но не маркетологам и Илону), так как нужен полноценный ИИ.
Если у оппонента низкая компетентность, но он этого не осознает и пишет откровенно ошибочные утверждения, выдавая за истину, нет ничего плохого в том, чтобы ему на это указать. Если ты не очень хороший программист то в будущем стоит вместо утверждений задавать вопросы. А тот человек еще и целую статью написал по теме, в которой не разбирается, чем распространяет свое невежество в среде разработчиков, что я считаю очень вредным явлением.
По поводу «вместо фактических аргументов» - я уже целую лекцию тут всем провел, начиная с возможности использовать в redux несколько сторов, заканчивая нормализацией, правильным хранением данных в сторе и deep linking, и даже недостатки mobx, пока отвечал на вопросы. Можно отдельную статью писать по каждому пункту. «Если бы у вас действительно были аргументы» - многое говорит и о вас раз вы этого не заметили.
Критика боилерплейта redux это почти всегда рассуждения на примерах типа hello world. Вот только во-первых его можно очень неплохо "причесать", а во-вторых - с ростом проекта он не увеличивается, в отличие от MobX, где растет количество связей, появляются нетипичные проблемы, решать которые просто не получится, такие как сериализация, или инициализация большого куска данных из сохраненного состояния. В redux состояние это всегда максимально тупая структура, которую можно целиком стерилизовать и десериализовать при желании, а нетипичные ситуации практически отсутствуют - на все есть продуманное, популярное решение. А для mobx даже появился mobx-state-tree, чтобы решить эту архитектурную проблему.
Наиболее стандартный пример с одним стором потому и стандартный, потому что на практике это отлично работает, и даже не требуется разбивать на сторы, а для оптимизации достаточно грамотное использование и какой нибудь reselect, и только если нужно совсем хорошо, можно обратиться к нормализации (об этом и написано в доке), и созданию дополнительных сторов, и даже использование React.Context для какой нибудь темы. А практика вообще показывает, что в 95% случаев узкое горлышко это как раз не redux, а неоптимальный код на react, и соответственно выбирать технологию нужно изходя из того, какая проще. Redux намного проще, а значит лучше.
Экраны должны быть автономны, должна быть возможность открывать любой экран хоть при старте приложения, и чтоб он подкачал все что ему требуется. Это нужно, например, для deep lilnking, и если так не делать, то когда это понадобится придется переписать половину приложения. Так же это показатель, что архитектура приложения удачная, и дает много других бонусов, о которых можно статью отдельную писать.
Ну вы можете лицезреть здесь уровень тех, кто так говорит - сплошная некомпетентность, незнание основ redux и react, ни на один мой комментарий нет конструктивной критики или диалога, только минусы.
В redux и без нормализаций хорошо работает, так как при реализации списков элементы списка мемоизируются, и при перерендеринге списка они не перерисовываются если не изменились их данные. Нормализация это скорей для совсем идеального решения.
Именно на таких клиентах никому не придет в голову в здравом уме делать deep comparison когда можно обойтись shallow, и именно такими проектами я и занимался/занимаюсь. Так что не вам мне рассказывать.
Завидую себе что давно завязал с нативной ios разработкой и использую React Native. Сам язык swift на начальном этапе дал понять, что инженеры в apple уже далеко не те, и будет хуже.
PS. Кстати многие нынче используют подход из JS/TS - ReSwift вместе с UIKit, и я бы так и делал.
Именно так, тем более всегда можно подменить любой запрос с фронта. Уже пугает что на хабре полно настолько некомпетентных статей, их уже намного больше чем нормальных.
"Задним умом все умные". Вы об этом не знали до публикации статьи и чтения комментов.
Ну зато теперь надеюсь запомнили. Правда для этого пришлось "замусорить" Хабр одной некомпетентной статьей.
Ситуация тут уж точно не на стороне автора статьи, он действительно не понимает базовых механизмов хуков, а именно предотвращают ли они создание функции на каждый рендер.
По тексту очевидно, что автор статьи действительно не понимает этого, а значит и самых базовых принципов работы хуков. Собеседующий так и не смог добиться от автора статьи правильного объяснения почему там useCallback не нужен, даже "забайтив" фразой/вопросом "ну функции же создаются заново".
PS. Количество лайков статьи многое говорит об аудитории хабра.
А если исключить ситуации когда водитель пьян, заснул за рулем, не обслуживал автомобиль, превышал сильно скорость в городе и на сложных участках, особенно в первые пару лет вождения, и тп? В общем те ситуации, в которые адекватный и ответственный водитель не попадает? Да еще и добавить сюда простые современные помощники вроде парктроников, камер и тп?
Может вполне оказаться что попасть в дтп в таком случае на "автопилоте" куда более вероятно чем без. Но такую статистику производители автопилотов не приводят.
Суть всей ситуации как раз в том, что полноценный «фикс» ты не получишь, невозможно сделать полноценный автопилот современными технологиями, который тебя гарантированно не попытается убить. И никакие багрепорты не помогут, а поможет либо держать руль и смотреть на дорогу, либо вообще его отключить.
Если вы этого так и не поняли, то лучше вам теслу не покупать.
Все эти горе-«автопилоты» это игра а русскую рулетку, 20 раз проедет, чем создаст иллюзию безопасности, 21 раз убьет.
По хорошему либо их запретить полностью, либо засудить на много миллиардов за то, что вводят в заблуждение пользователей названиями «автопилот» и используют недобросовестный маркетинг, и не заставляют водителя постоянно держать руки на руле, с отключением «автопилота» если это не так.
А настоящий автопилот на дорогах общего пользования с нынешними технологиями разработать невозможно, что было ясно еще много лет назад (но не маркетологам и Илону), так как нужен полноценный ИИ.
Не надоело по hello world сравнивать? PS. zustand ни разу не защищаю.
Вопрос не ко мне, товарищ @Modinрешил почему то, что оно лучше чем по ссылке или shallow, без аргументов.
Если у оппонента низкая компетентность, но он этого не осознает и пишет откровенно ошибочные утверждения, выдавая за истину, нет ничего плохого в том, чтобы ему на это указать. Если ты не очень хороший программист то в будущем стоит вместо утверждений задавать вопросы. А тот человек еще и целую статью написал по теме, в которой не разбирается, чем распространяет свое невежество в среде разработчиков, что я считаю очень вредным явлением.
По поводу «вместо фактических аргументов» - я уже целую лекцию тут всем провел, начиная с возможности использовать в redux несколько сторов, заканчивая нормализацией, правильным хранением данных в сторе и deep linking, и даже недостатки mobx, пока отвечал на вопросы. Можно отдельную статью писать по каждому пункту. «Если бы у вас действительно были аргументы» - многое говорит и о вас раз вы этого не заметили.
В вашем редком случае это может быть и оправдано, в статье же нет этому объяснения.
Критика боилерплейта redux это почти всегда рассуждения на примерах типа hello world. Вот только во-первых его можно очень неплохо "причесать", а во-вторых - с ростом проекта он не увеличивается, в отличие от MobX, где растет количество связей, появляются нетипичные проблемы, решать которые просто не получится, такие как сериализация, или инициализация большого куска данных из сохраненного состояния. В redux состояние это всегда максимально тупая структура, которую можно целиком стерилизовать и десериализовать при желании, а нетипичные ситуации практически отсутствуют - на все есть продуманное, популярное решение. А для mobx даже появился mobx-state-tree, чтобы решить эту архитектурную проблему.
Наиболее стандартный пример с одним стором потому и стандартный, потому что на практике это отлично работает, и даже не требуется разбивать на сторы, а для оптимизации достаточно грамотное использование и какой нибудь reselect, и только если нужно совсем хорошо, можно обратиться к нормализации (об этом и написано в доке), и созданию дополнительных сторов, и даже использование React.Context для какой нибудь темы. А практика вообще показывает, что в 95% случаев узкое горлышко это как раз не redux, а неоптимальный код на react, и соответственно выбирать технологию нужно изходя из того, какая проще. Redux намного проще, а значит лучше.
Экраны должны быть автономны, должна быть возможность открывать любой экран хоть при старте приложения, и чтоб он подкачал все что ему требуется. Это нужно, например, для deep lilnking, и если так не делать, то когда это понадобится придется переписать половину приложения. Так же это показатель, что архитектура приложения удачная, и дает много других бонусов, о которых можно статью отдельную писать.
Ну вы можете лицезреть здесь уровень тех, кто так говорит - сплошная некомпетентность, незнание основ redux и react, ни на один мой комментарий нет конструктивной критики или диалога, только минусы.
Передавать в экран объект вместо id это плохо всегда. Между вложенными компонентами допустимо. И да, инструменты тут ни при чем.
В redux и без нормализаций хорошо работает, так как при реализации списков элементы списка мемоизируются, и при перерендеринге списка они не перерисовываются если не изменились их данные. Нормализация это скорей для совсем идеального решения.
Именно на таких клиентах никому не придет в голову в здравом уме делать deep comparison когда можно обойтись shallow, и именно такими проектами я и занимался/занимаюсь. Так что не вам мне рассказывать.
Для ссылок придумали useRef. Почитайте доку. Хотя что имеется ввиду вообще не ясно.
Грамотный логаут мало того, что очищает стор, так по хорошему еще и перезагружает страницу.