А, домоское взаимодействие
С ростом популярности технологии ajax стали широко использоваться SPA-приложения. Внедрение SPA заставляет содержимое всего приложения асинхронно взаимодействовать на одной странице. Таким образом, разработка оригинального метода взаимодействия с DOM непроста в управлении. Например, на странице SPA много интерактивной и асинхронной загрузки содержимого. Наш подход заключается в том, чтобы выполнять привязку событий после каждого запроса, и затем выполните другую часть события после асинхронного запроса, привязки и т.д. Когда вызываются все асинхронные страницы, привязка на странице становится очень запутанной, различные элементы связаны, содержимое визуализированного представления не является логически логичным, и необходимо объявлять различные переменные для сохранения данных, возвращаемых каждый раз при асинхронной загрузке. загружается, потому что взаимодействие со страницей должно работать с этими данными, и, наконец, код проекта превращается в кашу.
2. Внешний интерфейс MVC
Для более удобного унифицированного управления событиями, данными и просмотром контента на странице существует ранний дизайн фреймворка MVC. MVC можно рассматривать как шаблон проектирования, и его основная идея состоит в том, чтобы разделить процесс взаимодействия с DOM на вызовы событий, получение данных и управление представлениями. Все предыдущие события, данные и представления будут управляться отдельно. Модели используются для хранения запросов данных и операций с данными, представления используются для хранения операций и изменений представлений, а контроллеры используются для управления различными привязками событий.
Например, каждую асинхронную страницу в SPA можно рассматривать как компонент, раньше практика заключалась в том, что каждый компонент выполнял свою операцию запроса данных, рендеринг и привязку данных независимо, но компонентов много, и каждый компонент делает это сам. Запутанный, логически запутанный. В mvc все запросы данных компонентов, рендеринг и привязка данных управляются унифицированной моделью, представлением и контроллером. Нам все равно, сколько компонентов у вас есть в следующих операциях.Если вы хотите вызвать его, вы должны настроить его через унифицированную модель, представление и контроллер. Вообще говоря, это как бы компонент, передающий свое управление в единое место для регистрации и звонка, что гораздо удобнее, я думаю, это уже всем понятно, поэтому я сэкономлю место и не буду приводить пример.
3. Фронтенд MVP
MVP может смотреться с MVP, и на это мы тоже специально обращаем внимание. Как и в MVC, m в MVC — это MODEL, V — это View, а P представляет presener, который немного похож на Controller. Другое дело, что в MVC v будет напрямую отображать M, а V делегирует все задачи в MVP P. V и P будут ссылаться друг на друга, поэтому их можно будет называть друг друга.
Например, мы можем внести небольшое изменение в код MVC и написать его так:
<div controller="Controller.vp" id="text">html</div>
var Controller = new Controller();
Controller['vp']= new VP({
$el: $('text'),
click: fn(e){
console.log(self.$el.html());
},
mouseenter: function(e){
console.debug(self.$el.html());
},
mouseleave: function(e){
console.info(self.$el.html());
}
});
Несколько преимуществ, так что ссылка представления и контроллера связана, и MVC обычно реализуется через асинхронный метод мониторинга событий или наблюдателя.Мы можем без проблем определять и регистрировать события мониторинга в любом месте.Событие и элемент html, который запускает событие вне ссылки.Когда приложение сложное, более проблематично поддерживать логику взаимодействия DOM. И mvp предоставляет простую ссылку, чтобы связать соответствующую операцию элемента с соответствующим презентатором. Когда мы хотим запросить контроллер, соответствующий элементу, мы можем вызвать его напрямую через Controller.vp Фактически, этот момент немного похож на определение mvvm, не так ли?
4. Фронтенд мввм
Концепцию mvvm можно рассматривать как автоматизированный презентатор, который в настоящее время еще больше ослабляет уровень C, и любая операция управляется viewModel. Итоговое поведение Контроллера на странице отражается в виде директив, а события регистрируются путем идентификации директив, чтобы управление было более понятным. См. пример определения инфраструктуры mvvm.
<form action="" id="form">
<label for="text" q-html="label"></label>
<input type="text" q-value="value" q-model="value" q-mydo="number | getValue">
<button q-on="click: submit"></button>
</form>
let viewModel = new VM({
$el: '#form',
data:{
метка: 'имя пользователя',
Значение: «Введите начальное значение»,
number: 0
},
method:{
submit(){
// doSubmit
}
},
directive:{
mydo(value){
console.log(value);
}
},
filter:{
getValue(){
reutrn value ++;
}
}
})
И определение MVP, немного похожее, разработка MVVM большое преимущество - зарегистрировать контроллер в контроллере в MVC к соответствующему элементу, что позволяет нам найти последнее обслуживание, устранить список событий в контроллере. Работа, а также Автоматически выполнять привязку данных после инициализации, вы можете настроить все тот же тип работы на странице, что значительно сохранил собственный код записи, чтобы сделать связь. Когда вы инициализируете этот код, вы автоматически поможете нам делать цифровые заливки, двунаправленные привязки и привязки событий. Так как кадры помогут мне? Давайте посмотрим на новые Что такое VM делает: это включено здесь, и список данных, методов, пользовательских списков директивы, первые программы для поиска этого элемента, начнут перейти к узлу свойства этого элемента, один раз пройденный к имени атрибута, содержащего Q-начало, это, это Считается, что является недвижимостью MVVM Framework Custom, а затем указание атрибута специально обрабатывается; например, когда он проходит в Q-HTML = «метку», значение этикетки в данных используется для обеспечения INNERHTML этого Элемент; если пересекается на q- on = "Нажмите: отправьте« Когда событие Click является привязке этого элемента, функция обратного копирования событий должна быть отправлена; или инструкция Q-Mydo может быть настроена, и она пересекается в атрибут узла, вызов Метод MyDO в Директиве, введите параметр, возвращенный методом GetValue в данных, и параметр ввода GetValue, является номером значение, и GetWalue здесь называется фильтром.
Здесь вам нужно знать, что инструкции атрибутов в начале q- предусмотрены фреймворком, а разные фреймворки имеют разные соглашения, такие как ng-, v-, ms-, которые все видели или использовали. Принцип создания и привязки viewModel здесь такой простой, если развернуть его по этой идее, то можно самому написать mvvm framework. Конечно, полная структура включает в себя множество вещей, включая богатые директивы, фильтры, выражения, идеальный API vm и даже некоторую обработку совместимости.
В заключение, от mvc к mvp, а затем к mvvm, шаблон проектирования интерфейса все еще развивается в основном направлении простой реализации, простого обслуживания и легкого расширения. Но в настоящее время различные интерфейсные фреймворки созрели и начали итерацию версий. Однако это еще не конец, мы до сих пор не оторвались от основной рутины программирования dom, совершенствование фреймворка только повысило эффективность нашей разработки, а вот эффективность dom-элементов существенно не повысилась.
5. Внешний виртуальный дом
Чтобы повысить эффективность взаимодействия с домом или свести к минимуму количество взаимодействий с домом, в настоящее время очень популярна концепция виртуального дома, и различные команды разного размера в круге в настоящее время инвестируют в проекты. Потому что изменение viewModel в конечном итоге требует манипулирования DOM в реальном времени для обновления уровня представления, а манипулирование объектом DOM по-прежнему медленнее, чем манипулирование объектом JavaScript. Причина очень проста.Существует много встроенных свойств объекта узла DOM.С точки зрения создания объекта DOM создание DOM должно иметь дело с инициализацией различных встроенных свойств, и требуется время для JavaScript для вызова DOM. Так что, если вы используете объекты JavaScript для описания, это просто.
Например, следующая структура:
<ul id="ui-list">
<li class="ui-list=item">1</li>
<li class="ui-list-item">2</li>
<li class="ui-list-item">3</li>
</ul>
Вы можете быть представлены следующим образом javascript
var element = {
tagName: 'ul',
props: {
id: 'ui-list'
},
children: [
{tagName: 'li', props: {class: 'ui-list-item'}, children: ["1"]},
{tagName: 'li', props: {class: 'ui-list-item'}, children: ["2"]},
{tagName: 'li', props: {class: 'ui-list-item'}, children: ["3"]},
]}
<ul id="ui-list">
<li class="ui-list=item">1</li>
<li class="ui-list-item">2</li>
<li class="ui-list-item2"></li>
</ul>
Здесь объект javascript эквивалентен виртуальному дому, взаимодействие с пользователем может привести к множеству мест dom, если это не витальный дом, может потребоваться выполнение нескольких операций, виртуальный дом, вы можете отразить взаимодействие нескольких пользователей с виртуальным домом, последнее чтобы выполнить алгоритм DIFF виртуального дома, а затем отправить его на уровень просмотра страницы. Относительно mvvm, начальной стадии рендеринга страницы, но также и для того, чтобы избежать поверхностного узла развертки, синтаксического анализа директив, чтобы знать, что эти операции являются операцией dom, использование виртуального dom, по-видимому, способно значительно повысить скорость рендеринга страницы.
Шесть, передний конец MNV *
Если виртуальный дом уменьшает количество взаимодействий с домом, то одна вещь, которую хочет сделать mnv*, — это полностью отказаться от использования дома, чтобы его можно было улучшить только на уровне представления, используя nativeView для замены текущего html. представление и логика взаимодействия. Его все еще можно реализовать с помощью модели представления, виртуального дома или контроллера, в зависимости от того, как это реализовано.
Для достижения работы NativeView разница здесь в том, что рендеринг nativeView выполняется через интерпретатор через производный синтаксис HTML при вызове, что требует добавления уровня интерпретатора между собственным и производным синтаксисом HTML для анализа существующего синтаксиса описания представления. . Например, давайте посмотрим на пример рендеринга Native:
// iOS
import React, {
Component,
} from 'react';
import {
TabBarIOS,
NavigatorIOS
} from 'react-native';
class App extends Component {
render() {
return (
<TabBarIOS>
<TabBarIOS.Item title="React Native" selected={true}>
<NavigatorIOS initialRoute= />
</TabBarIOS.Item>
</TabBarIOS>
);
}
}
Здесь и в виртуальном фреймворке похожие места получены из использования синтаксиса описания html для представления слоя представления, но разница заключается в том, что модель mnv является производным html, вызывающим nativeView для достижения отображения представления. Собственно здесь и реализуем раздел разница только в том что вид тут родной Посмотреть. Конечно, это всего лишь одна реализация mnv. Текущие реализации имеют более одной, это уже практиковалось программно mvvm для отображения модели представления в собственном представлении программы.
7. Резюме
Подводя итог, фронтенд-фреймворк развивается снова и снова, сначала в направлении повышения эффективности, а затем в направлении улучшения производительности.Здесь я просто хочу предложить концепцию mnv* для описания этого этапа нативной разработки фронтенда. . В настоящее время модель развития мнв начала выходить в поле зрения, а также быстро формируется и налаживается экосистема. Но несмотря на это, если нам нужно выбрать решение стека технологий, конечно, мы все равно берем наиболее подходящее как высший принцип. Не переусердствуйте.
Теги: mnv* эпоха разработки фреймворка, mnv, mnv*, mvvm