Расскажите о моем восприятии современных интерфейсных фреймворков.

Сейчас в мире фронтенда есть три основных фреймворка: Vue, React и Angular, и это почти все необходимые навыки для фронтенд-инженера.

Но я не знаю, сколько людей тщательно задумывались над тем, почему это так?

Некоторые новые выпускники и люди, только вступающие в отрасль, теперь сталкиваются с выбором: изучать Vue, изучать React или изучать Angular, как только они переходят в отрасль фронтенда.

На самом деле, в первые годы такой проблемы не было, нам не нужно было выбирать, на тот момент, когда мы писали фронтенд, jQuery был челноком, просто сделал, и готово.

Так почему же людям сейчас нужно выбирать различные фреймворки?

На самом деле, причина, по которой нам нужно выбрать фреймворк сейчас, в основном состоит в том, что потребности, с которыми мы сталкиваемся, изменились. Все должны понимать, что если мы пишем только страницу, которая чисто отображает информацию и не имеет никаких интерактивных функций, по сути, даже сейчас нам не нужно выбирать фреймворк, нам достаточно написать несколько строк CSS и HTML для завершить задачу.

Так как требования, с которыми мы сталкиваемся, стали более сложными, наши приложения часто должныВремя выполненияПроведите некоторое взаимодействие.

Есть три очень важных слова, которые я выделил жирным шрифтом, и они называются Runtime. В современной фронтенд-разработке приложения, которые мы разрабатываем, часто должныВремя выполненияДля выполнения взаимодействий эти взаимодействия были просто простыми взаимодействиями, такими как слайд-шоу или вкладка, переключающиеся раскрывающиеся меню в первые дни. Эти взаимодействия совершенно хорошо с jQuery. Но в современном интерфейсе наша цель состоит в том, чтобы воспользоваться сетью на местные приложения PK и PK с родным.

Что на этот раз мы найдем использование jQuery для разработки приложений, наш код становится очень сложным в обслуживании, так зачем использовать современный фреймворк, такой как Vue, React, чтобы его было легче поддерживать?

Здесь, пожалуйста, позвольте мне рассказать историю, небольшой эпизод.Несколько дней назад я обсуждал в группе WeChat, в чем разница между Vue и jQuery, и некоторые люди очень сильно говорили, что разница в том, что Vue имеет компоненты ,что это и что?некоторые особенности.

В то время я высказал свое мнение в группе WeChat, я сказал, что разница между Vue и jQuery только в одном пункте,Декларативный и императивный.

Мы можем подумать об этом, какова цель использования jQuery для управления DOM? это длячастичный вид обновленияДругими словами, этолокальный повторный рендеринг.

jQuery — это императивная операция DOM, императивное представление частичного обновления, в то время как современные основные фреймворки Vue, React, Angular и т. д. являются декларативными, декларативными представлениями частичного обновления.

Почему декларативные манипуляции с DOM могут сделать приложения более удобными в сопровождении?

Чтобы понять эту проблему, давайте сначала кратко представим, что является императивным, а что декларативным.

императив

Императив, как и jQuery, мы все хотим что-то сделать и просто делаем это, например следующий код:

$('.box')
  .append('<p>Test</p>')
  .xxx()
  .yyy()
  .jjj()
  ...

Императивный стиль заключается в том, чтобы вызывать метод напрямую и делать это напрямую, это просто, прямолинейно и грубо.

Представьте себе очень простую сцену, например эффект переключения, нажатие кнопки, переключение цветов.

В императивном письме мы должны писать так: если текущий цвет такой, какой он есть, пусть он станет другим цветом.

Если хорошенько подумать, то на самом деле его можно разделить на два поведения: одно — судить о состоянии, а другое — манипулировать DOM.

Так что же такое декларативный? ?

декларативный

ДекларативныйОписывая сопоставление между состояниями и представлениями, а затем оперировать DOM с помощью такого отношения сопоставления или специально использовать такое отношение сопоставления для создания узла DOM и вставки его на страницу. Подобно шаблонам в Vue. Роль шаблона заключается в описании отношения сопоставления между состоянием и DOM.

В том же сценарии мы используем шаблон в Vue для его реализации.После того, как мы опишем отношения сопоставления с шаблоном, когда мы нажимаем кнопку, нам нужно только изменить переменную цвета, чтобы выполнить требования.

Увидеть разницу?

Тщательно подумайте и используйте Vue для достижения тех же требований.Если вы посмотрите на подразделение, у нас есть только одно поведение и только состояние в логике. А jQuery — это два поведения: состояние + манипулирование DOM.

Так почему же декларативный подход может упростить поддержку кода приложения?

Потому что это позволяет нам сосредоточиться только на поддержании состояния. Таким образом, когда приложение сложное, на самом деле наше мышление, то, как мы управляем кодом, находится только в состоянии, и все операции DOM не должны касаться, что, можно сказать, значительно снижает сложность обслуживания кода. .

Нам больше не нужно сосредотачиваться на том, как работать с DOM, потому что фреймворк поможет нам сделать это автоматически, нас просто беспокоит только состояние.

