Инвентаризация развития передовых технологий в 2020 году

Закончился 2020. В этом году из-за эпидемии в той или иной степени пострадали все в жизни и работе. Однако в 2020 году развитие фронтенд-технологий не остановилось.

И как фронтенд-разработчики мы должны иметь представление об обновлении технологий. Хотя нам и не нужно изучать все новые технологии. Но «знать» и «понимать» эти технологии необходимо всегда.

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

эта статьяВ 2020 году я подвел итоги некоторых новых технологий во внешнем интерфейсе, их развития и тенденций..

Но нам не нужно глубоко понимать их все, наше внимание должно быть сосредоточено на следующих аспектах:

"К пониманию«Что делает эта штука
"понимать"Для чего эта штука?
"знаниеКак можно использовать эту вещь (сценарии использования)

"1" Миро интерфейсы

«Микро-интерфейс» должен быть одной из технологий, которые мы слышим больше всего в 2020 году. Многие крупные производители в настоящее время пробуют эту новую технологию для решения проблем в крупномасштабных проектах.

Хотя у нас есть модульные компоненты во фронтенд-разработке, они сильно отличаются от серверных «микросервисов».

Прежде чем узнать о «микро-интерфейсе», давайте дополним знания о «микросервисе» в бэк-энде для тех, кто не сталкивался с бэк-эндом.

Что такое микросервисы?

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

Если приведенная выше терминология сложна для понимания, мы можем понять ее таким же образом. Микросервисы — то есть написание одного бизнеса как самостоятельного сервиса, с независимыми серверами, системами интерфейсов и отдельной командой для разработки и сопровождения.

Например, на Таобао есть два «модуля» для заказов и пользователей. Возможно, вначале мы разработали эти модули вместе. Таким образом, ресурсы разработки и время, необходимое для разработки, относительно невелики. Ведь микросервисы — это не то, что может держать команда из 5-6 человек.

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

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

Поскольку серверная часть столкнется с ситуацией, когда сложность системы слишком высока, бизнес и взаимодействие естественного внешнего интерфейса будут становиться все более и более сложными. Поэтому, в конце концов, фронтенд также должен установить «микросервисную» систему вместе с бэкендом.

Что такое микрофронтенд?

Происхождение микро-фронтенда такое же, как и у бэк-энда.Непрерывное развитие бизнеса и функций модуля делает код содержимого модуля все более сложным и объемным, и в то же время он неизбежно будет иметь неизбежное взаимодействие с другими предприятиями.

Именно взаимосвязь между этими модулями делает нашу систему все более и более сложной в обслуживании, что сильно снижает «гибкость» разработки.

Так что делать? Давайте разделим бизнес большого приложения на небольшие «сервисные» модули по модулям. Эти небольшие модули будут работать на отдельном сервере, подобно внутреннему интерфейсу, а также будут разрабатываться и поддерживаться отдельной небольшой командой.

Такие системы и системы с микро-независимой интерфейсной архитектурой называются «микро-интерфейсами».

Команда разработчиков каждого «микроинтерфейсного» приложения имеет автономию на протяжении всего жизненного цикла приложения. Это включает в себя независимую разработку, независимое управление номерами версий, независимое тестирование, независимую упаковку, независимую визуализацию, независимое обновление и независимое развертывание.

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

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

Преимущества микрофронтендов

