предисловие
Прежде всего, приглашаю всех следовать за мной.Счет наггетси Гитхабблог, что можно рассматривать как небольшое поощрение для меня, ведь у меня нет денег, чтобы писать вещи, и я могу продолжать на своем собственном энтузиазме и всеобщем поощрении.
Основная причина, по которой я хочу написать эту серию статей, заключается в том, что я ничего не писал уже почти месяц, а за последнее время было так много всего, что у меня не так много времени, чтобы изучать то, что мне нравится. Я видел Бога некоторое время назадlivoras, объяснение Virtual DOM очень подробное.Поскольку я занимаюсь разработкой React, я также являюсь пользователем Virtual DOM, поэтому я начал писать серию статей о Virtual DOM, и я также хочу попробовать реализовать набор Virtual DOM самостоятельно. Поэтому в этой серии статей мы проведем серию анализов на тему Virtual DOM и даже попытаемся вместе с вами реализовать свой собственный фреймворк Virtual DOM Заинтересованные студенты могут подписаться на меняСчет наггетсИли подписывайтесь на мой Githubблог.
Обзор фреймворка
Я впервые услышал, что концепция Virtual DOM должна исходить от React, и когда я не понимала ее, я чувствовала, что эта концепция — очень высокоуровневое слово. На самом деле рождение любой технологии имеет соответствующую историю, и ничто не появляется из воздуха, так же, как я слышал, многие критикуют язык JavaScript за его грамматическую шелуху, но по сути нужно понять, почему появился JavaScript и Автор Брендан Эйх разработал широко популярный язык высокого уровня всего за дюжину дней, вы не должны так думать. Точно так же появление Virtual DOM также имеет определенную историческую причину, которая должна говорить об истории интерфейсных фреймворков.
На самом деле, мы можем делать все то же, что и фреймворк, вручную.Когда мы изучаем JavaScript в университетской аудитории (конечно, у некоторых исследований нет соответствующих курсов), когда мы хотим использовать JavaScript для создания программы проверки формы, можно сделать не один десяток строк кода.В это время фреймворк раздут и вам не нужен. Даже фреймворк значительно увеличит ваши затраты на обучение и снизит скорость работы вашей программы (фреймворк не гарантирует, что эффективность должна быть выше, чем ваша ручная работа). Но когда масштаб вашей программы будет постепенно увеличиваться, вы обнаружите, что объем вашего кода будет увеличиваться в геометрической прогрессии, а в js-файле даже будут десятки тысяч строк кода (не удивляйтесь, я действительно видел это общее), в настоящее время поддержание этого кода было бы катастрофой.
В настоящее время применяются различные интерфейсные фреймворки, целью которых является не повышение производительности, а поддержание ремонтопригодности и облегчение командной разработки. Но халявы на свете не бывает.Ради ремонтопригодности программы вы отказываетесь от части производительности в качестве компромисса.Ведь никакой фреймворк не имеет высокой производительности ручной нативной работы,потому что фреймворк должен быть универсальным и уметь обрабатывать различные сцены.
MVC
Фактически, все, что нужно сделать переднему интерфейсу, — это отобразить интерфейс (представление) данных, и изменения в интерфейсе могут вызвать соответствующие изменения данных (модели), а когда данные (модель) изменяются, интерфейс ( View) также может вовремя реагировать и реагировать соответствующим образом. В конечном счете, это то, как координировать отношения между View и Modal.
Фреймворк, похожий на Backbone, появившийся в первые дни, — это типичный MVC (на самом деле я не сталкивался с этой эпохой). Установив уровень контроллера в представлении и модели, операции, инициированные взаимодействием с пользователем, будут переданы контроллеру, а уровень контроллера будет управлять соответствующими изменениями данных модели. Когда данные модели изменяются, он уведомляет соответствующее представление через режим наблюдателя, а затем представление повторно запрашивает данные модели для внесения соответствующих изменений интерфейса.
По мере увеличения масштаба приложения вы обнаружите, что в шаблоне MVC есть несколько существенных проблем.Соответствие между моделью и представлением является много-многим.Одна модель может соответствовать нескольким представлениям или одно представление нескольким моделям или даже больше Сложная взаимосвязь между Моделью и Представлением усложняет разработку. А поскольку представление зависит от модели, реализовать компонентизацию представления в этом режиме относительно сложно.
MVP
Мы не хотим, чтобы зависимость между представлением и моделью была слишком тесной, поэтому мы можем улучшить шаблон MVC, и появится шаблон MVP.
Таким образом, мы реализуем независимость модели и представления через презентер. Пока требуемый интерфейс зарезервирован между представлением и моделью, они не влияют друг на друга и прозрачны друг для друга. На этом основании нам необходимо реализовать View Componentization очень просто. Однако этот режим не лишен недостатков: логика презентатора не только должна выполнять все функции предыдущего контроллера, но также должна принимать уведомления об изменении данных модели и изменять пользовательский интерфейс в соответствии с соответствующей функцией. из-за чего у Presenter слишком много функций, что делает Presenter слишком раздутым и сложным в обслуживании.
MVVM
Мы обнаружили, что MVP также имеет соответствующие недостатки, поэтому предшественники внесли улучшения на основе MVP, и появилась структура MVVM.
Преимущества MVVM очень очевидны, что значительно улучшает ремонтопригодность.Взаимное ручное обновление обслуживания между View и Model выпущено и заменено автоматическим обновлением. Однако из-за относительно высоких затрат на создание и обслуживание ViewModel не подходит для некоторых простых страниц, но увеличивает производительность для сложных представлений.
Решить по-другому
До сих пор мы понимали, как структура типа MV* разрешает связь между уровнем модели и уровнем представления и обрабатывает связь между ними, создавая различные промежуточные уровни (контроллер, презентатор, представление модели) между моделью и уровнем представления. Вид Синхронизированные отношения. Но можем ли мы изменить способ мышления, Вид можно рассматривать как представление Модели, соответствующее определенным правилам, поэтому, когда Модель изменяется, Представление непосредственно перерисовывается.
Мы не можем не чувствовать, что этот метод работы действительно груб!
Этот метод работает? Конечно! На самом деле, разве это не общая идея React? Но у бывалого у вас сразу возникнет вопрос, надежна ли эта штука? На самом деле, если изменения Вида, вызванные изменениями Модели, очень велики (например, изменились все интерфейсы), этот режим будет работать хорошо, потому что сами изменения интерфейса эквивалентны повторному рендерингу. Но если текущее изменение Модели вызывает лишь очень небольшое изменение интерфейса (например, меняется цвет кнопки), мы обновляем весь интерфейс, что действительно страшно.
Учащиеся, которые работали над внешним интерфейсом, должны понимать, что скорость DOM такая же высокая, как и у JavaScript, потому что свойства и структура DOM спроектированы так, чтобы быть очень сложными. Можно ли полностью отказаться от этого метода?
нет! Иначе React не было бы.
Студенты, изучавшие принципы компоновки компьютеров в колледже, должны помнить, что вычислительная скорость ЦП очень высока, но по сравнению с ЦП другие компоненты ввода-вывода, такие как жесткие диски, имеют очень низкую скорость, и разница не проблема порядка. В это время компьютер вводит ОЗУ. Скорость ОЗУ ниже, чем у ЦП, но выше, чем у жесткого диска. Для данных, требуемых ЦП, их можно сначала поместить в ОЗУ с жесткого диска, а затем в результате Операции процессора также помещаются в оперативную память и сохраняются на жестком диске только при постоянном хранении. Даже ЦП будет чувствовать, что скорость ОЗУ все еще низкая, и внутри ЦП вводятся различные уровни кэш-памяти, чтобы устранить узкое место производительности между ОЗУ и ЦП.
Внешний интерфейс может извлечь урок из такого мышления: DOM медленный, но производительность JavaScript действительно неплохая, особенно сегодня с движком V8. Затем мы можем описать структуру DOM в JavaScript, аналогичную следующей структуре:
На самом деле описанная структура DOM выглядит следующим образом:
<div>
<button>按钮</button>
</div>
Конечно, этот метод представления не уникален, пока он может описывать соответствующую структуру DOM, вы можете играть в него свободно.
Таким образом, после каждого изменения Модели мы можем сначала получить соответствующую Виртуальную DOM-структуру этой Модели, которая представляет DOM-структуру Представления, соответствующего этой Модели. Если мы по-прежнему кэшируем структуру Virtual DOM, соответствующую последней модели в программе, то мы можем сравнить две структуры Virtual DOM до и после и использовать определенный алгоритм для поиска несоответствия между двумя виртуальными DOM. называется алгоритмом Diff. Затем используйте оптимальный метод, чтобы применить разницу между двумя виртуальными DOM к реальному DOM.
Значит, этот метод должен быть выше идеи повторного рендеринга, о которой мы говорили в начале? Конечно нет, если интерфейс меняется очень сильно, то производительность упомянутого выше Virtual DOM может быть ниже, чем при перерендеринге, потому что процесс Diff тоже имеет потери производительности, даже если React использует различные эвристические алгоритмы для объединения двух Virtual DOM. DOM В случае, когда древовидная структура сокращается с O(n ^ 3) до O(n), в случае очень большого количества узлов следует также учитывать стоимость Diff.
Суммировать
В этой статье мы в общих чертах рассмотрели историю усовершенствований различных сред MV*, чтобы описать еще одно новое решение, предложенное React, и почему React представил Virtual DOM. Чтение этого может помочь вам немного понять Virtual DOM.Приглашаю всех обратить внимание на мой блог, и я продолжу обновлять серию статей о Virtual DOM и других идеях, которые я узнал во время обучения интерфейсу. Если что-то не так, пожалуйста, дайте мне знать.