Я просто не понимаю, зачем 1 модуль раскидывать на 100 частей?
Обновил я зависимости и тут бот не работает.
Где именно не работает? Какую ошибку выдает?
Где именно не работает? Какую ошибку выдает?
Теперь чтобы работала нужно ещё и HearManager
Автор данного модуля так и будет делить модуль, пока каждая переменная не окажется в отдельном файле?
Так, вы же можете создать свою команду без модуля.
Так, вы же можете создать свою реализацию HearManager без модуля.
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Так, вы же можете создать свою реализацию HearManager без модуля.
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Возможно для удобства и чтоб быстро работало 👍 . Хотя все же есть минусы у модели.
Так, вы же можете создать свою реализацию HearManager без модуля.
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Возможно для удобства и чтоб быстро работало 👍 . Хотя все же есть минусы у модели.
Быстрее от этого не станет, как мне кажется
Так, вы же можете создать свою реализацию HearManager без модуля.
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Возможно для удобства и чтоб быстро работало 👍 . Хотя все же есть минусы у модели.
Быстрее от этого не станет, как мне кажется
Но все же, лучше использовать свою реализацию )) Там меньше проблем
Так, вы же можете создать свою реализацию HearManager без модуля.
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Возможно для удобства и чтоб быстро работало 👍 . Хотя все же есть минусы у модели.
Быстрее от этого не станет, как мне кажется
естественно станет, модуль не будет подгружать те вещи, которые начальному юзеру будут ненужны и не будет обрабатывать мидлвари, которые в итоге будут проигнорированы = буст в скорости, думайте о чем пишете
Так, вы же можете создать свою реализацию HearManager без модуля.
>
>
Это да, но узнать "Зачем и Почему?" разбили все на модули хочется!)
Возможно для удобства и чтоб быстро работало 👍 . Хотя все же есть минусы у модели.
Быстрее от этого не станет, как мне кажется
естественно станет, модуль не будет подгружать те вещи, которые начальному юзеру будут ненужны и не будет обрабатывать мидлвари, которые в итоге будут проигнорированы = буст в скорости, думайте о чем пишете
Да, но основной хендлер - сообщения, зачем его то выпиливать?
Да, но основной хендлер - сообщения, зачем его то выпиливать?
Давай я постараюсь объяснить всё на понятном тебе языке - языке мемов.
В защиту @Zharckov могу сказать что нарушение обратной совместимости - не есть хорошо.
Разъединение модулей повысило порог вхождения, да и сложность кода лишь увеличилась со временем.
В защиту @Zharckov могу сказать что нарушение обратной совместимости - не есть хорошо.
Поэтому это Breaking Change.
Основная библиотека это vk-io
, которая предоставляет базовое взаимодействие с ВКонтакте, она тянет за собой минимальное количество зависимостей. Модуль @vk-io/hear
это такой же middleware как @vk-io/session
и @vk-io/scenes
. Так как это только альтернативная реализация возможного взаимодействия с сообщениями. Когда модуль находился в Updates
это не позволяло переиспользовать его и добавляла лишнюю сложность и бесконтрольность, к тому же это нарушало принцип SOLID.
В самом деле я бы всё разделил на отдельные модули @vk-io/api
, @vk-io/upload
, @vk-io/updates
, @vk-io/collect
и @vk-io/structures
а в vk-io
всё бы это экспортировалось по умолчанию, ввиду того что каждый модуль лишь реализация своей ответственности. Но прямо сейчас внутри vk-io
каждый модуль уже готов пересадки в своё пространство имён.
У этого подхода есть большее преимущество, вы устанавливаете только то — что вам нужно. А так же вы не путаетесь в огромном количестве экспорта из всего модуля. За примером далеко ходить не нужно, стоит посмотреть инструменты по типу: apollo-server, apollo-tooling и apollo-client.
Самый полезный комментарий
Основная библиотека это
vk-io
, которая предоставляет базовое взаимодействие с ВКонтакте, она тянет за собой минимальное количество зависимостей. Модуль@vk-io/hear
это такой же middleware как@vk-io/session
и@vk-io/scenes
. Так как это только альтернативная реализация возможного взаимодействия с сообщениями. Когда модуль находился вUpdates
это не позволяло переиспользовать его и добавляла лишнюю сложность и бесконтрольность, к тому же это нарушало принцип SOLID.В самом деле я бы всё разделил на отдельные модули
@vk-io/api
,@vk-io/upload
,@vk-io/updates
,@vk-io/collect
и@vk-io/structures
а вvk-io
всё бы это экспортировалось по умолчанию, ввиду того что каждый модуль лишь реализация своей ответственности. Но прямо сейчас внутриvk-io
каждый модуль уже готов пересадки в своё пространство имён.У этого подхода есть большее преимущество, вы устанавливаете только то — что вам нужно. А так же вы не путаетесь в огромном количестве экспорта из всего модуля. За примером далеко ходить не нужно, стоит посмотреть инструменты по типу: apollo-server, apollo-tooling и apollo-client.