автономия- Каждое микроинтерфейсное приложение может разрабатываться, развертываться, поддерживаться и расширяться независимо, не затрагивая функции других микроинтерфейсных приложений.
специфичность- Каждое приложение микро-фронтенда рассчитано на набор функций и ориентировано на решение конкретной задачи. Если разработчики постепенно добавляют больше кода в микроинтерфейсное приложение, что делает его сложным, мы можем снова разделить его на несколько небольших микроинтерфейсных приложений.
Ловкость- Микро-фронтенд — это организация, состоящая из нескольких небольших независимых команд, отвечающих за свои собственные микро-фронтенд-приложения. Каждая команда развивается в небольшой хорошо понятной среде и может работать более независимо и быстрее. Это сокращает время цикла разработки.
Гибкое расширение- С помощью микроинтерфейсных приложений мы можем независимо расширять компоненты и функции для удовлетворения потребностей других приложений. Это позволяет командам правильно настраивать потребности инфраструктуры, точно измерять затраты на функции и поддерживать доступность при резком росте спроса на услуги.
простое развертывание—— Micro frontend поддерживает непрерывную интеграцию и непрерывную доставку, что позволяет легко и безопасно пробовать новые идеи и может независимо откатывать приложение, если оно не работает нормально. Поскольку приложения микроинтерфейса напрямую независимы, проблемы возникают только в их собственных приложениях, поэтому мы можем смело экспериментировать, легче обновлять код и сокращать время запуска новых функций.
техническая свобода- Архитектуры микроинтерфейса не следуют универсальному подходу. Команды могут свободно выбирать лучший инструмент или структуру для решения своей конкретной проблемы. То есть одно микро-интерфейсное приложение может использовать Vue, а другое — React. Поэтому команды, создающие микросервисы, могут выбрать для себя лучший инструмент или фреймворк.
многоразовый- Разделите интерфейсные приложения на четко определенные модули, что позволит командам использовать функциональные возможности для различных целей. Интерфейсные модули, написанные для одной функции, можно использовать в качестве строительных блоков для другой функции. Это позволяет приложениям загружаться самостоятельно, поскольку разработчики могут создавать новые функции без необходимости писать код с нуля.
эластичность- Независимость от внешнего интерфейса повышает устойчивость приложения к сбоям. В монолитной архитектуре при отказе одного компонента все приложение может стать неработоспособным. Благодаря разделенной архитектуре микроинтерфейсов приложения могут справляться с общими сбоями службы за счет сокращения функциональности без сбоя всего приложения.

Корпус микро-интерфейса

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

Представьте, что у нас есть домашняя страница для блога. Основная функция — отображать содержание нашей статьи. Конечно, блог на самом деле очень прост, и в обычных сценариях разработки ему не будет дан дизайн архитектуры микрофронтенда.

Но если мы действительно хотим сделать его более мощным, это тоже нормально:

Во-первых, когда пользователи заходят на нашу домашнюю страницу, они видят список статей, и пользователи могут искать статьи по ключевым словам. Вы также можете искать по категориям и тегам. Если посложнее, то можно еще отсортировать и поискать по читаемости и популярности (алгоритм вычисляет популярность).
Каждая статья должна иметь страницу сведений, и каждая страница сведений должна отображать подробный текст статьи. Если мы хотим усложнить задачу, мы также можем рассчитать, какие другие статьи заинтересуют пользователя, на основе тегов и ежедневных записей просмотра статей пользователем. В настоящее время мы можем добавить соответствующие рекомендуемые статьи в список.
В блоге неизбежно будет вводная страница блоггера (О программе), страница классификации статей (Категории) и страница меток статей (Теги).

Конечно, это не очень сложно, но когда мы продолжим добавлять больше функций в эту блог-платформу, например, когда мы наконец сделаем такие платформы, как CSDN, Nuggets и Zhihu, тогда микро-фронтенд необходим!

Метод микро-интерфейсной интеграции

Что ж, если когда-нибудь настанет день, когда мы станем большой платформой для блогов. Итак, как мы используем микрофронтенды? На самом деле способов интеграции много:

Состав шаблона на стороне сервера
Интеграция во время сборки
Интеграция во время выполнения через iframe
Интеграция во время выполнения через JavaScript
Интеграция во время выполнения через веб-компоненты

Мы не будем объяснять их здесь по одному, если однажды мы действительно столкнемся со сценарием, требующим от нас использования микроинтерфейсов для решения наших технических проблем. Давайте углубимся и узнаем о микро-фронтендах. Основная цель здесь состоит в том, чтобы дать нам ясно понятьЧто такое микрофронтенд,что можно решить,этокак решитьВот и все.

На самом деле, все методы интеграции вращаются вокруг очень естественного шаблона проектирования — каждая страница в приложении является «отдельным» приложением микроинтерфейса. На каждой странице будет «одно приложение-контейнер», и его роль:

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

Примерный дизайн страницы выглядит следующим образом:

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

"2" Атомный дизайн

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

КонцепцияBrad FrostПредложил, он использует атомарную композицию в химии для анализа и дизассемблирования композиции веб-приложения. Он заменяет атомы (Atoms), молекулы (Molecules), организмы (Organisms) и так далее.

напримерпоиск молекул(Поисковая молекула) созданаinput-text(введите текст) +button(кнопка) +label(название) и другие атомы. Затем эти молекулы объединяются, чтобы стать организмом (Организмом).

И организм (Организм) будет жить в шаблоне макета нашей страницы, и они могут быть воплощены в страницу и, наконец, отображены для наших пользователей.

Brad FrostАбстрагируйте дизайн наших интерфейсных компонентов и интерфейсов от структуры атомарного состава в химии. Давайте лучше разберемся, как состоят страница, компонент и элемент.

