Самый большой недостаток контекста в том, что при его обновлении происходит перерисовка всего дерева дочерних компонентов. Поэтому react context используют для данных, которые меняются редко, такие как выбор темы или языка всего приложения.
Америку не открыли, но личный опыт использования mobX совсем небольшой — на проекте, где все было сильно запутано.
Если сравнивать DX, то представляется такой образ: Redux — большая организация со сложной бюрократией, mobX — частная фирма с теми же услугами, Effector — онлайн-стартап.
Статья основана на личном опыте, и в нем был Redux Toolkit, но на том проекте все равно использовали саги для асинхронных запросов. Так что упомянутая проблема с отсутствием импортов-экспортов оставалась.
Как я отмечаю в статье, Effector мне понравился больше тем, что оказался понятнее и нагляднее. Не спорю, что для кого-то другого Redux лучше :)
Внесли изменения в описание и имплементацию быстрой сортировки. Благодарим, что заметили! По поводу двоичного поиска — можете привести примеры подобной реализации? В примерах, которые находил я, возвращается индекс искомого элемента, если я вас правильно понял. Заранее спасибо!
Действительно, пункт, где говорится, что алгоритм стоит использовать, если нет ограничений по памяти, был ошибочным. Текст скорректировали. Спасибо за замечание!
Алгоритмы со сложностью O(n) и O(2n) идентичны, так как Big O не определяет скорость работы алгоритма, он показывает зависимость алгоритма от входных данных. Можно обратиться к материалам на эту тему: раз и два
Разрешено все, что не запрещено (или не замечено :D).
Чтобы понять, почему подход с прокидыванием экземпляра класса — плохой, давайте заменим его на нечто знакомое в мире Vue. Экземпляр класса — это ничто иное, как экземпляр родительского компонента, только вынесен в другой файлик. То есть у нас есть состояние, есть методы, которые это состояние меняют.
Если обратиться к документации, где сказано, что мутирование props — это плохо, потому что приводит к боли, получается, что прокидывание самих методов с их последующим вызовом — это плохо и больно.
Используя экземпляр класса в качестве props с последующим мутированием его состояния приведет к тому, что будет сложно отслеживать, кто же дернул этот метод. К тому же в классическом компонентном подходе, каждый компонент — это "черный ящик" с приватной реализацией собственной логики и состояния.
Взаимодействие с компонентами осуществляется за счет публичного интерфейса — props/emits. В большинстве проектов и Vuex (помянем) / Pinia не нужны, так как хранить глобальное состояние отдельно от представления нужно далеко не всегда.
Однако если уж прям хочется вынести логику в сервис, создав франкенштейна во фронтенде с костыльной слоистой архитектурой, то вам в Angular использование Vuex / Pinia будет наилучшим решением, чем придумывать слой данных на коленках. Даже в этом случае нужно будет обеспечивать высокую связанность компонентов и держать store/view слои где-то рядом (посмотрите на Gitlab исходники)
Кратко: Нет, так делать не нужно, так как в долгой перспективе приведет к сильной связности/сложному дебагу и ужасному опыту тестирования
Спасибо, решение $mol на первый взгляд выглядит более лаконичным, возможно, ваш пример пригодится читателям при выборе инструментов для сборки пакетов.
Действительно, вы правы, Composition API — это использование функции setup внутри тега <script> с применением описанных вами технологий, которые стали доступны в третьей версии Vue. Однако функцию setup можно использовать и описанным в статье образом с помощью <script setup>
В статье приведены примеры импорта компонентов, которые будут понятны новичкам. Один из комментаторов ниже обратил внимание на отсутствие таких вещей, как Global component, и в будущем мы обязательно о них расскажем.
Увы, в оригинале статьи автор не делает упор на использовании Vue в тандеме с TypeScript, поэтому более точная типизация массива опущена. Однако спасибо за дельное замечание, если у наших читателей будет интерес к теме Vue + TypeScript, мы обязательно напишем об этом отдельно
Спасибо вам и всем другим комментаторам за активную обратную связь! При переводе мы преследовали цель — помочь тем, кто находится на начальном этапе изучения нового для себя фреймворка, подсказать, что есть определенные способы передачи данных между компонентами. Обязательно обратим внимание на ваши уточнения. В будущем, возможно, выкатим статью про указанные кейсы)
Такой вариант не рассматривали. Интересно, можно попробовать. Спасибо за идею!
Надеемся, что наш кейс поможем вам предотвратить подобную ситуацию)
Спасибо, учтем на будущее момент со скриншотами:) на всякий случай тут отметим, как должно было быть, и как было в реальности
zustand не пробовала, но, справедливости ради, к Redux devtools эффектор тоже подключается
Самый большой недостаток контекста в том, что при его обновлении происходит перерисовка всего дерева дочерних компонентов. Поэтому react context используют для данных, которые меняются редко, такие как выбор темы или языка всего приложения.
Америку не открыли, но личный опыт использования mobX совсем небольшой — на проекте, где все было сильно запутано.
Если сравнивать DX, то представляется такой образ: Redux — большая организация со сложной бюрократией, mobX — частная фирма с теми же услугами, Effector — онлайн-стартап.
Статья основана на личном опыте, и в нем был Redux Toolkit, но на том проекте все равно использовали саги для асинхронных запросов. Так что упомянутая проблема с отсутствием импортов-экспортов оставалась.
Как я отмечаю в статье, Effector мне понравился больше тем, что оказался понятнее и нагляднее. Не спорю, что для кого-то другого Redux лучше :)
Внесли изменения в описание и имплементацию быстрой сортировки. Благодарим, что заметили! По поводу двоичного поиска — можете привести примеры подобной реализации? В примерах, которые находил я, возвращается индекс искомого элемента, если я вас правильно понял. Заранее спасибо!
Действительно, пункт, где говорится, что алгоритм стоит использовать, если нет ограничений по памяти, был ошибочным. Текст скорректировали. Спасибо за замечание!
Алгоритмы со сложностью O(n) и O(2n) идентичны, так как Big O не определяет скорость работы алгоритма, он показывает зависимость алгоритма от входных данных. Можно обратиться к материалам на эту тему: раз и два
Спасибо за замечание, внесли изменения в текст
Действительно, кавычки лишние мешали. Спасибо, что обратили внимание, поправили)
Разрешено все, что не запрещено (или не замечено :D).
Чтобы понять, почему подход с прокидыванием экземпляра класса — плохой, давайте заменим его на нечто знакомое в мире Vue. Экземпляр класса — это ничто иное, как экземпляр родительского компонента, только вынесен в другой файлик. То есть у нас есть состояние, есть методы, которые это состояние меняют.
Если обратиться к документации, где сказано, что мутирование props — это плохо, потому что приводит к боли, получается, что прокидывание самих методов с их последующим вызовом — это плохо и больно.
Используя экземпляр класса в качестве props с последующим мутированием его состояния приведет к тому, что будет сложно отслеживать, кто же дернул этот метод. К тому же в классическом компонентном подходе, каждый компонент — это "черный ящик" с приватной реализацией собственной логики и состояния.
Взаимодействие с компонентами осуществляется за счет публичного интерфейса — props/emits. В большинстве проектов и Vuex (помянем) / Pinia не нужны, так как хранить глобальное состояние отдельно от представления нужно далеко не всегда.
Однако если уж прям хочется вынести логику в сервис, создав франкенштейна во фронтенде с костыльной слоистой архитектурой, то
вам в Angularиспользование Vuex / Pinia будет наилучшим решением, чем придумывать слой данных на коленках. Даже в этом случае нужно будет обеспечивать высокую связанность компонентов и держать store/view слои где-то рядом (посмотрите на Gitlab исходники)Кратко: Нет, так делать не нужно, так как в долгой перспективе приведет к сильной связности/сложному дебагу и ужасному опыту тестирования
Спасибо, решение $mol на первый взгляд выглядит более лаконичным, возможно, ваш пример пригодится читателям при выборе инструментов для сборки пакетов.
Спасибо за уточнения! Касательно п.2 сделали дополнение в тексте
Такого опыта не было, там скорее всего понадобится решение с бэка. Но возможно, кто-то из других читателей сталкивался и готов поделиться)
Библиотеки в топе могут варьироваться для каждого разработчика. Можно обратиться, например, к таким: Shopify Polaris React, Adobe Spectrum, Microsoft Fluent UI React
Действительно, вы правы, Composition API — это использование функции setup внутри тега <script> с применением описанных вами технологий, которые стали доступны в третьей версии Vue. Однако функцию setup можно использовать и описанным в статье образом с помощью <script setup>
В статье приведены примеры импорта компонентов, которые будут понятны новичкам. Один из комментаторов ниже обратил внимание на отсутствие таких вещей, как Global component, и в будущем мы обязательно о них расскажем.
Увы, в оригинале статьи автор не делает упор на использовании Vue в тандеме с TypeScript, поэтому более точная типизация массива опущена. Однако спасибо за дельное замечание, если у наших читателей будет интерес к теме Vue + TypeScript, мы обязательно напишем об этом отдельно
Спасибо вам и всем другим комментаторам за активную обратную связь! При переводе мы преследовали цель — помочь тем, кто находится на начальном этапе изучения нового для себя фреймворка, подсказать, что есть определенные способы передачи данных между компонентами. Обязательно обратим внимание на ваши уточнения. В будущем, возможно, выкатим статью про указанные кейсы)