Mantra - это архитектура приложения, которую мы разрабатываем для Meteor. По сути, это позволит вам создавать удобные в обслуживании приложения Meteor, соответствующие требованиям завтрашнего дня.
Почему?
Я начал работать с Meteor (в основном в сообществе) с самых первых дней его существования. С того дня я создал приложения Meteor с нашей командой в Kadira, и я создал массу пакетов Meteor.
В моем путешествии на Метеоре я видел общую закономерность.
В Meteor нет прикладной архитектуры.
Мы просто создаем приложения. Иногда приложения в значительной степени основаны на нескольких пакетах, а не следуют базовому набору принципов, которые прослужат долгое время.
Теперь хуже. У нас есть Blaze / Blaze2, React и Angular. Даже внутри React у нас есть много способов создать приложение. Тогда мы не уверены, как совместить их с Meteor.
Вот почему Meteor нужна архитектура приложения, основанная на наборе основных принципов.
Обратите внимание, что это архитектура приложения, а не архитектура приложения. Это потому, что есть несколько способов делать что-то правильно.
Познакомьтесь с мантрой
В Kadira мы всегда стараемся создавать поддерживаемые приложения с помощью Meteor. Мы очень старались, но не получилось так, как мы хотели. Некоторые части наших приложений устарели, а тесты непредсказуемы и занимают много времени.
Мы не хотим никого винить. Это всегда наша ответственность. Никто не заставлял нас что-либо использовать.
Вот почему мы пишем Мантру. Это архитектура приложения для Meteor (но не вилка). У Mantra есть только две основные цели.
1. Высокая ремонтопригодность
Каждая строка кода, которую вы пишете, - это ответственность. С помощью Mantra каждый написанный вами фрагмент кода может быть модульно протестирован, даже пользовательский интерфейс.
В нем также есть стандарты для всего, что позволяет легко привлекать новых разработчиков и работать с крупными проектами.
2. Гарантия будущего
Мы каждый день видим новые технологии и библиотеки. Очень сложно выбрать одно перед другим. То, что мы используем сегодня, может быть не тем, что мы будем использовать через шесть месяцев.
Итак, нам нужно согласовать основной набор инструментов и концепций, на которые мы полагаемся, и позволить другим вещам меняться по мере необходимости.
Для достижения вышеуказанных целей нам, возможно, придется немного пойти на компромисс. В частности, придется немного поучиться. Не волнуйтесь, мы неплохо объясняем сложные вещи :)
Обычно приложения развиваются
Обычно мы не начинаем создавать полностью функционирующее приложение в первый же день. Во-первых, мы строим MVP. Потом проверим, что будем делать дальше. Потом пробуем что-нибудь новенькое. Это эксперимент. Если это сработает, мы сохраним его. Если нет, попробуем что-нибудь другое.
Lifetime нашего приложения - это набор экспериментов, которые у нас сработали.
С Mantra мы делаем то же самое для поддержки нашего приложения:
- Сначала мы создаем приложение, не слишком заботясь о производительности.
- После этого мы следим за ним и решаем, какие части нужно изменить (а не только сервер). Обычно это связано с государственными менеджерами.
- Затем мы пытаемся его оптимизировать.
- Если нам это удается, мы сохраняем его, если нет, мы возвращаем его обратно.
- Теперь вернемся к шагу 2.
Mantra позволяет вам делать это, не нарушая работу нашего приложения и не заставляя нас делать повторную запись.
Технологический стек, лежащий в основе Mantra
Мы просто посмотрели на цели, стоящие за Mantra, и на то, почему мы их создаем. Теперь пришло время взглянуть на стек технологий, лежащих в основе Mantra.
ES2015 и вкус функционального программирования
Мы используем ES2015 как основную часть Mantra. Хотя Mantra не является чисто функциональным подходом к программированию, мы извлекаем из него много полезного, что позволяет нам проводить модульное тестирование всего.
Мы используем Meteor 1.3 в качестве основы, потому что мы сильно полагаемся на модульную систему ES2015.
Реагировать как слой пользовательского интерфейса
Mantra использует React, потому что мы считаем, что именно так движется будущее. Это не только из-за тенденции, но и потому, что мы увидим много хороших вещей с React.
Но мы не используем состояния в React. Это жесткое правило. Все, что вам нужно использовать внутри компонента React, должно поступать через props, если это не другой компонент.
Несколько государственных менеджеров
В наших приложениях мы обычно работаем с двумя типами состояний:
- Местный штат - штат, который остается только локально. Им никогда не нужно синхронизироваться с сервером.
- Удаленное состояние - данные обычно хранятся на удаленном сервере. Обычно мы получаем и изменяем их в клиенте. Мы также подписываемся на изменения удаленного состояния.
В Mantra мы позволяем различным инструментам управлять этими двумя состояниями.
Это та часть, где Mantra гибкая, она позволяет вам проводить эксперименты и выяснять, что лучше для вас.
Например, когда вы начинаете создавать приложение, вы можете начать с этих менеджеров состояний:
- Mongo / MiniMongo для удаленного управления состоянием.
- Трекер / ReactiveDict для местного государственного управления.
- FlowRouter для управления состоянием URL (можно считать, что это тоже часть локального состояния).
По мере роста вашего приложения вам может потребоваться использовать некоторые другие менеджеры состояний, например:
- GraphQL для удаленного управления состоянием.
- Redux для управления состоянием локальных данных.
Действия
Действия являются сердцем приложения (на стороне клиента) и обрабатывают бизнес-логику. Каждое действие - это функция, которую можно тестировать отдельно. Действие может взаимодействовать с менеджерами состояний, но не может напрямую взаимодействовать с пользовательским интерфейсом.
Контейнеры React
Контейнеры React просто привязывают действия и состояния к компонентам пользовательского интерфейса. При необходимости они могут даже вызывать действия. Контейнеры React должны быть составлены, и вы также не можете использовать состояния внутри контейнеров.
Вы также можете провести модульное тестирование того, как мы составляем контейнеры React.
Клиентский фокус
В большинстве случаев Mantra помогает вам спроектировать клиентскую часть вашего приложения. Он полагается на менеджеров состояний для взаимодействия с сервером.
Однако Mantra будет иметь соглашения об именах и несколько правил для серверной стороны.
Внедрение зависимостей (DI)
Контейнеры и действия React должны работать с разными менеджерами состояний и использовать некоторые элементы конфигурации. Вместо использования модулей JavaScript или глобального пространства имен мы используем методы внедрения зависимостей для доступа к ним.
Таким образом, мы можем без особых усилий написать код, пригодный для модульного тестирования, и он будет чистым.
Это всего лишь обзор мантры. Мы опубликуем первоначальный проект в понедельник. В комплекте:
- Спецификация
- Стартовый комплект
- Пример приложения
План развития
Для Mantra мы не собираемся создавать совершенно новый набор новых инструментов. Собственно, нам и не нужно. Вместо этого мы воспользуемся несколькими клеевыми проектами, такими как react-komposer.
Как только мы выпустим первоначальный черновик в понедельник, мы начнем переписывать некоторые приложения в Kadira на основе Mantra. (Специально наше приложение для онлайн-обучения, используемое для BulletProof Meteor.)
Нам действительно нужна ваша поддержка, чтобы настроить Mantra и создать удобные в обслуживании приложения Meteor. Так что поиграйте с этим, взломайте и отправьте PR.
Следите за новостями о первом выпуске Mantra!
РЕДАКТИРОВАТЬ: Мантра здесь.
Следуйте КАДИРА ГОЛОС, чтобы узнать больше о Мантре.
