Кажется, вы не понимаете мою мысль. Я люблю MobX и считаю его замечательным инструментом. А свой подход я лишь показал для тех людей, которые его считают не самым удобным. Таких людей много. Погуглите статьи, сравнивающие MobX и Redux, и вы удивитесь, тому как часто всплывает тезис "В MobX слишком много свободы".
Вы считаете, что MobX идеален и это ваша правда. Они считает, что в нем есть недостатки. И это их правда. Мир не делится на черное и белое. И опять же повторюсь, моя статья направлена как раз на таких людей.
Я могу понять ваши слова. Однако, если вы читали мою предыдущую статью, о чем я просил в начале, то вы бы знали, что этот недостаток описывается в невероятно большим количеством статей других авторов.
Самому мне нравится свобода MobX, потому я, как мне кажется, оставил достаточное место для маневра в описываемом подходе. Однако, для тех людей, кто считает, что свободы слишком много, я описал несколько простых правил
Мы снова возвращаемся к проблеме гибкости и расширяемости. Без всех вводных хорошего решения не придумать. А продумывать заранее все возможные ситуации - сильно усложнять себе жизнь и замедлять процесс разработки.
Пример довольно специфичный. Не знаю, какое было бизнес-требование, но логировать обработку любой функции во вьюмодели - это жестко, конечно.
А ещё непонятно, почему в вашем примере модель имеет какую-то логику. Если вы хотите использовать "Модель", то она должна только хранить данные.
Ролевая модель и аутентификация у меня были, и я делал их отдельными DI синглотн контейнерами. Они не были сущностями из паттерна MVVM. В вашем же примере, я бы создал вообще отдельную сущность, как некий middleware, который бы использовал в `configure({ vmFactory })`
Я думаю, каждый останется при своем мнении. Я считаю, что такие абстракции могут быть далеко не всегда обоснованы. Ваш код может и будет более гибким, но так ли часто нужна эта гибкость? На моей практике гибкость нужна была исключительно редко, и там только где она действительно нужна, я прибегал к подобному делению. В остальных же случаях "яйца в одной корзине" мне только помогали. Потому что проще носить одну корзину с 10 яйцами, чем десять корзин с 1 яйцом
Все верно, добавь функцию render во вьюмодель и она почти станет копией классового компонента. Однако, я считаю, что такое деление все же полезно. Как минимум есть разница в том, что с помощью вьюмодели можно обращаться к родителю и его родителю и т.п.
Однако, основная проблема - подход. На моей практике в классовых компонентах в них часто намешаны функции по обработке логики и по рендеру. Часто в классовых компонентах присутствует не только функция render, содержащая JSX код, но и пара дополнительных, которые вызываются внутри render. И это уже сильно усложняет анализ компонента.
А в подходе MVVM берется все лучшее из двух миров. Компоненты являются функциями, а логика хранится в классе.
Понятие чистой архитектуры - это всегда условная вещь. Невозможно придумать архитектуру, которая бы всегда подходила ко всем приложениям. К тому же архитектура - это всегда усложнение концептов и абстракций. Безусловно, это усложнение помогает в разработке, т.к. формирует строгий подход к ней. Но нужно искать грань, когда очередное усложнение абстракций приносит больше пользы, чем вреда. Слишком строгий подход будет замедлять вхождение в проект новых разработчиков и способен даже негативно сказываться на скорости процесса разработки.
Наверное, я соглашусь, то, что я показал в статье - это не совсем реализация MVVM. И не только из-за того, что там нет модели. Однако, это подход концептуально близок к этому паттерну, поэтому я так его и назвал.
В указанном мной подходе необходимости в абстракции модели зачастую нет. Да и в целом, модель из MV-паттернов является абстракцией скорее необходимой для бэкенд разработки. Вы можете, конечно, вместо вьюмодели хранить observable поля в специальном объекте, который бы удалялся при размонтировании вью. Но реально все что изменится в таком подходе - это то, как вы будете получать данные. Не viewModel.field, а viewModel.model.field.
Хотя, я согласен, что смысл в модели может быть. Например, в моем прошлом проекте моделью я считал описание формы. Тогда в модели я с помощью декораторов создавал валидацию, отслеживал, была ли изменена модель, и проводил другие операции свойственные формам. Однако, такая модель была специфичная для того проекта. Смысла переносить такую абстракцию для всех нет.
Теперь об остальных замечаниях.
Я специально разделил понятие DI и MVVM. В моем представлении те данные, которые нужны только одному компоненту логично хранить именно во вьюмодели, а то, что нужно в разрозненных частях, - в DI контейнере. Уже такое деление помогает разработчику, взглянув на данные, понять как и где они используются. Поэтому не делать MVVM стором я бы не стал.
Учитывая, что я описал свою точку зрения по необходимости модели, ответ на то, нужно ли удалять вьюмодель при размонтировании вью становится очевиден, ведь MVVM хранит его данные. Но даже, если бы она не хранила данные, а содержала бы только логику, я бы все равно советовал её удалять. Во-первых, если ваши вьюмодели являются синглтонами, то вы не сможете использовать несколько вью с одинаковыми вьюмоделями. Во-вторых, вьюмодели должны содержать логику - как минимум функции по обработке состояния. И если не уничтожать вьюмодели, то память приложения будет постепенно засоряться теми данными, которыми пользователь, может и не воспользоваться больше.
Вашу мысль про mobx-react-lite я не особо понял, если честно. Вы бы не могли её расписать?
Зачем вью и вьюмодель знают о существовании друг друга? Ответ на этот вопрос таится в самой статье. Вьюмодель способна обрабатывать логику на разных жизненных этапах вью. Таким образом можно полноценно разделять логику и отображение, и даже от хуков во вью отказаться. К тому же, вьюмодель знает о пропах вью. Таким образом она может навешивать реакции на их изменение, а дети вью могут без проп дриллинга получать нужный проп. Что влияет как на производительность, так и на простоту анализа кода.
Ввиду того, что я не знаком с данной технологией, я не могу апеллировать техническими аргументами. Однако, ваша мысль про "менеджеров или программистов" кажется мне странной. Как программист я хочу быстро решать задачи и получать ответы на свои вопросы. И развитое сообщество мне в этом не помогает.
Погоня за быстродействием - это всегда риск, тем более если мы говорим о новых технологиях. А риски должны быть оправданы. И программист должен уметь их оценивать.
Кстати, если же вы против популярного, и за все быстрое, по такой логике можно начать писать какой-нибудь свой WASM движок на C вместо JS. Или даже свой браузер, где JS не будет и в помине.
К тому же популярность часто коррелирует с гарантией. Если большое количество людей уже проверило код, значит с большей вероятностью в нем будет меньше ошибок.
Интересная технология. Впервые если честно о ней слышу, поэтому даже не задумывался об этой библиотеке. Но я могу порассуждать, есть ли смысл в текущей реализации MVVM, если есть MobX.
MobX скачивают в 1000 раз чаще, чем данную библиотеку. И MobX образовало вокруг себя довольно большое сообщество. Поэтому заинтересованных в небольшой доработке уже существующего популярного решения будет в разы больше, чем в доработке для малоизвестной новой библиотеки. А я своей статьей хотел именно заинтересовать других разработчиков
Замечательно, что такая библиотека существует. Однако, её разработчики преследуют несколько иные цели, нежели я. MVVM предназначен именно для разделения логики и отображения. И напрямую от DI никак не зависит. Я просто предоставил возможность подключения DI. Причем не какой-то определенной DI библиотеки, а любой
Если представить, что каждая корутина - это задача, выделенная под запрос пользователя, то логично ожидать, что и каналов будет много. Так что условие с N каналов мне показалось более реалистичным.
А по поводу закуска везде... Ну, можно, конечно. Но кода на Python в репозитории и так уже больше всего)
Хотя, если дополнить репозиторий парой тестов и расширить проверку на большем количестве рутин, можно будет говорить, что бенчмарк можно использовать раз в полгода-год и смотреть динамику. Тогда и на разные ОС можно будет расширить код.
Знаете, ваши опасения были не напрасны. Результаты изменились не катастрофически но значимо. Rust начал выглядеть не настолько крутым языком, а скорее как примерно такой же.
По всей видимости мое описание тестов вводит людей в заблуждение. Имелось в виду, что канал использовался для передачи информации от одной горутины к другой, а в Rust асинхронные функции просто возвращали значение. В конечном итоге значения и в Rust и в Go записывались в вектор и массив. Я дополню свою статью
Все верно. Первый тест является эмулирующим. И задержка как раз эмулирует ожидание при вводе-выводе. Как и тесты с SQL. Можно представить, что у нас есть веб сервер, где миллион пользователей одновременно пытаются что-то сделать. Так что по мне так tokio здесь очень даже к месту. Если не согласны, распишите, пожалуйста, подробнее почему
Я тоже об этом думал. Однако, мне показалось, что на миллионе каналов программе может стать дурно. К тому же представить реальную задачу, где требовалось бы миллион каналов, мне тяжело. Поэтому я просто выбрал способ, где данные в принципе сохранялись бы, любым доступным способом
Кажется, вы не понимаете мою мысль. Я люблю MobX и считаю его замечательным инструментом. А свой подход я лишь показал для тех людей, которые его считают не самым удобным. Таких людей много. Погуглите статьи, сравнивающие MobX и Redux, и вы удивитесь, тому как часто всплывает тезис "В MobX слишком много свободы".
Вы считаете, что MobX идеален и это ваша правда. Они считает, что в нем есть недостатки. И это их правда. Мир не делится на черное и белое. И опять же повторюсь, моя статья направлена как раз на таких людей.
Я могу понять ваши слова. Однако, если вы читали мою предыдущую статью, о чем я просил в начале, то вы бы знали, что этот недостаток описывается в невероятно большим количеством статей других авторов.
Самому мне нравится свобода MobX, потому я, как мне кажется, оставил достаточное место для маневра в описываемом подходе. Однако, для тех людей, кто считает, что свободы слишком много, я описал несколько простых правил
Мы снова возвращаемся к проблеме гибкости и расширяемости. Без всех вводных хорошего решения не придумать. А продумывать заранее все возможные ситуации - сильно усложнять себе жизнь и замедлять процесс разработки.
Пример довольно специфичный. Не знаю, какое было бизнес-требование, но логировать обработку любой функции во вьюмодели - это жестко, конечно.
А ещё непонятно, почему в вашем примере модель имеет какую-то логику. Если вы хотите использовать "Модель", то она должна только хранить данные.
Ролевая модель и аутентификация у меня были, и я делал их отдельными DI синглотн контейнерами. Они не были сущностями из паттерна MVVM. В вашем же примере, я бы создал вообще отдельную сущность, как некий middleware, который бы использовал в `configure({ vmFactory })`
Я думаю, каждый останется при своем мнении. Я считаю, что такие абстракции могут быть далеко не всегда обоснованы. Ваш код может и будет более гибким, но так ли часто нужна эта гибкость? На моей практике гибкость нужна была исключительно редко, и там только где она действительно нужна, я прибегал к подобному делению. В остальных же случаях "яйца в одной корзине" мне только помогали. Потому что проще носить одну корзину с 10 яйцами, чем десять корзин с 1 яйцом
Все верно, добавь функцию
renderво вьюмодель и она почти станет копией классового компонента. Однако, я считаю, что такое деление все же полезно. Как минимум есть разница в том, что с помощью вьюмодели можно обращаться к родителю и его родителю и т.п.Однако, основная проблема - подход. На моей практике в классовых компонентах в них часто намешаны функции по обработке логики и по рендеру. Часто в классовых компонентах присутствует не только функция render, содержащая JSX код, но и пара дополнительных, которые вызываются внутри render. И это уже сильно усложняет анализ компонента.
А в подходе MVVM берется все лучшее из двух миров. Компоненты являются функциями, а логика хранится в классе.
Понятие чистой архитектуры - это всегда условная вещь. Невозможно придумать архитектуру, которая бы всегда подходила ко всем приложениям. К тому же архитектура - это всегда усложнение концептов и абстракций. Безусловно, это усложнение помогает в разработке, т.к. формирует строгий подход к ней. Но нужно искать грань, когда очередное усложнение абстракций приносит больше пользы, чем вреда. Слишком строгий подход будет замедлять вхождение в проект новых разработчиков и способен даже негативно сказываться на скорости процесса разработки.
Наверное, я соглашусь, то, что я показал в статье - это не совсем реализация MVVM. И не только из-за того, что там нет модели. Однако, это подход концептуально близок к этому паттерну, поэтому я так его и назвал.
В указанном мной подходе необходимости в абстракции модели зачастую нет. Да и в целом, модель из MV-паттернов является абстракцией скорее необходимой для бэкенд разработки. Вы можете, конечно, вместо вьюмодели хранить observable поля в специальном объекте, который бы удалялся при размонтировании вью. Но реально все что изменится в таком подходе - это то, как вы будете получать данные. Не
viewModel.field, аviewModel.model.field.Хотя, я согласен, что смысл в модели может быть. Например, в моем прошлом проекте моделью я считал описание формы. Тогда в модели я с помощью декораторов создавал валидацию, отслеживал, была ли изменена модель, и проводил другие операции свойственные формам. Однако, такая модель была специфичная для того проекта. Смысла переносить такую абстракцию для всех нет.
Теперь об остальных замечаниях.
Я специально разделил понятие DI и MVVM. В моем представлении те данные, которые нужны только одному компоненту логично хранить именно во вьюмодели, а то, что нужно в разрозненных частях, - в DI контейнере. Уже такое деление помогает разработчику, взглянув на данные, понять как и где они используются. Поэтому не делать MVVM стором я бы не стал.
Учитывая, что я описал свою точку зрения по необходимости модели, ответ на то, нужно ли удалять вьюмодель при размонтировании вью становится очевиден, ведь MVVM хранит его данные. Но даже, если бы она не хранила данные, а содержала бы только логику, я бы все равно советовал её удалять. Во-первых, если ваши вьюмодели являются синглтонами, то вы не сможете использовать несколько вью с одинаковыми вьюмоделями. Во-вторых, вьюмодели должны содержать логику - как минимум функции по обработке состояния. И если не уничтожать вьюмодели, то память приложения будет постепенно засоряться теми данными, которыми пользователь, может и не воспользоваться больше.
Вашу мысль про mobx-react-lite я не особо понял, если честно. Вы бы не могли её расписать?
Зачем вью и вьюмодель знают о существовании друг друга? Ответ на этот вопрос таится в самой статье. Вьюмодель способна обрабатывать логику на разных жизненных этапах вью. Таким образом можно полноценно разделять логику и отображение, и даже от хуков во вью отказаться. К тому же, вьюмодель знает о пропах вью. Таким образом она может навешивать реакции на их изменение, а дети вью могут без проп дриллинга получать нужный проп. Что влияет как на производительность, так и на простоту анализа кода.
*мне в этом помогает
Ввиду того, что я не знаком с данной технологией, я не могу апеллировать техническими аргументами. Однако, ваша мысль про "менеджеров или программистов" кажется мне странной. Как программист я хочу быстро решать задачи и получать ответы на свои вопросы. И развитое сообщество мне в этом не помогает.
Погоня за быстродействием - это всегда риск, тем более если мы говорим о новых технологиях. А риски должны быть оправданы. И программист должен уметь их оценивать.
Кстати, если же вы против популярного, и за все быстрое, по такой логике можно начать писать какой-нибудь свой WASM движок на C вместо JS. Или даже свой браузер, где JS не будет и в помине.
К тому же популярность часто коррелирует с гарантией. Если большое количество людей уже проверило код, значит с большей вероятностью в нем будет меньше ошибок.
Интересная технология. Впервые если честно о ней слышу, поэтому даже не задумывался об этой библиотеке. Но я могу порассуждать, есть ли смысл в текущей реализации MVVM, если есть MobX.
MobX скачивают в 1000 раз чаще, чем данную библиотеку. И MobX образовало вокруг себя довольно большое сообщество. Поэтому заинтересованных в небольшой доработке уже существующего популярного решения будет в разы больше, чем в доработке для малоизвестной новой библиотеки. А я своей статьей хотел именно заинтересовать других разработчиков
В этом и смысл. MobX также позволяет "держать в узде сложную логику", предоставляя при этом более простой инструментарий
Замечательно, что такая библиотека существует. Однако, её разработчики преследуют несколько иные цели, нежели я. MVVM предназначен именно для разделения логики и отображения. И напрямую от DI никак не зависит. Я просто предоставил возможность подключения DI. Причем не какой-то определенной DI библиотеки, а любой
Если представить, что каждая корутина - это задача, выделенная под запрос пользователя, то логично ожидать, что и каналов будет много. Так что условие с N каналов мне показалось более реалистичным.
А по поводу закуска везде... Ну, можно, конечно. Но кода на Python в репозитории и так уже больше всего)
Хотя, если дополнить репозиторий парой тестов и расширить проверку на большем количестве рутин, можно будет говорить, что бенчмарк можно использовать раз в полгода-год и смотреть динамику. Тогда и на разные ОС можно будет расширить код.
Я обновил статью. Теперь канал в тестах используется буферизованный
Знаете, ваши опасения были не напрасны. Результаты изменились не катастрофически но значимо. Rust начал выглядеть не настолько крутым языком, а скорее как примерно такой же.
По всей видимости мое описание тестов вводит людей в заблуждение. Имелось в виду, что канал использовался для передачи информации от одной горутины к другой, а в Rust асинхронные функции просто возвращали значение. В конечном итоге значения и в Rust и в Go записывались в вектор и массив. Я дополню свою статью
Все верно. Первый тест является эмулирующим. И задержка как раз эмулирует ожидание при вводе-выводе. Как и тесты с SQL. Можно представить, что у нас есть веб сервер, где миллион пользователей одновременно пытаются что-то сделать. Так что по мне так tokio здесь очень даже к месту. Если не согласны, распишите, пожалуйста, подробнее почему
Да, спасибо. Обязательно попробую
Я тоже об этом думал. Однако, мне показалось, что на миллионе каналов программе может стать дурно. К тому же представить реальную задачу, где требовалось бы миллион каналов, мне тяжело. Поэтому я просто выбрал способ, где данные в принципе сохранялись бы, любым доступным способом
Интересное замечание. Я попробую запустить тест с этой правкой