По сути, эта концепция позволяет взглянуть на нее с новой точки зрения.Модульный интерфейс(модульный интерфейс). Такой образ мышления позволяет нам глубже понять роль и API компонента, чтобы дизайн компонентов был более ясным и эффективным.

Простое и понятное представление:

Что такое атом?

Атомы являются основными строительными блоками материи. В компонентном дизайне атом — это наименьшая элементная единица компонента, а компонент состоит из нескольких атомов.

В веб-интерфейсе атомы могут быть:HTML-теги

метка стола
поле ввода
кнопка кнопка

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

Что такое молекула?

Все становится интереснее, когда мы объединяем атомы. Молекула представляет собой группу атомов, связанных вместе, и является наименьшей основной единицей соединения. Каждая молекула имеет свои свойства и является основой нашей дизайн-системы.

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

Когда мы объединяем молекулы с атомами, нам нужно следовать одному принципу: "делать только одно и делать это хорошо(Похоже ли это немного на шаблон проектирования: «Единственная ответственность»? Да, это то, что это означает.) Хотя молекулы могут быть сложными, как правило, все они представляют собой относительно простые атомы.возможность повторного использованияи жить.

Что такое Организм?

Молекулы могут служить строительными блоками, на которых мы строим интерфейсы. Мы можем соединить молекулы, чтобы построить организм (то есть один из наших интерфейсов). Организмы собираются из набора молекул, а составляющие его организмы являются частью интерфейса, обладающего относительно сложными и уникальными свойствами.

Например, на картинке выше мы комбинируем молекулы части логотипа веб-страницы. Затем мы объединяем молекулу поиска и молекулу логотипа вместе, и она становится организмом-заголовком на интерфейсе.

Это становится все более и более интересным, организм не является фиксированным компонентом, он состоит из множества молекул. Разные организмы могут использовать одни и те же молекулы или атомы, но все они функционируют по-разному.

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

Поэтому при построении молекул и построении организмов из молекул компоненты, которые мы создаем, должны бытьАвтономный, портативный, многоразовый.

Шаблоны

Когда у нас есть молекулярная организация организмов (Организм), мы можем использовать эти организмы для формирования наших шаблонов интерфейса. Здесь мы можем разорвать аналогию с химией и получить что-то более значимое для пользователя и конечного результата.

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

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

Страницы

Страницы — это конкретные экземпляры шаблонов. Здесь контент-заполнитель заменяется реальным, репрезентативным контентом, который точно описывает то, что в конечном итоге увидит пользователь.

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

Этот этап страницы очень важен, потому что именно здесь мы проверяем эффективность дизайн-системы. Видеть все в контексте — это этап, на котором мы можем вернуться и изменить наши молекулы, организмы и шаблоны.

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

Зачем использовать концепцию атомарного дизайна?

После того, как у нас будет простое понимание атомарного дизайна, мы можем спросить, зачем использовать атомарный дизайн?

На самом деле ответ очень прост: когда мы обычно проектируем приложение, даже если мы сознательно не используем этот способ мышления, мы всегда проектируем именно таким образом.

Atomic Design обеспечивает четкий подход к проектированию систем (основанный на концепции), который члены команды (разработчики, менеджеры по продукту, дизайнеры и т. д.) могут лучше понять, фактически увидев шаги, которые им предстоит выполнить. Концепция системы проектирования.

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

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

Стиль инкапсуляции "3" и Shadow DOM

Одним из наиболее важных аспектов разработки компонентов является инкапсуляция — возможность скрыть разметку и поведение от остального кода на странице, чтобы разные части не конфликтовали, а код оставался чистым.

И чтобы сделать это,Shadow DOM APIэто ключ. Он может прикрепить к элементу скрытый, независимый DOM.

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

Вот некоторые термины, относящиеся к Shadow DOM, которые нам необходимо знать:

Теневой хост: обычный узел DOM, к которому будет присоединен теневой DOM.
Теневое дерево: дерево DOM внутри Shadow DOM.
Граница теней: где заканчивается теневой DOM и где начинается обычный DOM.
Корень тени: корневой узел дерева теней.

Мы можем манипулировать теневым DOM так же, как и обычным DOM — например, добавлять дочерний узел, задавать свойства и добавлять собственные стили к узлу или ко всему теневому DOM.

В отличие от обычного DOM, элементы внутри Shadow DOM никогда не влияют на элементы вне его (за исключением:focus-within), что облегчает инкапсуляцию.

На самом деле Shadow DOM — это не совсем новая вещь, она уже давно используется браузерами. Браузеры используют его для инкапсуляции внутренней структуры элемента записи с кнопкой управления воспроизведением по умолчанию.<video>элемент например.