Однако, если приложение особенно сложное, мы обнаружим, что даже если мы сосредоточимся только на поддержании состояния, это все равно сложно, даже если мы будем поддерживать только состояние, поэтому существуют технические решения, такие как Vuex и Redux.

Что такое рендеринг?

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

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

Процесс вставки модели DOM генерации состояния на страницу и ее отображения в пользовательском интерфейсе называется рендерингом.

Как современные интерфейсные фреймворки обрабатывают рендеринг

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

Как перерендерить?

Самое простое и грубое решение, и самый распространенный способ, которым я обычно пишу некоторые простые функции в проектах, не использующих какой-либо фреймворк, — это сгенерировать новый DOM с состоянием, а затем заменить старый DOM на innerHTML.

Небольшой функциональный блок, который я написал, хорош таким образом, потому что в функции задействовано мало DOM-тегов, и при изменении состояния почти все теги моего функционального блока нужно изменить, поэтому даже использование innerHTML не даст никакого эффекта. , Аргументы в пользу потраченной впустую производительности.

Но фреймворк не работает.Если фреймворк заменить на innerHTML, то он не будет частично перерисовываться, а будет обновляться вся страница целиком.Этот характер изменится, так как же фреймворк добивается частичного перерендеринга ?

Для решения этой проблемы необходимы некоторые технические решения для ее решения.Это может быть VirtualDOM, но это не обязательно должен быть VirtualDOM.Также это может быть процесс грязного обнаружения в Angular, или это может быть мелкозернистая привязка. Например, Vue1.0 использует мелкозернистую привязку.

Что такое мелкозернистая связка?

Детальная привязка означает, что состояние привязывается к определенному тегу на странице. То есть, если в шаблоне есть десять тегов, использующих переменную, то эта переменная привязана к десяти конкретным тегам.

По сравнению с React и Angular гранулярность относительно грубая, и их обнаружение изменений на самом деле не знает, какая переменная состояния конкретна, поэтому требуется жесткое сравнение, и после сравнения известно, какую часть представления нужно обновить. .

Детальная привязка Vue на самом деле знает, какое состояние изменилось в момент изменения состояния, а также знает, какие конкретные теги используют это состояние, поэтому все становится намного проще.Цель частичного обновления может быть достигнута путем непосредственного обновления конкретного теги, привязанные к этому состоянию.

Но это на самом деле имеет определенную цену, потому что гранулярность слишком тонкая, будут определенные накладные расходы на отслеживание зависимостей. Поэтому Vue2.0 начал принимать компромиссное решение, которое заключается в настройке привязки на среднюю степень детализации.

Состояние соответствует компоненту, а не конкретному тегу. Одним из преимуществ этого является то, что это может значительно уменьшить количество зависимостей, ведь количество компонентов намного меньше, чем конкретных тегов в DOM. Но для этого требуется еще одна операция: при изменении состояния уведомляется только компонент, так как же компонент узнает, какой тег DOM нужно обновить? ?

Ответ — виртуальный дом.

То есть, когда уровень детализации настроен на средний, еще одна операция — использовать VirtualDOM внутри компонента для повторного рендеринга.

Vue очень умен, чтобы улучшить производительность фреймворка с помощью двух технических решений обнаружения изменений + VirtualDOM.

Таким образом, Vue2.0 представил VirtualDOM не из-за того, насколько хорош VirtualDOM, а потому, что VirtualDOM в сочетании с обнаружением изменений может настроить привязку на среднюю степень детализации, чтобы решить проблему накладных расходов на отслеживание зависимостей.

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

Таким образом, способ обнаружения изменений в определенной степени уже определил то, как фреймворк отрисовывается.

Я написал PPT о принципе реализации VirtualDOM, если интересно, можете посмотреть.портал.

Другой - компиляция шаблона. На самом деле, я мало говорил о компиляции шаблона. Роль шаблона заключается в описании отношения отображения между состоянием и DOM. Через шаблон может быть скомпилирована функция рендеринга, а VirtualDOM может можно получить, выполнив эту функцию рендеринга.VNode, представленный в , на самом деле, если вы читали PPT, в котором я представил принцип VirtualDOM ранее, вы будете знать, что различающиеся узлы VirtualDOM на самом деле различаются VNodes. Я написал статью о принципе реализации шаблонной компиляции.портал.

наконец

Последнее, что я хочу сказать, это то, что я лично чувствую себя немного стремительным в текущем фронтенде.Многие люди гонятся за новыми.Каждый день я обращаю внимание на какие-то новые функции.Сегодня завтра будет выпущен новый фреймворк. Я согласен с этим, но я предпочитаю видеть суть, гоняясь за новыми.

Конечной целью всех технических решений является решение проблемы.Сначала есть проблема, а затем есть решение.Решение может быть не идеальным.Решений может быть много, так каковы преимущества и недостатки между ними? На какие компромиссы и компромиссы пошел каждый из них при решении проблемы?

Нужно видеть суть через явление, чтобы не запутаться на поверхности.