Самый большой недостаток контекста в том, что при его обновлении происходит перерисовка всего дерева дочерних компонентов. Поэтому 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, мы обязательно напишем об этом отдельно
Спасибо вам и всем другим комментаторам за активную обратную связь! При переводе мы преследовали цель — помочь тем, кто находится на начальном этапе изучения нового для себя фреймворка, подсказать, что есть определенные способы передачи данных между компонентами. Обязательно обратим внимание на ваши уточнения. В будущем, возможно, выкатим статью про указанные кейсы)
Добрый день! Производительность Tree.js-приложений больше зависит от видеокарты, основные вычисления производятся именно там. Это нормально, что кулер начинает шуметь — нагрузка немного возрастает, поэтому веб-страница при открытии напоминает видеоигру. В идеале необходимо тестировать WebGL-страницы на производительность — ее можно оптимизировать настройками. Для слабых компьютеров можно отключить совсем. Статистика использования Three.js растет с каждым годом. Также предлагаю посмотреть другие сайты, использующие Three.js.
Статистика загрузок насчитывает порядка миллиона в неделю. И это только Three.js, но существует множество других библиотек. Для сравнения у Vue 3-4 миллиона загрузок в неделю, React — 15-17 миллионов, но эти два фреймворка общего назначения. На мой взгляд, использование WebGl в веб-разработке будет расти с каждым годом по мере подготовки специалистов и роста производительности компьютеров.
Данный способ очень подробно описан в документации. Можно там посмотреть, как это правильно делается. На наш взгляд, способ слишком «костыльный», чтобы применять его на практике. Человек, который не знает этот нюанс или забыл, может не понять, что там происходит. WatchEffect позволяет сделать это более аккуратно, понятно и с меньшим количеством кода.
У watchEffect есть свои плюсы, например, он позволяет отслеживать сразу несколько переменных. Кроме того, благодаря свойствам flush, onTrack, onTrigger можно оптимизировать некоторые процессы вычислений, а также watchEffect предоставляет удобный метод для отмены асинхронных операций.
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, мы обязательно напишем об этом отдельно
Спасибо вам и всем другим комментаторам за активную обратную связь! При переводе мы преследовали цель — помочь тем, кто находится на начальном этапе изучения нового для себя фреймворка, подсказать, что есть определенные способы передачи данных между компонентами. Обязательно обратим внимание на ваши уточнения. В будущем, возможно, выкатим статью про указанные кейсы)
Добрый день! Производительность Tree.js-приложений больше зависит от видеокарты, основные вычисления производятся именно там. Это нормально, что кулер начинает шуметь — нагрузка немного возрастает, поэтому веб-страница при открытии напоминает видеоигру. В идеале необходимо тестировать WebGL-страницы на производительность — ее можно оптимизировать настройками. Для слабых компьютеров можно отключить совсем. Статистика использования Three.js растет с каждым годом. Также предлагаю посмотреть другие сайты, использующие Three.js.
Статистика загрузок насчитывает порядка миллиона в неделю. И это только Three.js, но существует множество других библиотек. Для сравнения у Vue 3-4 миллиона загрузок в неделю, React — 15-17 миллионов, но эти два фреймворка общего назначения. На мой взгляд, использование WebGl в веб-разработке будет расти с каждым годом по мере подготовки специалистов и роста производительности компьютеров.
Данный способ очень подробно описан в документации. Можно там посмотреть, как это правильно делается. На наш взгляд, способ слишком «костыльный», чтобы применять его на практике. Человек, который не знает этот нюанс или забыл, может не понять, что там происходит. WatchEffect позволяет сделать это более аккуратно, понятно и с меньшим количеством кода.
У watchEffect есть свои плюсы, например, он позволяет отслеживать сразу несколько переменных. Кроме того, благодаря свойствам flush, onTrack, onTrigger можно оптимизировать некоторые процессы вычислений, а также watchEffect предоставляет удобный метод для отмены асинхронных операций.