Все, что мы можем видеть, это<video>Фактически тег в своей Shadow DOM содержит ряд кнопок и других контроллеров. Стандарт Shadow DOM позволяет нашим собственным элементам (настраиваемым элементам) поддерживать набор Shadow DOM.

Этот подход также часто признается лучшим решением для инкапсуляции стилей компонентов.

Основное использование

Сначала мы можем использоватьElement.attachShadow()способ присоединения теневого корня к любому элементу.

Этот метод принимает в качестве параметра объект конфигурации, этот объект имеетmodeсвойство, значение которого может бытьopenилиclosed:

let shadow = elementRef.attachShadow({mode: 'open'});
let shadow = elementRef.attachShadow({mode: 'closed'});

open: Указывает, что Shadow DOM можно получить с помощью методов JavaScript на странице, таких как использованиеElement.shadowRootАтрибуты:

let myShadowDOM = myCustomElem.shadowRoot;

Но если мы прикрепим корень Shadow к пользовательскому элементу и поместимmodeУстановить какclosed, то мы не сможем получить Shadow DOM извне — вернется myCustomElem.shadowRootnull.

На самом деле браузер<video>Вот и все, он содержит недоступный Shadow DOM.

Если вы хотите прикрепить Shadow DOM к пользовательскому элементу, вы можете добавить следующую реализацию в конструктор пользовательского элемента (в настоящее время это наиболее практичное использование Shadow DOM):

let shadow = this.attachShadow({mode: 'open'});

Как только Shadow DOM присоединен к элементу, им можно манипулировать с помощью DOM API, как и обычным DOM.

var para = document.createElement('p');
shadow.appendChild(para);

Для подробного использования вы можете перейти непосредственно к MDN "Использовать теневой DOM".

«4» Расцвет TypeScript

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

Хотя TypeScript все еще имеет свои недостатки, он облегчает понимание кода (для студентов, привыкших писать объектно-ориентированный, он действительно прост для понимания, но для студентов, не знакомых с объектно-ориентированным, он немного неудобен). ). А TypeScript хорош для быстрой реализации и меньшего количества ошибок после производства.

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

Преимущества использования ТС

1. Код легче понять

Много раз, когда мы смотрим на функцию в фрагменте кода, мы задаем следующие вопросы:

Допустим ли этот параметр?
Какое значение вернет функция?
Какие внешние данные ему нужны?
Что он делает, чтобы превратить входные параметры в выходные возвращаемые значения?

В динамически типизированных языках часто трудно ответить на первые три вопроса.

Но в статически типизированном языке, таком как TypeScript, мы можем получить ответы на все вышеперечисленные вопросы прямо из IDE и компилятора.Больше не нужно просматривать всю кодовую базу, постоянно задавать вопросы нашим коллегам или рисковать ошибками в рабочей среде.

2. Более простой и быстрый код реализации

Когда я хочу реализовать новую функцию или компонент, наш рабочий процесс выглядит так:

Инициализируйте функцию компонента, установите параметры ее конструктора и напишите остальную часть кода.
Если ему нужны какие-то внешние или сложные данные (например, пользователи или статьи), то держите их в своей памяти и используйте в коде.
Поместите компонент в свое приложение и передайте ему реквизиты.
Затем пришло время протестировать компонент либо вручную, либо с помощью модульных тестов (здесь нам нужно убедиться, что он получает правильные реквизиты и что он работает).
Если где-то есть ошибка, самое время вернуться к нашему коду и попытаться найти, что пошло не так. Вернитесь к шагу 1.

Выше показан процесс разработки с использованием JavaScript, поэтому, если мы будем использовать TypeScript, он будет проще и эффективнее:

Инициализируйте функцию компонента, определите ее тип и реализуйте ее.
Если ему нужны какие-либо внешние или сложные данные, просто найдите их интерфейсы и повторно используйте их (полностью или частично).
Поместите компонент в свое приложение и передайте ему реквизиты.
Вот и все! (Если определения типов между вызывающим и вызываемым объектами правильно согласованы, все должно работать безупречно. Единственное, что сейчас нужно протестировать, — это фактическую бизнес-логику компонента.)

Это намного проще? Это также причина, по которой TypeScript имеет меньше шансов на низкоуровневые ошибки.

3. Код легко рефакторить

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

В TypeScript такой рефакторинг становится менее пугающим. Часто рефакторинг — это просто клик в IDE»Переименовать символ" команда.

