Да вы исходники лодаша почитайте, посмотрите что там происходит. Сразу спойлерну, что ничего хорошего вы там не обнаружите. Любая функция использует большую часть самого лодаша для максимально банальных операций и добавляет такое количество оверхеда (проверки типов, копирования массивов, лишние обходы массивов) что становится страшно за наш родненький фронтенд.
[].includes появился в стандарте уже лет 10 назад, как и все остальные функции, которые до сих пор поставляет этот ваш лодаш.
И зачем писать свои функции, если все проблемы решаются стандартной библиотекой? Ссылка именно это и демонстрирует, что вы конечно можете запустить огромный, не оптимальный, перегруженный конвейер лодаша чтоб мапнуть объект, или же написать Object.entries(obj).map(...) где всё максимально оптимально и прозрачно.
Ну а если вы такие маленькие снипеты пишите изначально с багами, то у меня для вас плохие новости.)
Да кажется, что этот вайб-кодинг нужен чисто для успокоения. По факту, когда придет AGI или схожий помощник, который уже будет способен планировать, размышлять и думать, формат общения с ним скорее всего будет совершенно другим, т.к. текущий банально не масштабируется.
В голове вырисовывается что-то уже похожее на нормальный диалог команды разработки с продактом, где агент приходит за уточнениями и сам понимает в каких местах бизнес требования описаны плохо, какие есть варианты их обыграть и так далее. А пользователь лишь обрисовывает общую картину и проблемы, которые нужно решить. Ну и агент сам будет решать где там фабрику засунуть, где фасад.
А то, что есть сейчас, скорее просто демо тупого подобия ИИ для развлечения.
Синьор, кмк, в первую очередь должен спросить о цели этого рефакторинга и пояснить за то, что рефакторинг должен быть обоснован с точки зрения потребности в масштабирования системы.) Ну а дальше уж в коде ковыряться.
Ага, а если и выдавал, то он не вчитывался и просто говорил "давай работай интернет грёбаный", перезагружал роутер и всё чинилось.)
Ну в крайнем случае звонил в техподдержку провайдера, когда уже три раза ребутнулся, перезагрузил ОС, а хром всё равно не открывает чатжпт, которого можно было бы спросить что же с этим делать.
Да его же не спрашивали про устройство DNS и протокола TCP/IP. Можно было хотя бы базовыми словами ответить: "Система доменных имён, которая позволяет преобразовать домен в айпишник".
Это просто проверка на то, что человек хоть чуть-чуть вылезает за пределы ide и интересуется тем, как магические коробочки, называемые компьютером, таки работают.
И да, если он ни разу не загуглил ради интереса что такое DNS_PROBE_FINISHED_NXDOMAIN в хроме или не настраивал свой роутер/впн, где всегда есть опция по DNS, то какой он вообще программист?)
Как же вы так код писали, что у вас постоянно возникали эти зацикливания?) Что-то мне подсказывает, что проблема-то была как раз не во фреймворке, а в кое чём другом.
И да, кстати, 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, но там только самые важные метрички. Зато очень дешево - они собираются с пользователей автоматически.
Ну а в статье я как раз стараюсь раскрыть тему именно перф тестов.)
И вот ещё накину статейку, в которой хорошо расписано, почему лодаш - это очень плохо:
https://habr.com/ru/articles/823484/
Да вы исходники лодаша почитайте, посмотрите что там происходит. Сразу спойлерну, что ничего хорошего вы там не обнаружите. Любая функция использует большую часть самого лодаша для максимально банальных операций и добавляет такое количество оверхеда (проверки типов, копирования массивов, лишние обходы массивов) что становится страшно за наш родненький фронтенд.
[].includes появился в стандарте уже лет 10 назад, как и все остальные функции, которые до сих пор поставляет этот ваш лодаш.
И зачем писать свои функции, если все проблемы решаются стандартной библиотекой? Ссылка именно это и демонстрирует, что вы конечно можете запустить огромный, не оптимальный, перегруженный конвейер лодаша чтоб мапнуть объект, или же написать Object.entries(obj).map(...) где всё максимально оптимально и прозрачно.
Ну а если вы такие маленькие снипеты пишите изначально с багами, то у меня для вас плохие новости.)
Да кажется, что этот вайб-кодинг нужен чисто для успокоения. По факту, когда придет AGI или схожий помощник, который уже будет способен планировать, размышлять и думать, формат общения с ним скорее всего будет совершенно другим, т.к. текущий банально не масштабируется.
В голове вырисовывается что-то уже похожее на нормальный диалог команды разработки с продактом, где агент приходит за уточнениями и сам понимает в каких местах бизнес требования описаны плохо, какие есть варианты их обыграть и так далее. А пользователь лишь обрисовывает общую картину и проблемы, которые нужно решить. Ну и агент сам будет решать где там фабрику засунуть, где фасад.
А то, что есть сейчас, скорее просто демо тупого подобия ИИ для развлечения.
Lodash где угодно - моветон.)
https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore
Синьор, кмк, в первую очередь должен спросить о цели этого рефакторинга и пояснить за то, что рефакторинг должен быть обоснован с точки зрения потребности в масштабирования системы.) Ну а дальше уж в коде ковыряться.
Ага, а если и выдавал, то он не вчитывался и просто говорил "давай работай интернет грёбаный", перезагружал роутер и всё чинилось.)
Ну в крайнем случае звонил в техподдержку провайдера, когда уже три раза ребутнулся, перезагрузил ОС, а хром всё равно не открывает чатжпт, которого можно было бы спросить что же с этим делать.
Да его же не спрашивали про устройство DNS и протокола TCP/IP. Можно было хотя бы базовыми словами ответить: "Система доменных имён, которая позволяет преобразовать домен в айпишник".
Это просто проверка на то, что человек хоть чуть-чуть вылезает за пределы ide и интересуется тем, как магические коробочки, называемые компьютером, таки работают.
И да, если он ни разу не загуглил ради интереса что такое DNS_PROBE_FINISHED_NXDOMAIN в хроме или не настраивал свой роутер/впн, где всегда есть опция по DNS, то какой он вообще программист?)
Как же вы так код писали, что у вас постоянно возникали эти зацикливания?) Что-то мне подсказывает, что проблема-то была как раз не во фреймворке, а в кое чём другом.
И да, кстати, MobX изначально спроектирован так, что циклические зависимости там невозможны - код просто не запустится и явно подскажет вам где вы накосячили. Так что советую попробовать, возможно вы приятно удивитесь.)
Замечу, что я на личности таки не переходил, а вы почему-то сразу решили это сделать. Видимо, почувствовали свою несостоятельность.)
Боязни нового тут нет. Просто есть проверенное временем решение, лучше которого, к сожалению, пока ничего не придумали. А вот это ваше неудержимое джуниорское желание попробовать всё новое и запихать в проект все возможные хайпующие технологии до добра обычно не доводит (сам таким был, каюсь, и спустя много лет понимаю какую свинью подложил той компании, где я такое практиковал) и приходится после этого приходить на проект и выкорчёвывать целый зоопарк сомнительных решений.
А что ж тогда в статье об одном лишь каунтере рассказали? Привели бы в пример кейсы, где zustand реально хорошо себя показывает, тогда вопросов бы не было. Пока же в статье показаны кейсы, где MobX показывает себя гораздо лучше.
Если честно, вы такими заявлениями дискредитируете себя ещё больше.)
Ну, если вы рекомендуете своим коллегам строить огромных колоссов на глиняных ногах, то мне вас откровенно жаль и ещё больше жаль ваших коллег, которые будут работать с этим и поддерживать эти бесконечно большие модели, пытаясь к ним прицепить новую функциональность, при этом не поломав всё остальное.
БД в качестве примера приводить не стоит, всё же это совершенно сторонняя концепция и она мало чем связана непосредственно с бизнес логикой приложений. И на самом-то деле даже БД уже спокойно себе декомпозируют и разбивают на независимые суб бд для микросервисов. Но, повторюсь, к делу это никакого отношения не имеет. Бизнес логика приложений строится совершенно по другим принципам.
И думаю стоит сказать о простых человеческих возможностях - работать с одной огромной сущностью с внутренними взаимосвязями гораздо сложнее, чем с набором малых, которые взаимодействуют между собой. Малые сущности позволяют абстрагировать как логику, так и данные и оперировать бОльшими блоками, что очень удобно для нашего мозга - не нужно погружаться в детали реализации, можно просто использовать интерфейсы. Если же у вас одно огромное хранилище, то придется держать в голове кучу взаимосвязей внутри него, знать о каждой его части и что на неё может воздействовать.
Могу предположить, что у вас просто не получалось наладить взаимодействие этих отдельных блоков и они превращались в один плотно скрученный пучок отношений (слабая связность, сильное зацепление). Для решения таких проблем существует большое количество разных паттернов, которые позволят вам достичь гораздо лучшего результата. Почитайте туже банду 4, к примеру. Ну или хотя бы пройдитесь по статье на вики. Думаю после этого вам станет более понятно, как организовать ваш код таким образом, что б не приходилось решать ваши проблемы с помощью объединения всего и вся в одну мега сущность.
Да, я догадывался, что для вас это будет просто набором слов, но надеялся что всё же поймёте.
Ага, а данные у нас в коде конечно же никак не представлены.
А вот из-за таких домыслов производительность современного фронтенда и находится в жопе. Т.к. многие думают что достаточно кодсплитить одни вьюхи, а всю логику поставлять в одном единственном чанке на всё приложение (привет редакс). Да, конечно есть воркераунды для этого дела, но не только лишь все ими пользуются...
А если же всё же декомпозировать ваш этот огромный стор на составляющие и разместить рядом с ними связанную логику и представления, то можно с лёгкостью разделить приложение на независимые части и поставлять их пользователю по запросу (при SPA переходе, открытии модалки и т.д.). Это уменьшит вес вашего основного чанка, ускорит его парсинг и выполнение.
Поздравляю, вы противоречите официальной доке zustand.)
Ну и выше я постарался объяснить с помощью базовых принципов человеческого мышления почему это важно.
Слушайте, вам бы самому в начале стоит код привести, графики, сравнения, а не бравировать пустыми домыслами об этой самой производительности у zustand.
Производительность же раздельных сторов базируется на простом принципе - иммутабельно изменять огромное дерево в любом случае будет менее производительным, чем изменение независимых сторов и обновление только тех представлений, которые этого требуют.
MobX не задвинут ни разу, вы очень сильно ошибаетесь. Он простой, легкий и очень, нет, ОЧЕНЬ гибкий. Возможно даже излишне гибкий и из-за этого такие как вы просто боитесь его использовать, т.к. вам проще идти на поводу у решений, которые банально не дают вам возможности сделать шаг в сторону, подумать о том, а какой же паттерн тут лучше применить, подумать о том, как сделать код более масштабируемым, поддерживаемым, гибким. И решением всех ваших проблем становится один лишь pubsub. О да, самый лучший паттерн.)
И да, вы очень сильно удивитесь какие по масштабу проекты пилят именно на MobX.
Смотрю я последнее время на хабр и становится грустно от огромного количества статей на тему этих zustand, effector и прочих.
Грустно от того, что люди не понимают, что все эти стейт менеджеры представляют из себя синглтоны, склоняют к использованию синглтонов, никак не решают проблемы взаимосвязей разных сущностей и по факту совершенно не заботятся о производительности.
И в этой статье также одни розовые сопли и никакой аналитики, сравнений с нормальными решениями типа MobX, чуть более сложных примеров, чем банальный каунтер, примеров масштабирования системы, её гибкости.
И этот момент:
Ну уж извините. Создание отдельных хранилищ оправдано огромным количеством различных причин. К примеру:
Декомпозиция бизнес логики на составляющие и её инкапсуляция
Повышение реиспользуемости разных частей приложения
Увеличение связность и уменьшение зацепления (а в общих сторах вся всегда очень зацеплено и слабо связано)
Code Splitting
Поддерживаемость
Производительность
Конеш удобненько хранить всё своё состояние в одном огромном дереве. Удобно, когда у тебя две формочки на весь проект и одна единственная корзина с товарами. А когда корзин становится две, то уже возникают сложности.
Эх, вот использовал бы народ MobX повсеместно, глядишь фронтендеров и за людей бы начали считать...
Скорее всего обосновано только тем, что разработчики на редаксе не привыкли включать голову в процессе разработки и уж тем более продумывать архитектуру и вкладываться в её становление и развитие. =)
Он понятный и простой ровно до тех пор, пока не появится чуть больше двух формочек со взаимосвязями в приложении. После этого он становится абсолютно лапшеобразным и баз фактор этого кода стремится к 0.
А по этим цифрам особо ничего и не скажешь на самом деле.)
Для прод мониторинга производительности яб всё же посоветовал что-то типа https://www.sitespeed.io/. Он лучше подходит для этих целей и покрывает большее количество релевантных перфоманс метрик.
Ещё можно воспользоваться Chrome UX Report, но там только самые важные метрички. Зато очень дешево - они собираются с пользователей автоматически.
Ну а в статье я как раз стараюсь раскрыть тему именно перф тестов.)