Недавно наша команда выложила в открытый доступ набор интерфейсной архитектуры SPA, который накапливался в течение 2 лет, в основном для решения проблемы динамической маршрутизации. Наша идея исходит из серверной части, и мы используем шаблон проектирования промежуточного программного обеспечения для построения всей структуры. Наш принцип заключается в том, чтобы позволить каждому быстро разработать одностраничное приложение SPA, заботясь только о бизнес-логике, а другие варианты поведения можно обработать с помощью.
На самом деле, наш открытый исходный код торопится, и он все еще немного нестандартен во многих аспектах, но после этого мы будем строго следовать стандартным спецификациям и процедурам, чтобы дать вам стабильную структуру. Я очень благодарен друзьям, которые сейчас следят за нашей командой. При всеобщей поддержке мы станем лучше.
Что именно пытается решить Miox?
Исходя из первоначального замысла нашего проекта, эта задача состоит в том, чтобы решить все проблемы маршрутизации. Фактически, в отрасли все признают режим маршрутизации «один к одному», что создает множество систем маршрутизации, таких какvue-router
а такжеreact-router
.他们都是非常不错的架构,从某种意义上来说,引领了前端路由的前进。很多小伙伴都是直接使用他们的全家桶来开发项目,也得到了很好的效果。
Я не уверен, что все считают проблемой, когда пользователь входит в систему с целевой страницы A, входит на страницу B, а затем возвращается на страницу A. Статическая маршрутизация один к одному на самом деле наконец отображает страницу A как незарегистрированную, что совершенно правильно, но по логике это должна быть страница входа. Статический маршрут не может различать переменные среды при выборе страницы, может только передаватьhookи другие средства для замены содержимого страницы. Теоретически, мы используем метод написания бэк-энда, должна быть следующая логика:
route.get('/a', ctx => {
if (global.logined) {
ctx.render(webveiwA);
} else {
ctx.render(webviewB);
}
})
Нам нужно автоматически выбирать, какую страницу отображать, в соответствии с переменными окружения, и эта логика — то, что нам нужно. Поэтому мы будем разрабатывать динамическую маршрутизацию в соответствии с этой идеей. существуетnodejs
В мире этот шаблон уже очень распространен, например,express-router
а такжеkoa-router
, все используют эту дизайнерскую идею для реализации системы маршрутизации динамических слов. Я наблюдал за развитием фронтенда и не предлагал реализовать такую логику во фронтенде. Поэтому мы начали изучать, как использовать эту идею во фронтенде для получения более идеального логического опыта.
Miox никогда не полагается на какой-либо фреймворк MVX для реализации
Почему ты это сказал? Причина очень проста. В компании около 90% нашего бизнеса H5 реализуется Miox. Наш технологический стек на самом деле Vue, потому что Miox слишком глубоко интегрирован с Vue, поэтому, естественно, некоторые мелкие партнеры думают, что Miox разработан на основе Vue, а значит, Miox зависит от Vue? На самом деле нет, Miox не полагается на какую-либо реализацию фреймворка. Позвольте мне привести пример:
Наш компьютер, если вы меняете видеокарту, вы должны установить драйвер видеокарты. В зависимости от драйвера видеокарты производительность тоже разная. Если мы используем Vue в качестве видеокарты, а Miox в качестве компьютера, то нам нужен драйвер видеокарты, чтобы весь компьютер принимал эту видеокарту.
Итак, я предлагаю концепцию, которая представляет собой концепцию драйвера рендеринга. Vue — это всего лишь движок рендеринга нашего Miox, который используется для рендеринга страниц, которые можно понимать как шаблоны. Нам также нужен драйвер, чтобы сообщить Miox, как рендеринг Vue реализован в Miox. Эту часть можно получить уздесьпонимать. Конечно, не только Vue, мы также можем интегрировать React в Miox. Теоретически, если имеется соответствующий драйвер рендеринга, любой движок рендеринга можно подключить к Miox для использования. Естественно, стиль письма каждого станет стилем письма этого движка. Это наша сменная конструкция. При использовании его в компании нам не нужно заботиться о том, какой движок рендеринга использовать, Miox может его поддерживать и помогать вам управлять всей системой маршрутизации.
Реализация на основе промежуточного программного обеспечения
Во внешнем интерфейсе, если мы можем использовать промежуточное программное обеспечение для перехвата всего логического процесса, это весьма благоприятно для разработки, может не только улучшить читаемость кода, но и повысить эффективность на конкретном бизнес-уровне. Мы используем внутреннюю логику маршрутизации, чтобы привести пример:
Когда мы сталкиваемся с некоторыми API, которые требуют аутентификации входа, мы можем использовать
/authorize
Префиксы маршрутизации обрабатываются единообразно с помощью промежуточного программного обеспечения. Другие не проходят логику проверки.
const Authorize = require('./auth');
const AuthorizeApi = require('./auth/routes');
route.use(
'/authorize',
Authorize.connect(), // Authorize.connect是统一的验证逻辑代码
AuthorizeApi.routes(),
AuthorizeApi.allowedMethods()
);
так через/authorize
маршруты должны пройти черезAuthorize.connect()
для проверки разрешения. Это делает код очень лаконичным и простым для понимания.
Дизайн Miox таков: благодаря этой архитектуре промежуточного программного обеспечения у нас есть возможность единообразно перехватывать и обрабатывать во внешнем интерфейсе. В реальном производстве мы используем промежуточное ПО во многих местах для обработки унифицированной логики проверки, что значительно повышает удобство сопровождения кода.
Так что, если вы не используете его? Когда мы заходим на страницу, нам нужно встроить кусок кода в каждую страницу, чтобы решить проблему с разрешениями.Увеличивается не только количество кода, но и для последующего обслуживания может возникнуть проблема с отсутствующими изменениями.
Для тех, кто хочет узнать больше о промежуточном программном обеспечении, я рекомендую посмотретьkoa-router.
Кэшированные страницы повышают производительность рендеринга
Что касается кеширования, то эта тема слишком большая.Что касается механизма кеширования Miox, то могу лишь кратко представить его.Заинтересованные друзья могут глянуть.исходный код.
В процессе разработки, особенно для разработки мобильных страниц, нам нужно сохранить положение прокрутки предыдущей страницы, тогда мы не можем уничтожить предыдущую страницу при переходе на другую страницу, причина в том, что мы хотим вернуться на предыдущую страницу. остается в предыдущей позиции прокрутки. Затем нам нужно кэшировать эту страницу, чтобы гарантировать, что местоположение не изменится. Miox имитируетhistoryчасть API, добавляя слой стека страниц. Нам нужно поддерживать этот уровень стека страниц, чтобы обеспечить отслеживаемость страниц. Каждый раз, когда мы передаем алгоритм для динамического сравнения отношений между маршрутами и страницами, чтобы выбрать из этого стека кэшированную страницу, которую мы хотим. Конечно, когда такой корреспонденции нет, мы, естественно, должны ее создать. мы основаны наМаксимально возможное повторное использование страницЦель состоит в том, чтобы кэшировать отношения между этими страницами и маршрутами.
Некоторые люди могут спросить, если кэша слишком много, повлияет ли производительность на переключение страниц? Да, чрезмерное кэширование страниц также является ключом к снижению производительности. Здесь мы оптимизировали количество кешей. При запуске службы miox у нас есть параметр конфигурацииmax
, как правило, по умолчанию один, конечно, вы также можете свободно установить максимальное количество, чтобы обеспечить производительность кеша.
Проблемы, оставшиеся от истории: пути решения проблемы направления истории
В истории все мы узнаем, что нынешний браузер не может определить направленность поведения, невозможно дать направление, которое мы хотим сделать автоматический эффект переключения страницы. Чтобы решить эту проблему, мы собрали решение отрасли, используяsessionStorage
для имитации стека истории для решения этой проблемы (добавлен новый API историиhistory.index
динамические свойства, чтобы сообщить, где мы сейчас находимся в стеке). Мы интегрировали это решение в Miox и улучшили его, чтобы сообщить механизму анимации, как это поведение должно вести себя в браузере. Естественно, анимационный движок может автоматически переключать анимацию страницы в соответствии с этим для достижения эффекта автоматической обработки.
Официальный предоставляет простой модуль для поддержки анимации.Конечно, друзьям очень просто настроить анимацию.Подробнее см.здесь.
Независимый жизненный цикл страницы
在传统的MVX框架中提供了组件的生命周期,我们在某种意义上也认为是页面的生命周期,但是我们对比原生IOS的周期行为,还是有所欠缺的。 Напримерactive
Жизненный цикл. Что это значит? Позвольте мне привести пример:
Когда страница переводится в фоновый режим и снова активируется, мы не знаем, активирована ли она снова, мы можем только знать, что страница снова открывается, и концепция второго входа требует большого количества кода для помощи. В традиционной структуре сложно вызвать другой
mounted
жизненный цикл, так как страница былаmounted
проходить. Miox дает определение такого жизненного цикла.
// use vue.js
export default Vue.extend({
mounted() {
this.$on('webview:active', this.activeLife);
},
methods: {
activeLife() {
console.log('我被唤起了');
}
}
})
Конечно, мы также можем выбросить эти жизненные циклы напрямую в глобальную сеть для глобального мониторинга.
app.on('webview:mounted', webview => {
console.log(webview);
})
Для предыдущего жизненного цикла мы также предоставляем следующие жизненные циклы:
- webview:enter
- webview:leave
- webview:beforeEnter
- webview:beforeLeave
Эти циклы дают вам хороший контроль над процессом и очень полезны для автоматического закапывания чего-либо.
рендеринг на стороне сервера
Текущая основная архитектура поддерживает рендеринг на стороне сервера для расширения возможностей SEO, поэтому для Miox им также необходимо поддерживать рендеринг на стороне сервера. Учитывая, что Miox сам будет оборачивать некоторый код для отображаемого контента, нам нужно реализовать SSR самостоятельно. Конечно, SSR-реализация движка рендеринга делается самостоятельно. То есть нам нужно обернуть его слоем SSR-рендеринга.
Miox временно поддерживает рендеринг SSR для Vue и постепенно добавит рендеринг SSR для React в будущем. и Байдуsan.js
Фактически, к нему также можно получить доступ для достижения SSR-рендеринга. Рендеринг на стороне сервера не представляет особых проблем, если вы можете освоить принцип работы Miox.
наконец
Что касается открытого исходного кода, наша команда приложила много внутренних усилий, и мы также консультировались со многими крупными коровами, надеясь создать для вас простую архитектуру разработки, которая поможет вам завершить свой бизнес. В настоящее время дальнейшие планы команды выглядят следующим образом:
- Улучшить документацию SSR
- Нормализуйте сообщения git на Github
- Поддерживать проблемы и PR на Github
- Улучшения одиночного теста и покрытия кода
- Подумайте больше об архитектуре маршрутизации, чтобы улучшить Miox
- Предоставить демо-версию на стороне ПК
- Предоставить примеры кода разработки в соответствии с реальным сценарием разработки Miox.
Я надеюсь, что вы увидели, что эта статья может поддерживать нас и дать нам больше, чтобы предоставить некоторые комментарии и предложения, давайте продолжим улучшать Miox. Как маленький партнер, помогитенажмите звездочку.
Проект с открытым исходным кодом вGitHub: 51nb/Miox