В языке с динамической типизацией лучшая помощь, которую мы можем получить при одновременном рефакторинге нескольких файлов, — это использование RegExp для поиска и замены.

В статически типизированных языках поиск и замена больше не нужны. Используйте команды IDE, такие как «Найти все вхождения» и «Переименовать символ», чтобы увидеть все вхождения определенной функции, класса или свойства интерфейса объекта в вашем приложении.

Если мы хотим немного улучшить нашу систему сборки, переименовать компоненты, изменить объекты или удалить устаревшие свойства, нам не нужно беспокоиться о том, чтобы что-то сломать.TypeScript поможет нам найти использование этих связанных вещей после нашего рефакторинга, переименовать его и предупредит вас об ошибке компиляции, если после нашего рефакторинга возникнет несоответствие типов.

4. Меньше ошибок

Проработав много лет фронтенд-разработкой, мы все знаем, что если рядом с нами кто-то есть, когда мы ошибаемся в имени переменной, используем значение, которое не обязательно равно нулю, или передаем параметр типа объекта в функцию, которая принимает время типа массива, может напомнить нам, тогда мы можем сэкономить 50% времени устранения неполадок.

Я рад сообщить вам, что этот хороший друг — TypeScript.

Спасибо за это, теперь относительно сложно написать ошибку. Когда наш код упакован, мы можем примерно знать, что наш код может быть запущен.

5. Меньше шаблонных тестов

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

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

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

6. Помогите разработчикам писать лучший код

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

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

Затем TypeScript потребует от нас следовать этому правильному подходу к разработке.Это побуждает нас четко продумать класс интерфейса функций, которые мы хотим реализовать, прежде чем мы сядем за реализацию функций и кода.

Недостатки TypeScript

Сказав так много преимуществ TypeScript, давайте также поговорим о его недостатках.

1. Требуется этап компиляции

Если мы разработчики, разрабатывающие серверную часть node.js, использование TypeScript становится немного более громоздким. Потому что нам нужно сначала скомпилировать.tsфайл, а затем его можно запустить на Node.

Конечно, если у нас есть хороший набор инструментов для упаковки, эта проблема все еще может быть решена. Но это действительно принесет студентам проблемы с серверной частью Node.js, которых у них не было.

Впрочем, это не проблема для фронтенд-разработчиков. Из-за современного процесса разработки внешнего интерфейса мы будем передавать весь внешний код черезwebpack,gruntПодождите, пока инструмент упаковки скомпилирует наш код.

Так.tsФайл был автоматически скомпилирован для нас в этом процессе. Поэтому нам не нужно делать никаких дополнительных действий. В лучшем случае он также используется в упаковочных инструментах.npmУстановите еще один плагин компилятора.

2. Немного сложно настроить

Несомненно, это действительно так. Например, между простым Next.js и Next.js с использованием TypeScript, с TypeScript нам пришлось бы подключить сервер Node.js, веб-пакет и инструмент для тестирования jest.

Кроме того, когда нам нужно добавить библиотеку, такую как React, Redux, Styled-Components и т. Д., Мы должны прикрепить ихtypedefs. (Например@types/styled-components, но некоторые пакеты поставляются со своими собственными определениями типов TS)

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

Итак, вы хотите использовать TypeScript?

TypeScript хорош, в конце концов, при рефакторинге Vue 3 TypeScript был окончательно выбран в качестве основного языка для многих языков.

Итак, преимущества TypeScript очевидны. Но любой выбор технологии зависит от нашей собственной команды и компании. Если разработчиков 10, 9 из них не знают TypeScript, и никто из них не хочет учиться, или компания просто не может дать нашей команде время на изучение нового языка.

Тогда выбор смены языка — не лучший выбор.

Нет лучшей технологии, есть только лучшая технология на данный момент.

«5» веб-компонентов

Веб-компоненты — это будущее интерфейса.Зачем?

потому чтоЧистые веб-компоненты не зависят от каких-либо интерфейсных фреймворков, они могут работать без них или с любыми фреймворками.

потому чтоЭти компоненты гораздо меньше подвержены «усталости JavaScript» и поддерживаются большинством браузеров.

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

Эти компоненты предоставляют настраиваемые элементы, Javascript API (который позволяет нам определять новый тип html-разметки), html-шаблоны для определения макета и, конечно же, Shadow DOM (который по своей природе зависит от компонента).

