Как же вы так код писали, что у вас постоянно возникали эти зацикливания?) Что-то мне подсказывает, что проблема-то была как раз не во фреймворке, а в кое чём другом.
И да, кстати, MobX изначально спроектирован так, что циклические зависимости там невозможны - код просто не запустится и явно подскажет вам где вы накосячили. Так что советую попробовать, возможно вы приятно удивитесь.)
Такие безапелляционные заявления - это верх пренебрежения, боязнь нового и попахивает не компетентностью
Замечу, что я на личности таки не переходил, а вы почему-то сразу решили это сделать. Видимо, почувствовали свою несостоятельность.)
Боязни нового тут нет. Просто есть проверенное временем решение, лучше которого, к сожалению, пока ничего не придумали. А вот это ваше неудержимое джуниорское желание попробовать всё новое и запихать в проект все возможные хайпующие технологии до добра обычно не доводит (сам таким был, каюсь, и спустя много лет понимаю какую свинью подложил той компании, где я такое практиковал) и приходится после этого приходить на проект и выкорчёвывать целый зоопарк сомнительных решений.
У нас большое приложение больше 2х лет работы и ни одного каунтера - сплошь сложные структуры данных и сложная логика.
А что ж тогда в статье об одном лишь каунтере рассказали? Привели бы в пример кейсы, где zustand реально хорошо себя показывает, тогда вопросов бы не было. Пока же в статье показаны кейсы, где MobX показывает себя гораздо лучше.
ваша "декомпозиция" приводит к композиции сложности и не надежности приложения (об этом написано в статье) - попробуйте в базах данных кому-нибудь рассказать что вы хотите часть базы данных "декомпозировать" - вас сразу же "декомпозируют" подальше от нее.
Если честно, вы такими заявлениями дискредитируете себя ещё больше.)
Ну, если вы рекомендуете своим коллегам строить огромных колоссов на глиняных ногах, то мне вас откровенно жаль и ещё больше жаль ваших коллег, которые будут работать с этим и поддерживать эти бесконечно большие модели, пытаясь к ним прицепить новую функциональность, при этом не поломав всё остальное.
БД в качестве примера приводить не стоит, всё же это совершенно сторонняя концепция и она мало чем связана непосредственно с бизнес логикой приложений. И на самом-то деле даже БД уже спокойно себе декомпозируют и разбивают на независимые суб бд для микросервисов. Но, повторюсь, к делу это никакого отношения не имеет. Бизнес логика приложений строится совершенно по другим принципам.
И думаю стоит сказать о простых человеческих возможностях - работать с одной огромной сущностью с внутренними взаимосвязями гораздо сложнее, чем с набором малых, которые взаимодействуют между собой. Малые сущности позволяют абстрагировать как логику, так и данные и оперировать бОльшими блоками, что очень удобно для нашего мозга - не нужно погружаться в детали реализации, можно просто использовать интерфейсы. Если же у вас одно огромное хранилище, то придется держать в голове кучу взаимосвязей внутри него, знать о каждой его части и что на неё может воздействовать.
Могу предположить, что у вас просто не получалось наладить взаимодействие этих отдельных блоков и они превращались в один плотно скрученный пучок отношений (слабая связность, сильное зацепление). Для решения таких проблем существует большое количество разных паттернов, которые позволят вам достичь гораздо лучшего результата. Почитайте туже банду 4, к примеру. Ну или хотя бы пройдитесь по статье на вики. Думаю после этого вам станет более понятно, как организовать ваш код таким образом, что б не приходилось решать ваши проблемы с помощью объединения всего и вся в одну мега сущность.
вот тут просто набор слов - не понятно как на него реагировать
Да, я догадывался, что для вас это будет просто набором слов, но надеялся что всё же поймёте.
вообще мимо - это относится к коду но не к данным
Ага, а данные у нас в коде конечно же никак не представлены.
не нужно путать код сплиттинг с разбиением данных на хранилища - это вещи абсолютно разного порядка. Асинхронно загружаемых бандлов может быть сколько угодно, но какое отношение они имеют к хранилищу данных, к целостности и не противоречивости их??
А вот из-за таких домыслов производительность современного фронтенда и находится в жопе. Т.к. многие думают что достаточно кодсплитить одни вьюхи, а всю логику поставлять в одном единственном чанке на всё приложение (привет редакс). Да, конечно есть воркераунды для этого дела, но не только лишь все ими пользуются...
А если же всё же декомпозировать ваш этот огромный стор на составляющие и разместить рядом с ними связанную логику и представления, то можно с лёгкостью разделить приложение на независимые части и поставлять их пользователю по запросу (при SPA переходе, открытии модалки и т.д.). Это уменьшит вес вашего основного чанка, ускорит его парсинг и выполнение.
вот как раз поддерживаемость одного хранилища в разы выше чем кучи хранилищ с непрозрачной логикой связи, с разнонаправленными потоками обновления данных и тд и тп - еще раз повторюсь в статье этот кейс описан
Поздравляю, вы противоречите официальной доке zustand.)
Ну и выше я постарался объяснить с помощью базовых принципов человеческого мышления почему это важно.
о какой производительности вы ведете речь - пожалуйста код в студию с измерениями!
Слушайте, вам бы самому в начале стоит код привести, графики, сравнения, а не бравировать пустыми домыслами об этой самой производительности у zustand.
Производительность же раздельных сторов базируется на простом принципе - иммутабельно изменять огромное дерево в любом случае будет менее производительным, чем изменение независимых сторов и обновление только тех представлений, которые этого требуют.
Такое ощущение что вы боитесь потерять работу потому что ваш MobX задвинут и возьмут в работу что-то более простое, легкое и гибкое
MobX не задвинут ни разу, вы очень сильно ошибаетесь. Он простой, легкий и очень, нет, ОЧЕНЬ гибкий. Возможно даже излишне гибкий и из-за этого такие как вы просто боитесь его использовать, т.к. вам проще идти на поводу у решений, которые банально не дают вам возможности сделать шаг в сторону, подумать о том, а какой же паттерн тут лучше применить, подумать о том, как сделать код более масштабируемым, поддерживаемым, гибким. И решением всех ваших проблем становится один лишь pubsub. О да, самый лучший паттерн.)
И да, вы очень сильно удивитесь какие по масштабу проекты пилят именно на MobX.
Смотрю я последнее время на хабр и становится грустно от огромного количества статей на тему этих zustand, effector и прочих.
Грустно от того, что люди не понимают, что все эти стейт менеджеры представляют из себя синглтоны, склоняют к использованию синглтонов, никак не решают проблемы взаимосвязей разных сущностей и по факту совершенно не заботятся о производительности.
И в этой статье также одни розовые сопли и никакой аналитики, сравнений с нормальными решениями типа MobX, чуть более сложных примеров, чем банальный каунтер, примеров масштабирования системы, её гибкости.
И этот момент:
Создание отдельных хранилищь оправдано лишь для:
реально не зависимых структур данных
для данных в микрофронтах
Ну уж извините. Создание отдельных хранилищ оправдано огромным количеством различных причин. К примеру:
Декомпозиция бизнес логики на составляющие и её инкапсуляция
Повышение реиспользуемости разных частей приложения
Увеличение связность и уменьшение зацепления (а в общих сторах вся всегда очень зацеплено и слабо связано)
Code Splitting
Поддерживаемость
Производительность
Конеш удобненько хранить всё своё состояние в одном огромном дереве. Удобно, когда у тебя две формочки на весь проект и одна единственная корзина с товарами. А когда корзин становится две, то уже возникают сложности.
Эх, вот использовал бы народ MobX повсеместно, глядишь фронтендеров и за людей бы начали считать...
Скорее всего обосновано только тем, что разработчики на редаксе не привыкли включать голову в процессе разработки и уж тем более продумывать архитектуру и вкладываться в её становление и развитие. =)
Он понятный и простой ровно до тех пор, пока не появится чуть больше двух формочек со взаимосвязями в приложении. После этого он становится абсолютно лапшеобразным и баз фактор этого кода стремится к 0.
Для прод мониторинга производительности яб всё же посоветовал что-то типа https://www.sitespeed.io/. Он лучше подходит для этих целей и покрывает большее количество релевантных перфоманс метрик.
Ещё можно воспользоваться Chrome UX Report, но там только самые важные метрички. Зато очень дешево - они собираются с пользователей автоматически.
Ну а в статье я как раз стараюсь раскрыть тему именно перф тестов.)
Как же вы так код писали, что у вас постоянно возникали эти зацикливания?) Что-то мне подсказывает, что проблема-то была как раз не во фреймворке, а в кое чём другом.
И да, кстати, MobX изначально спроектирован так, что циклические зависимости там невозможны - код просто не запустится и явно подскажет вам где вы накосячили. Так что советую попробовать, возможно вы приятно удивитесь.)
Замечу, что я на личности таки не переходил, а вы почему-то сразу решили это сделать. Видимо, почувствовали свою несостоятельность.)
Боязни нового тут нет. Просто есть проверенное временем решение, лучше которого, к сожалению, пока ничего не придумали. А вот это ваше неудержимое джуниорское желание попробовать всё новое и запихать в проект все возможные хайпующие технологии до добра обычно не доводит (сам таким был, каюсь, и спустя много лет понимаю какую свинью подложил той компании, где я такое практиковал) и приходится после этого приходить на проект и выкорчёвывать целый зоопарк сомнительных решений.
А что ж тогда в статье об одном лишь каунтере рассказали? Привели бы в пример кейсы, где zustand реально хорошо себя показывает, тогда вопросов бы не было. Пока же в статье показаны кейсы, где MobX показывает себя гораздо лучше.
Если честно, вы такими заявлениями дискредитируете себя ещё больше.)
Ну, если вы рекомендуете своим коллегам строить огромных колоссов на глиняных ногах, то мне вас откровенно жаль и ещё больше жаль ваших коллег, которые будут работать с этим и поддерживать эти бесконечно большие модели, пытаясь к ним прицепить новую функциональность, при этом не поломав всё остальное.
БД в качестве примера приводить не стоит, всё же это совершенно сторонняя концепция и она мало чем связана непосредственно с бизнес логикой приложений. И на самом-то деле даже БД уже спокойно себе декомпозируют и разбивают на независимые суб бд для микросервисов. Но, повторюсь, к делу это никакого отношения не имеет. Бизнес логика приложений строится совершенно по другим принципам.
И думаю стоит сказать о простых человеческих возможностях - работать с одной огромной сущностью с внутренними взаимосвязями гораздо сложнее, чем с набором малых, которые взаимодействуют между собой. Малые сущности позволяют абстрагировать как логику, так и данные и оперировать бОльшими блоками, что очень удобно для нашего мозга - не нужно погружаться в детали реализации, можно просто использовать интерфейсы. Если же у вас одно огромное хранилище, то придется держать в голове кучу взаимосвязей внутри него, знать о каждой его части и что на неё может воздействовать.
Могу предположить, что у вас просто не получалось наладить взаимодействие этих отдельных блоков и они превращались в один плотно скрученный пучок отношений (слабая связность, сильное зацепление). Для решения таких проблем существует большое количество разных паттернов, которые позволят вам достичь гораздо лучшего результата. Почитайте туже банду 4, к примеру. Ну или хотя бы пройдитесь по статье на вики. Думаю после этого вам станет более понятно, как организовать ваш код таким образом, что б не приходилось решать ваши проблемы с помощью объединения всего и вся в одну мега сущность.
Да, я догадывался, что для вас это будет просто набором слов, но надеялся что всё же поймёте.
Ага, а данные у нас в коде конечно же никак не представлены.
А вот из-за таких домыслов производительность современного фронтенда и находится в жопе. Т.к. многие думают что достаточно кодсплитить одни вьюхи, а всю логику поставлять в одном единственном чанке на всё приложение (привет редакс). Да, конечно есть воркераунды для этого дела, но не только лишь все ими пользуются...
А если же всё же декомпозировать ваш этот огромный стор на составляющие и разместить рядом с ними связанную логику и представления, то можно с лёгкостью разделить приложение на независимые части и поставлять их пользователю по запросу (при SPA переходе, открытии модалки и т.д.). Это уменьшит вес вашего основного чанка, ускорит его парсинг и выполнение.
Поздравляю, вы противоречите официальной доке zustand.)
Ну и выше я постарался объяснить с помощью базовых принципов человеческого мышления почему это важно.
Слушайте, вам бы самому в начале стоит код привести, графики, сравнения, а не бравировать пустыми домыслами об этой самой производительности у zustand.
Производительность же раздельных сторов базируется на простом принципе - иммутабельно изменять огромное дерево в любом случае будет менее производительным, чем изменение независимых сторов и обновление только тех представлений, которые этого требуют.
MobX не задвинут ни разу, вы очень сильно ошибаетесь. Он простой, легкий и очень, нет, ОЧЕНЬ гибкий. Возможно даже излишне гибкий и из-за этого такие как вы просто боитесь его использовать, т.к. вам проще идти на поводу у решений, которые банально не дают вам возможности сделать шаг в сторону, подумать о том, а какой же паттерн тут лучше применить, подумать о том, как сделать код более масштабируемым, поддерживаемым, гибким. И решением всех ваших проблем становится один лишь pubsub. О да, самый лучший паттерн.)
И да, вы очень сильно удивитесь какие по масштабу проекты пилят именно на MobX.
Смотрю я последнее время на хабр и становится грустно от огромного количества статей на тему этих zustand, effector и прочих.
Грустно от того, что люди не понимают, что все эти стейт менеджеры представляют из себя синглтоны, склоняют к использованию синглтонов, никак не решают проблемы взаимосвязей разных сущностей и по факту совершенно не заботятся о производительности.
И в этой статье также одни розовые сопли и никакой аналитики, сравнений с нормальными решениями типа MobX, чуть более сложных примеров, чем банальный каунтер, примеров масштабирования системы, её гибкости.
И этот момент:
Ну уж извините. Создание отдельных хранилищ оправдано огромным количеством различных причин. К примеру:
Декомпозиция бизнес логики на составляющие и её инкапсуляция
Повышение реиспользуемости разных частей приложения
Увеличение связность и уменьшение зацепления (а в общих сторах вся всегда очень зацеплено и слабо связано)
Code Splitting
Поддерживаемость
Производительность
Конеш удобненько хранить всё своё состояние в одном огромном дереве. Удобно, когда у тебя две формочки на весь проект и одна единственная корзина с товарами. А когда корзин становится две, то уже возникают сложности.
Эх, вот использовал бы народ MobX повсеместно, глядишь фронтендеров и за людей бы начали считать...
Скорее всего обосновано только тем, что разработчики на редаксе не привыкли включать голову в процессе разработки и уж тем более продумывать архитектуру и вкладываться в её становление и развитие. =)
Он понятный и простой ровно до тех пор, пока не появится чуть больше двух формочек со взаимосвязями в приложении. После этого он становится абсолютно лапшеобразным и баз фактор этого кода стремится к 0.
А по этим цифрам особо ничего и не скажешь на самом деле.)
Для прод мониторинга производительности яб всё же посоветовал что-то типа https://www.sitespeed.io/. Он лучше подходит для этих целей и покрывает большее количество релевантных перфоманс метрик.
Ещё можно воспользоваться Chrome UX Report, но там только самые важные метрички. Зато очень дешево - они собираются с пользователей автоматически.
Ну а в статье я как раз стараюсь раскрыть тему именно перф тестов.)