Вы называете объект литералом — теперь поняла :) Спасибо за замечание! В реальном коде я извлекла ссылки до useLayoutEffect, и массив зависимостей выглядит как-то так: [block1Ref.current, block2Ref.current].
Спасибо за оценку! Мной движет оптимизм 🙂 К слову о ненужных зависимостях, моя практика утверждает обратное: если их удалить, то линтер и правда не ругается, но высота третьего блока не будет обновляться динамически.
Не совсем поняла эту часть — «когда работаешь с хуками нельзя конфигурировать их литералами». Уточните, пожалуйста.
Самый большой недостаток контекста в том, что при его обновлении происходит перерисовка всего дерева дочерних компонентов. Поэтому 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 на первый взгляд выглядит более лаконичным, возможно, ваш пример пригодится читателям при выборе инструментов для сборки пакетов.
Вы называете объект литералом — теперь поняла :)
Спасибо за замечание! В реальном коде я извлекла ссылки до useLayoutEffect, и массив зависимостей выглядит как-то так: [block1Ref.current, block2Ref.current].
Это слишком скучно :)
Спасибо за оценку! Мной движет оптимизм 🙂 К слову о ненужных зависимостях, моя практика утверждает обратное: если их удалить, то линтер и правда не ругается, но высота третьего блока не будет обновляться динамически.
Не совсем поняла эту часть — «когда работаешь с хуками нельзя конфигурировать их литералами». Уточните, пожалуйста.
Такой вариант не рассматривали. Интересно, можно попробовать. Спасибо за идею!
Надеемся, что наш кейс поможем вам предотвратить подобную ситуацию)
Спасибо, учтем на будущее момент со скриншотами:) на всякий случай тут отметим, как должно было быть, и как было в реальности
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