Вот объяснение того, чтоJS усталость—— То есть, когда мы хотим изучить интерфейс, первым языком, с которым мы соприкасаемся, должен быть JavaScript, но как только мы начнем учиться, мы обнаружим, что вода действительно глубокая, и много других связанных знаний будет как прилив. В том числе интерфейсный фреймворк, Node.js, фреймворк пользовательского интерфейса, знание браузера, цепочка инструментов и т. д. Поначалу изучение интерфейса действительно очень утомительно.

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

Чтобы узнать больше о компонентизации, вы можете перейти к моей серии статей о компонентизации:

"Основы компонентизации внешнего интерфейса》
"Создание парсера компонентов с помощью JSX》

Эта серия все еще обновляется~

«6» Управление состоянием: прощай, Redux?

Будь то Redux от React или Vuex от Vue, на самом деле с этим монстром особенно сложно иметь дело. Хотя интерфейс становится все более модульным, управление глобальным состоянием в приложении становится все труднее контролировать. Но полезность и полезность State Management, таких как Redux и Vuex, делают их идеальным решением для многих команд.

Так можем ли мы попрощаться с Redux после 2020 года? Нет, не совсем.

Однако внутренние системы управления состоянием (такие как React hooks, Context-API и т. д.) начали появляться во фронтенд-фреймворках, и очень вероятно, что в будущем зависимость от управления состоянием вне фреймворка будет упразднена.

Как и Mobx, эти типы технологий вначале редко применялись, но из-за их компонентно-ориентированного и расширяемого характера только в 2020 году они стали более популярными, что позволило нам, разработчикам, исследовать больше вариантов.

Чтобы узнать больше, вы можете перейти кMobXофициальная документация.

MobX — это разрушенная войной библиотека, которая делает управление состоянием простым и расширяемым за счет прозрачного применения функционального реактивного программирования (TFRP). Философия MobX проста:

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

"7" ЭСМ КДН

Модули ES являются стандартом для использования модулей в браузерах, а модули ES стандартизированы ECMAScript. С модулями ES вы можете легко инкапсулировать функциональность в модули, которые можно использовать через CDN.

С выпуском Firefox 60 все основные браузеры будут поддерживать модули ES, и команда Node mteam усердно работает над добавлением поддержки модулей ES в Node.js. Кроме того, в ближайшие несколько лет будет доступна интеграция модуля WebAssembly ES.

«8» прогрессивных веб-приложений (PWA)

Прогрессивные веб-приложенияТакже известен какProgressive Web Apps- Он использует новейшие технологии для объединения веб-приложений и мобильных приложений. Думайте о PWA как о веб-сайте, который использует веб-технологии, но ведет себя и воспринимается как приложение (APP). Недавние разработки и усовершенствования в браузерах, средствах проверки доступности служб и API-интерфейсах Push позволяют пользователям устанавливать веб-приложения на настольные компьютеры, даже получать push-уведомления и работать в автономном режиме.

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

Конечно, у PWA все еще есть ограничения, и они не являются полной заменой нативных приложений. (Но действительно ли им это нужно?) В частности, будучи веб-страницами по своей природе, PWA не могут использовать большинство аппаратных функций, таких как NFC и Bluetooth. Однако не все приложения требуют этих функций.

Но PWA быстрее, проще и дешевле в разработке, поэтому они были тенденцией разработки в 2020 году и, безусловно, останутся в следующем году.

"9" WebAssembly (WASM)

JavaScript великолепен, но не лишен недостатков. JavaScript имеет проблемы с производительностью. Все языки синтаксического анализа сталкиваются с одной и той же проблемой, и WebAssembly — новейший способ ее решения.

Одна из лучших особенностей WebAssembly заключается в том, что это не совсем новый язык. Мы можем написать его на нашем любимом языке и скомпилировать в файл WASM для запуска в браузере. В настоящее время WebAsssembly поддерживает следующие языки: C/c++, Elixir, Python, Go, c#/.Net и Java.

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

Доступность "10" (a11y)

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

Доступность (или a11y) — мера «удобства» компьютерной системы для пользователя. Сайт должен хорошо работать на разных устройствах. но они должныПодходит для пользователей с различными «инвалидами» и «инвалидами». A11y обычно относится к доступности программного и аппаратного обеспечения.

В веб-разработке удобочитаемость может быть достигнута за счет:

Большой или настраиваемый размер шрифта
Дополнительные высококонтрастные страницы
Поддерживает синтез речи/преобразование текста в речь
Видео субтитры
Все голоса сопровождаются текстом
Голосовое распознавание навигации
текст на простом языке
Выделите важные части
Последовательная навигация и как можно меньше шагов
Упрощение авторизации (без ущерба для безопасности)
Навигация с помощью клавиатуры, а не мыши/трекпада
Семантический HTML

