Да. Есть такое дело, конечно “use-between” не защитит.
Современная бизнес ориентированная среда фронтенда продвигает идею, что не нужно решать проблем производительности до их появления. А архитекторы же напротив будут требовать закладывать как можно более надежный фундамент и контролировать код в течении всей его жизни с первых дней.
Реальный пример из жизни, я работал над большим проектом с redux, где повсеместно в компонентах использовался “useSelector”, мейнтейнер так беспокоился о производительности функций компонентов, что все вычисления вынес внутрь “useSelector”. А в итоге сработал обратый эффект, так как при изменении любого значения внутри стора даже самого незначительного запускались пересчёты всех “useSelector” из отображенных компонентов. В какой-то момент это стало заметно.
Для меня use-between это так же и уход от единого стора и возможность делить данные так, что бы пересчётов было как можно меньше. Что бы сторы были как можно проще и вообще я бы ввел ограничение на размер файла в один-два экрана для 95% случаев), что бы код было проще читать.
Грамотное использование React.memo, маленькие сторы, слежение за эффектами и как можно более “плоская” структура, так как чем больше вложений тем сложнее размотать потом код.
Хорошо что всё эти рекомендации применимы к Реакт приложению и без use-between!)
Классно написал про MobX, я тоже писал свой плагин на babel, что бы автоматически оборачивать компоненты в observer) нашелся бы кто-нибудь кто в open source оформил бы такой, да что бы ещё работал на SWC, вообще б цены не было!
Хм. Удивительно грубая речь. Думаю вопрос риторический. Могу немного перефразировать, следует вкладывать смысл во всё что мы пишем, а не только в код. Не писать глупостей и лишнего)
Мне больше всех нравятся минималистичные варианты типа Jotai, на работе пишу на Mobx, но для своих проектов использую личные разработки (например Remini), в какой-то момент становиться интереснее написать то что самому себе хочется, чем мириться с проблемами любого существующего стейт менеджера.
Адептам Mobx я противостоять не вижу смысла, как и сражаться с другими командами, делающими по-своему отличные решения, напротив мы все развиваем одну отрасль.
use-between же о другом, и лично я ищу тех кому будет интересно писать свой проект в стиле хуков! И сердечно предлагаю попробовать свежее решение.
Я тоже знаю mobx. И считаю его вполне интересным решением, правда его идею с "makeAutoObservable" считаю не очень удачной, да и прокси вместо реальных данных мне тоже не нравятся. А так же остаётся запретить "autorun" на проекте и научить всех проектировать нормальное ООП. Но я очень уважаю mobx, они отличные ребята и держат марку.
Совсем разные задачи. Здесь людям предоставляется удобный дизайн описания кода, при котором переиспользуется знание хуков. В случае с mobx, что бы написать хороший код придётся выучить много нового. Порог вхождения совершенно разный.
Ага. Но меня такое не останавливает) Уже с конца 16-ой версии Реакта никаких изменений. Использование внутреннего API даёт крутые возможности, его скорее сделают задокументированным чем удалят без предоставления альтернатив.
Хм. Тесты находятся на Github в репозитории с кодом.
Спасибо за добрые слова!)
Да. Есть такое дело, конечно “use-between” не защитит.
Современная бизнес ориентированная среда фронтенда продвигает идею, что не нужно решать проблем производительности до их появления. А архитекторы же напротив будут требовать закладывать как можно более надежный фундамент и контролировать код в течении всей его жизни с первых дней.
Реальный пример из жизни, я работал над большим проектом с redux, где повсеместно в компонентах использовался “useSelector”, мейнтейнер так беспокоился о производительности функций компонентов, что все вычисления вынес внутрь “useSelector”. А в итоге сработал обратый эффект, так как при изменении любого значения внутри стора даже самого незначительного запускались пересчёты всех “useSelector” из отображенных компонентов. В какой-то момент это стало заметно.
Для меня use-between это так же и уход от единого стора и возможность делить данные так, что бы пересчётов было как можно меньше. Что бы сторы были как можно проще и вообще я бы ввел ограничение на размер файла в один-два экрана для 95% случаев), что бы код было проще читать.
Грамотное использование React.memo, маленькие сторы, слежение за эффектами и как можно более “плоская” структура, так как чем больше вложений тем сложнее размотать потом код.
Хорошо что всё эти рекомендации применимы к Реакт приложению и без use-between!)
Жму руку. Приятно выйти на дружественную ноту!
Классно написал про MobX, я тоже писал свой плагин на babel, что бы автоматически оборачивать компоненты в observer) нашелся бы кто-нибудь кто в open source оформил бы такой, да что бы ещё работал на SWC, вообще б цены не было!
Хм. Удивительно грубая речь. Думаю вопрос риторический. Могу немного перефразировать, следует вкладывать смысл во всё что мы пишем, а не только в код. Не писать глупостей и лишнего)
Мне больше всех нравятся минималистичные варианты типа Jotai, на работе пишу на Mobx, но для своих проектов использую личные разработки (например Remini), в какой-то момент становиться интереснее написать то что самому себе хочется, чем мириться с проблемами любого существующего стейт менеджера.
Адептам Mobx я противостоять не вижу смысла, как и сражаться с другими командами, делающими по-своему отличные решения, напротив мы все развиваем одну отрасль.
use-between же о другом, и лично я ищу тех кому будет интересно писать свой проект в стиле хуков! И сердечно предлагаю попробовать свежее решение.
Я тоже знаю mobx. И считаю его вполне интересным решением, правда его идею с "makeAutoObservable" считаю не очень удачной, да и прокси вместо реальных данных мне тоже не нравятся. А так же остаётся запретить "autorun" на проекте и научить всех проектировать нормальное ООП. Но я очень уважаю mobx, они отличные ребята и держат марку.
Совсем разные задачи. Здесь людям предоставляется удобный дизайн описания кода, при котором переиспользуется знание хуков. В случае с mobx, что бы написать хороший код придётся выучить много нового. Порог вхождения совершенно разный.
Ага. Но меня такое не останавливает) Уже с конца 16-ой версии Реакта никаких изменений. Использование внутреннего API даёт крутые возможности, его скорее сделают задокументированным чем удалят без предоставления альтернатив.
Это не так. Каждый компонент подписывается на изменения стейта который в нём используется. Под копотом обычный state manager.