Разница в производительности между пакетом и тем же кодом в главном каталоге метеоритных проектов

Я завершил приложение Discover Meteor, и у меня есть вопрос, связанный с загрузкой пакета позади сцены. Чтобы быть более точным, учебник позволяет пользователю сначала создавать функции обработки ошибок внутри основного проекта метеора, а затем делает код модульным, создавая пакет ошибок.

Помимо очевидного преимущества наличия пакета, существует ли конкретный вопрос, почему нужно создавать пакет вместо простого использования в проекте? Любая разница в производительности, любое преимущество на пути загрузки пакетов? Какой недостаток я должен знать?

Я могу решить вопрос, имеет ли пакет лучшие результаты по сравнению с тем же кодом в основной папке проекта?

1 ответ

Создание пакета по своей сути не дает вам преимуществ в производительности - код минимизируется и вставляется в тот же комплект вместе с остальной частью вашего приложения. Основные преимущества:

  • Как вы указали, он делает код многоразовым. Даже если это только локальный пакет, вы все равно можете использовать его между своими собственными проектами. В качестве альтернативы, если вы можете поделиться с другими, вы можете опубликовать его в атмосфере и позволить остальной общине воспользоваться.

  • Вы получаете намного больший контроль над порядком загрузки зависимостей и файлов в вашем приложении. Некоторые члены сообщества восприняли эту идею до крайности, построив все свое приложение, используя пакеты, как показано здесь и здесь.

  • Вы можете использовать tinytest.

Я не могу придумать никаких очевидных недостатков, кроме когнитивных накладных расходов на запись и сохранение файла package.js (в нем перечислены зависимости, порядок загрузки файлов и т.д.). Также обратите внимание, что работа над системой пакетов находится в дорожной карте на 1.0, поэтому имейте в виду, что некоторые аспекты будут меняться в ближайшие месяцы.

На работе нам нравится включать независимые инструменты (например, генераторы текстов и библиотеки, взаимодействующие с нашим почтовым провайдером), в пакеты, даже если они не используются повторно для приложений, потому что:

  • Это делает нашу кодовую базу приложений меньшей.

  • Это держит истории git отдельно.

  • Это помогает обеспечить четкое разделение проблем.

Это, вероятно, не исчерпывающий список, но он должен дать вам несколько идей о мотивах создания и использования пакетов.

licensed under cc by-sa 3.0 with attribution.