Название a11y происходит от того, что в слове «accessibility» 13 букв, поэтому между «a» и «y» 11 букв. Но если присмотреться, а11й выглядит как слово «союзник» — означающее друг, помощник, партнер.

«11» JavaScript Framework (фреймворки)

Наконец, давайте поговорим о некоторых интерфейсных фреймворках, на которых мы можем сосредоточиться в 2020 году.

Gatsby.js

Гэтсби - SSG, полное имяStatic Site Generator(генератор статических сайтов). Если мы думаем, что статические сайты ушли в прошлое, то это новая технологическая тенденция.

Одна из замечательных особенностей GatsbyJs заключается в том, что ему не требуется традиционный сервер; он работает с BYOC (Bring Your Own Content) для создания веб-сайтов на основе данных из CMS, CSV, API и файлов уценки. Gatsby также использует GraphQL, высококлассный язык запросов API, для построения слоя данных.

Освоение GatsbyJs требует от разработчиков знания React Native и/или GraphQL, но нам не нужны глубокие знания сразу — мы можем изучать Gatsby + React Native + GraphQL одновременно, т.е. изучать React и GraphQL, одновременно учась делать Gatsby .

Поскольку GatsbyJs является SSG, онОтлично подходит для разработки сайтов электронной коммерции. Этот генератор на основе React помогает нам загружать наш сайт за доли секунды. Мы говорим не о секундах, а о скорости загрузки в миллисекундах. Как известно любому владельцу бизнеса электронной коммерции, иногда задержка загрузки страницы может иметь большое значение для того, купит ли клиент продукт. Это относится и к другим типам веб-сайтов.

Vue 3 - One piece

существуетконец июня 2019, Эван Ю (Yuxi You) и команда vuejs выпустили RFC (Request For Comment) о новой итерации фреймворка Vue 3, который встретил довольно много негатива в сообществе. Но в итоге оказалось, что негативные отзывы не так сильно повлияли на Vue 3.

Некоторые веб-разработчики застряли, потому что Vue.js внезапно получил API-интерфейс компонента на основе функций (API-компонент) для замены API-интерфейса объекта, с которым большинство людей уже знакомы. Однако это не совсем так, новый API-интерфейс компонентов на основе функций дополняет порядок, который мы можем использовать вместе с традиционным объектным API, если захотим.

Новый синтаксис в API композиции Vue 3 имеет лучшую логику и способствует лучшей структуре кода. Некоторые разработчики даже говорят, что это немного сокращает код. А архитектуру Vue 3 можно использовать как плагин для Vue 2, просто используйте библиотеку Vue Composition.

затем в18 сентября 2020 года вышла официальная версия Vue 3., названный One Piece (многие студенты знают, что это название происходит отОдин кусочек).

Что нового в Vue 3

1. Производительность

Принцип двунаправленного соответствия определяется формулойObject.defineProptryПереход на ES6 на основеProxy, что делает его более детализированным и быстрым, устраняя существовавшее ранее предупреждение;
Переписан Vdom, чтобы преодолеть узкое место производительности Vdom;
Оптимизированная компиляция модуля;
Сделана более эффективная логика инициализации компонентов;

2. Поддержка Tree-Shaking

поддерживаетсяtree-shaking(Обрезка): Отрежьте ненужные вещи, такие как обрезка листьев, чтобы размер Vue 3 стал меньше.

потому чтоtree-shaking, модули в vue 3 будут входить в пакет только тогда, когда они нужны. После оптимизации размер пакета Vue 3 будет вдвое меньше исходного размера (всего 13 КБ). Даже если ввести все функции, пакет будет весить всего 23 КБ, что все равно меньше, чем у Vue 2.x.

При этом что-то вродеkeep-alive,transition,четноеv-forВсе может быть импортировано по требованию.

3. Composition API

фактическиComposition APIВдохновленReact Hooks, это больше чемmixinболее сильное присутствие. Это может улучшить повторное использование логики кода, тем самым добившись независимости от шаблонов; в то же время код функционального программирования более сжимаем.

Кроме того,ReactivityНезависимость в Vue 3 означает, что реактивные модули Vue 3 можно комбинировать с любым другим фреймворком.

4. Fragments

больше никаких ограниченийtemplateСуществует только один корневой узел. а такжеrenderФункции также поддерживают возвращаемые массивы, как в React.React.Fragments.

5. Улучшенная поддержка TypeScript

Vue 3 имеет лучший вывод типов, что делает поддержку TypeScript очень хорошей.

6. API пользовательского рендерера

