Конференция раннего чата по интерфейсу, новая отправная точка для развития интерфейса, была проведена совместно с Nuggets. Добавьте WeChat codingdreamer в эксклюзивную внутреннюю группу поддержки конференции и выиграйте на новой стартовой линии.
14-я сессия Front-end Growth and Promotion, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):
Текст выглядит следующим образом
Эта статья является третьей сессией - специальная сессия по созданию передней страницы, на которой лектор Луо Чен делится
Самостоятельное введение
Всем привет, меня зовут Луо Чен, я работаю в команде фронтенда компании Zhengcaiyun. Я окончил Чжэцзянский технологический университет в 2014 г. Я занимался .NET, писал Java и играл с базами данных. Я присоединился к семье фронтенда в 2015. Попутно стал свидетелем трансформации внешнего интерфейса из jQuery -> Angular -> React/Vue, испытал сокращение зарплаты, увольнения и испытал дочернюю компанию от создания до роспуска. В январе 2019 года он официально присоединился к Zhengcaiyun Co., Ltd., отвечая за работы по проектной инфраструктуре, связанной со строительной системой «Лубань», и является обычным инженером по набору текста.
Введение в тему системы сборки
Наша работа состоит в том, чтобы выполнить бизнес-требования.Обзор требований -> разработка -> тестирование -> онлайн, после запуска следующий раунд обзора требований -> разработка -> тестирование -> онлайн, 3 года, 5 лет, 10 лет спустя, чему вы научились? Обзор требований и разработка, это просто грубая сила. Итак, как элегантно решить бизнес-задачи, это касается темы, которую мы сегодня обсудим, — построения системы.
Деловая сцена
Технологии служат бизнесу, а построение технологий без бизнес-сценариев — хулиганство. Итак, давайте рассмотрим бизнес-сценарии построения системы:
Все вышеперечисленные сценарии реальны.В нашей компании спрос на веб-сайты портала очень велик, и многие веб-сайты портала очень похожи, а это означает, что до тех пор, пока визуальные спецификации непротиворечивы, интерфейсные компоненты, компоненты, модули, и даже шаблоны можно переиспользовать в больших количествах, кроме того, требования к операции малы по размеру и многочисленны по функциям, поэтому приоритет требований нельзя поднять естественным образом, а сама операция бессильна, что в итоге приведет к трафику и Для фронтенда повторяющиеся бизнес-потребности ничего не стоят для собственного роста, и постепенно они онемеют, все дальше и дальше удаляясь от поставленной на тот момент маленькой цели в 100 миллионов, превращаясь в безжалостную кодировочную машину.
бизнес-кейс
Ниже приведены все веб-сайты портала нашей компании.Топ-использование, навигация по шапке, позиции баннеров, категории продуктов, быстрый доступ и т. д. очень похожи, что также делает возможным повторное использование компонентов/модулей, а также строит систему. предпосылки существования.
Давайте рассмотрим другой пример. Область, выделенная красным прямоугольником на рисунке, — это модуль, в котором операция/продукт хочет вручную настроить данные. Он занимает почти 70 % содержимого страницы, поэтому можно предположить, что спрос, вызванный операция не может быть решена вовремя.как это больно в сердце.
Как выглядит система сборки
Наша система построения разделена на 3 основных функциональных модуля, 1 модуль данных и 1 модуль разрешений:
- Управление сайтом: Для удобства понимания можно рассматривать сайт как бизнес-классификацию, и каждому виду бизнеса соответствует сайт (классификация)
- Управление страницами: это основная функция конструкции, и конкретные функции можно увидеть в следующих четырех последовательных записях экрана (рис. 2 ~ рис. 5).
- Управление компонентами: на странице будет использоваться много компонентов, а разные страницы также будут использовать разные версии одного и того же компонента, что и означает управление компонентами.
- Data Kanban: как отразить, приносит ли система пользу и эффективно ли она используется, данные — это наиболее интуитивно понятный способ выражения.
- Разрешения: Разрешения делятся на две части: одна — это управление меню и разрешениями на операции, а другая — управление разрешениями на данные самой системы, что ограничивает видимый объем данных пользователей. Разрешения на данные особенно важны. любой может контролировать данные Редактирование очень опасно.
Диаграмма архитектуры
развертывать
Как развернуть систему? Некоторые друзья могут задаться вопросом: как можно развернуть эту Ниму с набором тестовых, предварительных и производственных сред. Вы правы только наполовину. Задайте всем вопрос: одинаковы ли страницы в разных средах? Это то же самое! Нет, это три страницы, которые выглядят одинаково! ! Тогда в это время у нас будет психологическое ожидание: только одна сборка страницы вступит в силу в трех средах. Как это сделать? Пусть сама система сборки будет развернута в среде, а лучше отдельный сервер для производственной среды (эксплуатация и обслуживание VPC на рисунке), а затем пусть этот сервер и остальные три бизнес-среды (тестовая/постановочная/профессиональная среда на слева) пройти , то есть сгенерировать страницы в среде, в которой построена система, а затем синхронизировать страницы с тремя бизнес-средами тестирования, предварительной версии и рабочей среды с помощью операции «публикации», чтобы наша ожидания могут быть оправданы.
Сказав так много выше, у каждого должно быть определенное впечатление о конструкции.Далее мы перейдем к теме этого обмена.
Как присвоить данные
JSON Schema
Когда дело доходит до данных, что приходит на ум? String, Number, Boolean, но сегодня я говорю о JSON, если быть точным, JSON Schema, поэтому, пожалуйста, подумайте над этим вопросом, является ли JSON Schema расширением JSON? Или ограничения JSON?
Ответ: ограничения. Фактически схема JSON представляет собой стандартизированные/нормализованные данные JSON. Как определяется схема JSON?Это то, что я объясню ниже. Начнем с простого примера.
Простой пример
Это очень распространенная форма формы, которая включает в себя поля ввода, раскрывающиеся списки и переключатели. Включенные элементы включают в себя: метку (цвет темы, номер учетной записи), заполнитель, тип (ввод, переключатель), данные (параметры раскрывающегося списка), ключ (имя поля), значение (значение поля). Все вышеперечисленное тесно связано с нашим определением схемы JSON.
Разберитесь с определениями атрибутов прямо сейчас и возьмите в качестве примера одно из раскрывающихся окон «цвет темы»:
Видно, что мы описываем конкретный элемент страницы фрагментом данных JSON, что и является эффектом, которого JSON Schema хочет добиться при построении.
Конечно, помимо определения элементов страницы, на странице также должны быть исходные данные, определение исходных данных гораздо проще, наверное, вот так:
тип расширения
Упомянутые выше вход и переключатель являются типами, определенными в соответствии со сценой. Мы также можем определить ввод как строку и переключатель как логическое значение. Это некоторые стандарты классификации, которые искусственно определяются сценой. Нет фиксированной формы выражения, пока так как вы гарантируете, что четко определены и просты для понимания. Кроме того, они чаще встречаются в обычном бизнесе:
Суммировать
В обычном процессе кодирования наиболее распространенными сложными типами, которые мы используем для определения данных, являются объекты (Object) и массивы (Array), а наиболее распространенными базовыми типами, составляющими объекты и массивы, являются String и Number, которые также могут быть типами расширения.
Мы так много говорили о схеме JSON, какое отношение она имеет к нашему бизнесу?
Деловая сцена
Возвращаясь к порталу, который мы только что сказали, отдел красного ящика — это часть операций/продуктов, которая хочет вручную настроить данные, поэтому вопрос в том, как они могут настроить данные и как конфигурация данных связана с нашим JSON. Схема??
Превратите бизнес в данные
Первый шаг, нам нужно преобразовать бизнес-сценарий в объективные данные, возьмем для примера небольшой его кусочек:
Слева на рисунке видно, что это ярлык для каждой провинции.Данные, соответствующие этой маленькой странице, показаны справа на рисунке:
Это очень распространено и просто, так что давайте перейдем ко второму шагу:
Превратите данные в определения
Выше мы упомянули множество определений типов, поэтому давайте сначала введем эти определения в наши бизнес-сценарии.
Я вижу эти данные, их тип данных — массив, который включает поля «название места», «значок», «ссылка», «описание». В качестве примера возьмем два поля имени места и значка:
- Название места: метка = название места, ключ = имя адреса, тип = строка;
- Значок: label = icon, key = icon, type = Select, data = { icon1: icon1, icon2: icon2 } .
Затем мы интегрируем их, чтобы получить результат справа на рисунке.
Нормализация определений в структуры
У нас уже есть возможность преобразовать модуль страницы в простой фрагмент JSON Schema.Аналогично мы можем сделать такое же преобразование для других модулей,будь то Object,Array или даже Two-Dimensional Array (двумерный массив). ) , а затем мы интегрируем каждый фрагмент схемы JSON.Конечно, определения недостаточно, на странице также должны быть данные, чтобы мы могли получить полную структуру схемы JSON:
визуализация
Наконец, в соответствии с вашими потребностями в визуализации вы можете написать функцию форматирования, которая соответствует дизайну вашей страницы, преобразовать эти данные схемы JSON и, наконец, отобразить их в форме, таблице или другом виде. На следующем рисунке показана страница конфигурации данных операции, которую я отрисовал после преобразования схемы JSON, для справки:
Суммировать
системы и расширения
Система построения является одной из фронтенд-инжиниринговых систем, мы можем строить системы построения разного масштаба в соответствии с разными бизнес-сценариями: на уровне компонентов, на уровне компонентов, на уровне шаблонов и даже на уровне приложений, с точки зрения построения сценариях, это может быть одна страница, а также может быть вся бизнес-ссылка, маркетинговая деятельность или даже вся промежуточная платформа; с точки зрения типов терминалов: это может быть ПК, H5, Native, апплет и т. д.; в порядке для обеспечения стабильности системы построения, качественного вывода, высокопроизводительных страниц, нам также необходима поддержка некоторых других возможностей: стратегия аварийного восстановления собственной системы, например, какое решение снизу-вверх нужно когда страница потеряна, как восстановить потерянные данные и как выполнить откат, если публикация не удалась; с уровня спецификации нам необходимо иметь полный набор строительных лесов, ограничений и жизненного цикла разработки нормативных компонентов; выходной уровень, мы должны убедиться, что производительность построенных и выходных страниц относительно значительна, поэтому она включает тестирование производительности страницы.Это еще одна полная система.Наша система тестирования производительности называется "Baice".Он соединяется с системой построения по горизонтали и дает возможность проверить работоспособность построения страниц. Когда дело доходит до страниц, данные, естественно, незаменимы: уровень BFF, совместное использование данных, агрегация запросов Ajax и т. д.
Все вышеперечисленное, будь то небольшая проблема или большое направление, до тех пор, пока вы понимаете болевые точки бизнеса, разрабатываете для нее общее возможное решение и реализуете его как систему обратной связи с бизнесом. Это качественный прорыв и большой шаг к продуктизации и интеллекту. Помните: один маленький шаг для вас и огромный скачок для бизнеса.
Приходите в чашу, мы нанимаем! ! !
Чтобы получить последнюю информацию о наборе команды, отсканируйте QR-код ниже, чтобы подписаться на общедоступную учетную запись WeChat «Zhengcai Cloud Front-end Team» и с нетерпением ждем вашего присоединения.
Резюме и саморекомендации, пожалуйста, отправьте наZooTeam@cai-inc.com