Недавно я купил большой Live You Yuxi: говорить о интерфейсной структуре, не говоря об этом.Это Live подняло мое фронтенд-мышление на беспрецедентную высоту: когда мы новые фронтенд-разработчики, мы находимся в плавающем и борющемся пирамиды талантов фронтенда. Когда мы думаем о том, какую структуру изучать, как начать работу с фронтендом и что делать, сталкиваясь с узкими местами в обучении, именно эти отраслевые гиганты направляют нас своими собственными действиями. компромиссов, которые сделала технология? Теперь я организую соответствующие вещи в виде заметок. Я надеюсь, что студенты, которые заинтересованы в разработке интерфейса, могут поддержать вас.
Компоненты могут быть функциями
Представьте, что все приложение — это большая функция, которая может вызывать другие функции, каждый компонент — это функция, компонент может вызывать другие функции, в целом — древовидная структура.
Компоненты классифицируются
- Чистые компоненты отображения, ввод данных, вывод DOM, интуитивно понятный и понятный
- Компонент доступа, компонент-контейнер в сценарии React, этот компонент будет иметь дело со службой уровня данных и будет содержать некоторую логику для работы с сервером или источником данных, а контейнер будет передавать данные в компонент представления.
- Интерактивные компоненты, типичным примером является инкапсуляция и расширение компонентов формы.Большинство библиотек компонентов основаны на интерактивных компонентах, таких как Element UI, для которого характерна более сложная интерактивная логика, но это более общая логика, подчеркивающая повторное использование компонентов
- Функциональные компоненты, взяв в качестве примера сценарий приложения Vue, компонент представления маршрутизатора и компонент перехода маршрутизации, которые сами по себе не отображают никакого контента, являются логическими вещами, которые существуют как расширение или абстрактный механизм.
Сравнение JSX и шаблонов
Суть JSX в Javascript.Он полностью приобретает гибкость Javascript.Его самая большая ценность в том,что он лучше,чем чистые шаблоны при написании функциональных компонентов,но шаблоны не плохи для презентаций и других вариантов использования.Шаблоны позволят вам вложить меньше логики Хотя компонент отображения относительно прост по логике, он все же имеет определенную сложность в стиле.
Разделение кода (colocation)
Соединяем то, что должно быть вместе. Например, в однофайловом компоненте Vue мы складываем воедино логику шаблонов, стилей и javascript. В настоящее время это делают основные фреймворки. Если эту концепцию расширить, документация компонента также может быть объединен с другими компонентами компонента.После компонентизации это отличается от традиционного разделения ответственности.Традиционное разделение ответственности делится на языковые единицы, а компонент представляет собой сам компонент как сегментацию.абстракция
Механизм обнаружения и рендеринга изменений
- механизм рендеринга
Самый важный аспект рендеринга в современных интерфейсных фреймворках — декларативный.Концепция сравнения — императив.Наиболее прямым примером императива является то, что мы используем Jquery, чтобы получить селектор «непосредственно сухой», использовать команды для работы, просто, но вы скоро столкнетесь с проблемами обслуживания. В английском языке есть слово jQuery Spaghetti. Spaghetti означает спагетти. Значение этого слова в том, что ваш код будет написан позже. Как и кусок спагетти, его трудно поддерживать. Преимущество декларативный заключается в том, что мы напрямую описываем, каким должно быть отношение отображения между данными и структурой DOM, без необходимости выполнять эти операции вручную.
В React есть уравнениеview = render(state), здесь render — это функция рендеринга, которую мы написали в React.Шаблон Vue на самом деле скомпилирован в функцию рендеринга, поэтому суть между шаблоном и JSX аналогична, состояние ввода, DOM вывода, в идеале мы описываем это отношение, что вход меняется и выход также меняется. Нам не нужно беспокоиться о том, что произошло между входом и выходом. В частности, базовой реализацией может быть виртуальный DOM, но это не обязательно должен быть виртуальный DOM, это может быть мелкозернистая привязка
- обнаружение изменений
Друзья, которые использовали vue, знают, что данные vue отзывчивы, vue будет преобразовывать данные, которые вы передаете, и после преобразования, когда вы изменяете значение некоторых атрибутов, vue будет соответствующим образом обновляться, прикрепляя особенно актуальный Speech PPT, который имеет подробный процесс:
ppt
Живые вопросы:
В: Всегда был вопрос. В прошлом его критиковали. Почему декларативный метод написания Vue уважают?
Ответ: Область действия Javascript в этом onclick в HTML глобальна. Когда вы пишете это в vue, есть четкая область действия Javascript. Область влияния, которую может достичь ваша привязка и ваш метод, хорошо установлена, это принципиально отличается от глобальный Javascript. Кроме того, когда мы пишем это в vue или React, ваша логика Javascript и ваш шаблон или ваш JSX вместе, вы можете подумать о том, что мы упоминали ранее Концепция совместного размещения, поэтому это не вызовет трудностей в обслуживании, но если вы напишите его прямо в глобальном Html, вы совершенно не представляете, где ваш Javascript может ссылаться на переменную или вызов.
В двух словах, обнаружение изменений в основном делится на два типа:
-
pull
Так называемое вытягивание, система не знает, когда данные изменились, ей нужен сигнал, чтобы сообщить ей, что данные могли измениться, и эта система выполнит более жесткое сравнение.В React производительность Virtual Dom Diff , В Angular это весь процесс грязной проверки. Предпосылкой для этого является то, что Javascript достаточно быстр. Хотя это расточительно, производительность приемлема. -
push
Напротив, ответные данные Vue или механизм данных RXJS могут знать об изменениях данных сразу после изменения данных, и мы будем знать, какие данные изменились в определенных программах, чтобы можно было выполнять относительно более мелкие обновления. самая крупнозернистая, поэтому в масштабных приложениях нам нужно помочь системе уменьшить часть бесполезной работы, но форма push также имеет свои недостатки, чем мельче гранулярность, для каждой вашей привязки потребуется обсервабел/наблюдатель, что приведет к соответствующим накладным расходам памяти и отслеживанию зависимостей, поэтому в vue2 выбрано относительно среднезернистое решение.Это проталкивание на уровне компонентов, и каждый компонент является реагирующим наблюдателем.Когда данные изменяются, мы, компоненты, можем обновляться, внутри каждого компонента с помощью Virtual Дом сравнивает, существенная разница между push и pull заключается в том, что стоимость обнаружения обменивается на определенную степень автоматической оптимизации.
государственное управление
На самом деле, концепция управления состоянием была вынесена на обсуждение только после того, как FB предложил Flux.После первоначальной хаотической конкуренции Flux постепенно слился с Redux.Vux в определенной степени находился под влиянием Redux.Суть управления состоянием. миграция и изменение исходного события (исходного события), сопоставленного с состоянием, а затем сопоставленного с изменением пользовательского интерфейса, декларативный рендеринг помог нам решить сопоставление состояния с пользовательским интерфейсом, вот этот, поэтому управление состоянием этих библиотек На самом деле, как управлять процессом сопоставления источников событий с изменениями состояния, как отделить этот процесс сопоставления от компонента представления и как организовать эту часть кода для повышения удобства сопровождения, — вот основные проблемы, которые должны решаться с помощью состояния. управление.
Используйте Vue как Redux
Используйте Vue как MobX
Текущее решение для управления состоянием также сталкивается с некоторыми другими распространенными трудностями.Одна из них заключается в том, как отличить локальное состояние компонента от глобального состояния.Теперь нет очевидного различия между локальным состоянием и глобальным состоянием, а другая заключается в разнице между глобальное состояние и данные на стороне сервера.Существующее решение состоит в том, чтобы помещать данные, захваченные сервером, в хранилище.
маршрутизация
Маршрутизация — это проблема, которая встречается только в больших одностраничных приложениях.Традиционная идея маршрутизации более навязчива.Каждый маршрут имеет свою собственную модель данных, собственный шаблон и т. д., но когда появляются React и Vue, люди обнаружили, что разделение маршрутизации и Компоненты осуществимы и более гибки. Например, совершенно нормально использовать React напрямую без маршрутизации. Еще одно откровение заключается в том, что если вы думаете о маршрутизации из компонентов, это, по сути, становится процессом сопоставления URL-адреса с древовидной структурой компонентов, будет небольшие отличия в отображении url на компонент, надо ли начинать с url или с этого состояния, по сути суть одна и та же, т.к. url это сериализованное состояние.
Когда вы на самом деле сделаете это в SPA, вы обнаружите, что маршрутизация будет включать в себя множество других вопросов, таких как совместимость режима хеширования и режима истории, перенаправление, псевдонимы, отложенная загрузка, а затем самое сложное — переход, переход между маршрутами. switch должен предоставлять различные «хуки», и тогда эти «хуки» могут выполнять асинхронные операции, а «хуки» также могут отменять переход, делая переход недействительным, и так далее.
В целом, основные схемы маршрутизации немного похожи.Что более интересно, это последний reat-router4.То, что он пропагандирует, это способ использования самого компонента для маршрутизации.В значительной степени он использует вышеупомянутые Четвертый основной маршрут. Компонент представляет собой «функциональный компонент», который декларативно отображает другие компоненты в родительском компоненте. Отличие от традиционной схемы компонентов маршрутизации — «децентрализация». Вместо того, чтобы писать всю таблицу маршрутизации в одном месте, она пишет в разных местах.В компоненте преимущество этого в том, что гибкость очень хорошая, но есть и некоторые проблемы.Во-первых, централизованная таблица маршрутизации полезна для понимания структуры всего приложения.С другой стороны, децентрализованная маршрутизация для управления переходами, она будет слабее, и его управление переходами осуществляется непосредственно с жизненным циклом компонента.
Разница между веб-маршрутизацией и маршрутизацией приложений:
В настоящее время общая идея веб-маршрутизации такая же. Сопоставьте URL-адрес с деревом компонентов и перейдите с одного URL-адреса на другой URL-адрес. Мы помещаем новый URL-адрес в исторический стек, но позиция, соответствующая предыдущей позиции из стека Он был нами отброшен.Мы перешли из одного состояния в другое.Весь интерфейс нашего приложения перекочевал в другое состояние.Прыжок на нативном приложении как стопка карт,и новый интерфейс будет накладываться на существующий интерфейс. Выше, когда вы вернете его, просто удалите текущую карту, появится предыдущая карта, и схема маршрутизации, используемая в Интернете, будет неудобна для создания приложения.
CSS-схема
Основные CSS-решения
- Полностью отделен от JS, полагаясь на препроцессоры и спецификации, такие как BEM, для поддержания ремонтопригодности, более традиционный
- Модули CSS, все еще CSS, но скомпилированные, чтобы избежать глобальных конфликтов имен классов CSS.
- Различные решения CSS-in-JS, представленные сообществом React, более радикальны.
- Однофайловый компонент CSS Vue или компонент CSS Angular (написанный в декораторе), компромиссное решение
Сравнивая решения CSS, мы должны сначала прояснить проблему сцены.Если логика приложения была разделена на компоненты, это относительно сложная разработка приложения, и удобство сопровождения традиционного метода CSS будет проблематичным.
react-css-in-js
Статья против css-in-js
Некоторые проблемы с традиционным CSS:
- объем
- Critical CSS
- Atomic CSS
- мультиплексирование распределения
- Повторное использование на разных платформах
css-in-js имеет множество различных решений, каждое из которых решает некоторые из вышеперечисленных проблем, но не идеально:
- CSS-модули, встроенные стили и однофайловые компоненты vue могут напрямую добавить масштаб к этой проблеме.
- Так называемый Критический, например, если мы выводим страницу, во всем нашем приложении могут быть десятки страниц, но первая страница, которую мы выводим, всегда является первой страницей.Если ни одна страница не имеет соответствующего CSS, теоретически будет отображаться первая страница. Нам нужен только CSS первого экрана. Это так называемый критический CSS. Это особенно важно для рендеринга на стороне сервера. Решение состоит в том, чтобы определить, какой CSS используется для рендеринга во время рендеринга на стороне сервера. rendering.css-in-js и vue2.3+ имеют функцию времени выполнения.В процессе компиляции вставка CSS может быть связана с жизненным циклом компонента, а также может привести к сбору Critical CSS.
Живые вопросы:
В: Будет ли использование CSS-модулей в vue лучше, чем использование области действия?
Ответ: Я лично считаю, что принципиальной разницы нет, стоимость scoped будет ниже, CSS-модули будут иметь определенную стоимость времени выполнения, потому что требуется динамическая привязка классов.
- Концепция Atomic CSS: Например, у нас есть два правила CSS, одно — цвет: красный, другое — цвет: зеленый, мы пишем два стиля кнопок, одна кнопка красная, одна кнопка зеленая, если атомарный класс — It разделит цвет: красный на отдельный класс: A, отдельный цвет: зеленый на класс: B, а затем разделит все общие кнопки на класс: C, тогда красную кнопку можно назвать AC, а зеленую кнопку It это BC.. Одним словом, это разбить как можно больше отдельных правил на очень маленький класс, поэтому конечный результат в том, что ваш CSS более сжимаем и может стать меньше, соответствует стилю в css-in-js Кусок
- Аргументом в пользу распространения и повторного использования является то, что css-in-js — это полностью Javascript, поэтому его можно напрямую отправить в npm для повторного использования, как и обычные модули Javascript.Действительно, Javascript легче комбинировать и повторно использовать, чем чистый CSS, но вы также можете отправлять CSS Переход к npm и последующая ссылка на него напрямую через webpack не является полным преимуществом.
- Кросс-платформенное повторное использование: в VueX статический CSS компилируется в Javascript после синтаксического анализа, поэтому его можно повторно использовать на разных платформах.
инструменты для сборки
Инструмент сборки на самом деле решает несколько проблем:
- автоматизация задач
- Опыт и эффективность разработки (новые возможности языка, синтаксический сахар, горячая перезагрузка и т.д.)
- Требования, связанные с развертыванием
- оптимизация во время компиляции
Как разработать и внедрить интерфейсный код в крупной компании
Хотя сам Vue использует поток, рекомендуется использовать поток TypeScript, в основном с учетом опыта разработки и экологического совершенства.
обмен данными с сервером
В течение долгого времени наша традиционная практика вращалась вокруг Rest. Если сервер предоставляет относительно стандартный API Rest, тогда наш клиент может напрямую получить выборку или абстрагировать/инкапсулировать ресурс вокруг Rest. Конкретные приложения столкнутся с более сложными сценариями. заключается в том, что данные напрямую связаны, и между данными существует большая корреляция, а во-вторых, существует необходимость в push-синхронизации в реальном времени.В этом случае традиционный метод Rest будет более болезненным.
Руководство по рендерингу Vue.js на стороне сервера
кроссплатформенный рендеринг
С точки зрения front-end фреймворка суть кроссплатформенного рендеринга заключается в том, чтобы отделить механизм рендеринга фреймворка от DOM при проектировании фреймворка.Существует много способов реализовать это, и Virtual Dom не обязательно требуется. Инкапсулируя некоторые операции узла во время обновления, вы можете добиться кросс-платформенности, собственного механизма рендеринга, такого как React Native и VueX, по сути, имеющего адаптивный механизм рендеринга для каждой платформы внизу, пока механизм рендеринга открыт API операции узла можно связать со средой выполнения фреймворка для достижения цели рендеринга кода в фреймворке в нативный. Разделение здесь очень четкое, поэтому мы видим, что NG может подключаться к React. Native, VueX может запускать файлы Vue, VueX может работать на NativeScript и так далее.
новая норма
- Web Component
Веб-компоненты и технологии React, Angular, Vue-подобные компоненты, которые будут в будущем? - WebAssembly
Это универсальный двоичный и текстовый формат для Интернета, который может работать в браузере. Однако в текущей ситуации WebAssembly пока не может работать с DOM, а влияние на фреймворк пока относительно ограничено.
Суммировать
Подводя итог, мы поговорили о многих вещах, которые могут быть сложными, но, надеюсь, вы найдете что-то общее: технические решения — это все сначала проблемы, а потом идеи, сопровождаемые компромиссами. При выборе технологии измерения постарайтесь подумать о проблеме, стоящей за этой технологией, и о том, на какие компромиссы она пошла. Таким образом, с одной стороны, это может помочь нам лучше понять и использовать эти технологии, а также заложить прочную основу на тот случай, если в будущем вы столкнетесь с особыми ситуациями в бизнесе и вам потребуется принимать собственные решения.