Реализовано в виде DOMWebGLпрограммирование.

Svelte.js

Опубликовано Ричем Харрисом на JSConf EU 2019, Svelte (что означает «тонкий» на китайском языке) похож, но отличается от Vue. Точно так же это также компонентная архитектура. Однако, в отличие от Vue, SvelteКомпилятор компонентов запускается во время сборкииз. Это позволяет нам загружать только компоненты, необходимые для отображения текущего приложения. насНет необходимости использовать какой-либо виртуальный DOM(Виртуальный дом).

Svelte использует наборпростой синтаксис, что позволяет разработчикам получать доступ к переменным из разметки вместо использования оболочек состояния, которые отличаются для каждой платформы. Это делает Svelte почти идеальным фреймворком (то есть с ним очень легко начать работу) для новичков в веб-разработке. А для опытных разработчиков Svelte означает более быстрое написание кода, что приводит к повышению производительности веб-сайтов.

За год, прошедший с момента его выпуска, Svelte претерпел множество серьезных улучшений и обновлений, кульминацией которых стало то, что многие разработчики теперь называютОдин из самых простых и красивых фреймворков.

«12» CSS-фреймворк

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

Houdini CSS

Среди последних веб-трендов Houdini (названный в честь знаменитого фокусника Гарри Гудини) — очень уникальный фреймворк. По сути, Houdini — это набор API-интерфейсов, которые предоставляют разработчикам доступ к объектной модели CSS. Это означает, что если вам нужны стили, которых еще нет в CSS, нет необходимости изменять или переопределять их с помощью JavaScript. Используя напрямую архитектуру CSS Houdini, мы можем писать код, который обрабатывается как CSS и анализируется браузером для управления стилями.

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

Но есть одна проблема: не все основные браузеры поддерживают Houdini. Но пока нам остается только ждать, когда этот фреймворк будет поддерживаться всеми основными браузерами.

Bulma

Bulma – один из современных трендов индустрии. Он построен с расширением Sass, основанным на модуле CSS Flexible Box Layout или также известном как Flex Layout. Flexbox — это модуль, который часто используется для создания адаптивных веб-сайтов.

Bulma — это бесплатный CSS-фреймворк с открытым исходным кодом, который предоставляет коллекцию тем, созданных сообществом, которые следуют принципу написания как можно меньшего количества стиля. Его очень просто реализовать и настроить благодаря тому, что он создан с помощью Sass. Благодаря простоте кода Bulma CSS, веб-сайты, созданные с его помощью, частоСовместим со всеми браузерами с небольшими проблемами. В настоящее время это один из самых популярных CSS-фреймворков среди разработчиков, и, похоже, он останется таковым и в 2021 году.

Tailwind

Фреймворк Tailwind CSS существует уже некоторое время, но набрал обороты только в 2020 году.

Если мы посмотрим на диаграмму тенденций нагрева Google, мы увидим, что популярность Tailwind CSS продолжает расти.

Что делает Tailwind особенным, так это то, что это не набор инструментов пользовательского интерфейса, что отличает его от других фреймворков CSS. Он не имеет встроенных компонентов пользовательского интерфейса. Вместо этого Tailwind предоставляет набор виджетов (называемых виджетами на английском языке) для быстрой разработки компонентов пользовательского интерфейса или интерфейсов.Эти виджеты используют ряд инструментов класса, называемых атомарным CSS. Это означает, что мы можем создавать или разрабатывать компоненты пользовательского интерфейса с нуля в соответствии с нашими потребностями, не ограничиваясь темами и стилями, предоставляемыми другими средами CSS.

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

Суммировать

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

Многие студенты, работающие в сфере передовых технологий, во многих группах скажут: «Не обновляйте его, не придумывайте новый фреймворк, вы больше не сможете учиться~"

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

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

Когда дело доходит до этого, многие студенты спрашивают: «Так куда нам развиваться?»

Я думаю, что то, что сказал Учитель Юэин, может относиться к:

«Базовые и низкоуровневые знания, базовые и низкоуровневые знания, базовые и низкоуровневые знания».

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

Так что смысл в том, что нам нужно учиться и поддерживать способность быстро подбирать любой фреймворк и технологию. На самом деле, будь то Vue, React, Angular или Flutter. Разве нижний слой не весь JavaScript? Даже Node.js. А как быть с нижними слоями? Разве это не просто базовые знания компьютера? Если мы научимся досконально, то какие трюки вылезут в будущем, разве мы не можем выучить это за неделю? (Это может быть не в течение недели, но все же возможно быстро начать работу)

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

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