Добавить Автора
предисловие
Когда дело доходит до визуализации страниц, многие студенты должны кое-что знать об этом. В этой отрасли есть много статей. Подробную информацию вы можете найти на нижнем портале. Эта статья начинается только сКак создать простой в использовании и расширяемый инструмент построения визуализации общего назначенияНачиная, изучая технические идеи и думая на практике, приглашаем обсудить друг с другом.
Что касается сопутствующих инструментов, то в отрасли существует множество продуктов с открытым исходным кодом и коммерческих продуктов, но трудно найти продукты общего назначения, отвечающие индивидуальным требованиям, по многим причинам:
- Разные пользователи предъявляют разные требования к компонентам с одинаковыми функциями в процессе эксплуатации и НИОКР.Они хотят простоты в эксплуатации, а НИОКР требуют вторичных возможностей разработки.
- В зависимости от сценария компоненты, используемые для настройки операции, и форма процесса настройки практически полностью различаются.
- Требования к дизайнеру разные, разные системы предъявляют разные требования к интерфейсу дизайнера, да и возможности панели тоже разные.
- У разработчиков разные предпочтения, кто-то предпочитает реактивную разработку, кто-то предпочитает vue, а использование библиотек компонентов отличается.
- ...
По некоторым из вышеперечисленных причин некоторые инструменты с открытым исходным кодом не могут быть хорошо реализованы в реальном бизнесе, и во многих случаях они могут быть разработаны только сами по себе или на основе вторичного преобразования открытого исходного кода.
Зачем пытаться быть универсальным инструментом построения визуализации?
В качестве инструмента повышения эффективности, если вы используете инструмент визуальной настройки только для удовлетворения вашего собственного бизнеса, с более широкой точки зрения, повысит ли он эффективность или снизит ее? Даже если команду и отдел можно обобщить, не обязательно всю компанию, и они столкнутся с «воспроизведенным колесом», на которое часто ссылается DISS, что в основном означает, что у них есть свои индивидуальные потребности, которые другие инструменты не могут встретить. Поэтому сложно сформировать единую визуальную составляющую конфигурации и спецификацию.
Хотя существует множество сценариев настройки и проблем с предпочтениями, с технической точки зрения есть много общего:
1. Требуется дизайнер для добавления, перетаскивания и настройки компонентов
2. Обеспечить возможности рендеринга
3. Связь между компонентами
4. Сцена формы может быть связана и т. д.
Предполагая, что дизайнер может быть настроен, визуальные компоненты, реализованные разными библиотеками компонентов, могут работать в разных дизайнерах через базовый набор схем илиDSLНормативные ограничения. Таким образом, проблема совместного использования компонентов может быть решена в значительной степени, что значительно снижает стоимость повторной разработки. Реализовать дизайнер и кастомные компоненты не сложно, сложно как добиться такой спецификации при поддержке расширений. Компоненты и дизайнеры — это просто реализации верхнего уровня.
Перефразируя слова дедушки Мао:
Дорога извилиста, будущее светло
Давайте взглянем на некоторые мысли о процессе попытки достичь
1. Дивизион
1. По сцене
Ниже приведены типичные сценарии настройки бизнес-визуализации:
| Сцены | Пользователь | Функции | использовать |
|---|---|---|---|
| Операционная деятельность | действующие одноклассники | Большое количество, сильная настройка, быстрый запуск | Общие действия по настройке, целевые страницы, лотерея и т. д. |
| Форма процесса | Реализация процесса | Высокие требования к формообразованию, внутренней и внешней связи форм, расчету формул и т. д. | Сотрудничайте с проектировщиками процессов для реализации бизнес-потоков |
| деловой отчет | продукты, операции и т. | Представлен формой запроса + таблицей с настраиваемыми столбцами и конфигурацией диаграммы | Демонстрация процессов и бизнес-результатов |
| Персонализированные страницы | обычный пользователь | Конфигурация должна быть проще, а требования к взаимодействию высоки. | Индивидуальные требования. Например, домашняя страница пользователя, пользовательское рабочее место и т. д. |
| средняя задняя страница | Фронтенд НИОКР | Необходимо иметь возможность расширения кода и высокий профессионализм | Фронтальная эффективность. Решение утомительной и повторяющейся разработки |
Конечно, это всего лишь несколько типичных сценариев визуальной настройки.Если возможности настройки достаточно сильны, возможно, исходя из этого, можно решить большую часть работы по разработке интерфейса.
2. По профессионализму пользователя
От разработки дизайнера до конечного использования участвуют пользователи в разных ролях:
- дизайнер-разработчик: Обеспечьте независимость дизайнера и разделение бизнеса, а также сосредоточьтесь на основных возможностях, универсальности и гибкости дизайнера.
- разработчик компонентов: Разработка общих компонентов и бизнес-компонентов. Сосредоточьтесь на полезности компонентов, настройке бизнеса и т. д.
- персонал: добавление, перетаскивание конфигурации, публикация и т. д. Обратите внимание на сложность конфигурации, гибкость и богатство компонентов.
- конечный пользователь: использовать последнюю опубликованную страницу. Обратите внимание на пользовательский опыт, быстро ли он открывается, нормальная ли функция и т. д.
С точки зрения сложности настройки средства визуализации обычно бывают следующих типов:
- NoCode: Как следует из названия, он вообще не требует возможностей кодирования, таких как конфигурация операционной деятельности, персонализированная домашняя страница пользователя, формы процессов, бизнес-отчеты и т. д. Компоненты часто необходимо настраивать в зависимости от конкретных сценариев.
- LowCode: большую часть интерфейса и функциональности можно настроить визуально, но для полной функциональности требуется небольшой объем кода. Например, пользовательские ассоциации форм, логика отправки форм и т. д.
- ProCode: требуются профессиональные возможности внешнего интерфейса, соответствующие традиционным исследованиям и разработкам. Он характеризуется длительным циклом взаимодействия и высокой стоимостью НИОКР.
Вы можете увидеть [Инструменты визуального построения и страницы]
Его можно найти,LowCode,NoCode,ProCodeОба достигают последней страницы (синяя).ProCodeСпособность самая сильная, она может реализовать все функции сцены, и в то же времяLowCode,NoCodeПлатформа или сам инструмент
3. По типичным взаимодействиям
- форма взаимодействия: Включает проверку формы, связывание, отправку, эхо значения и т. д.
- Показать страницу: пользовательский ввод требуется меньше или вообще не требуется, в основном для отображения, с некоторой индивидуальной конфигурацией. Например, бизнес-отчеты, персонализированная домашняя страница пользователя, операционная деятельность и т. д.
Инструменты визуальной настройки классифицируются выше по-разному, не обязательно точно, но в основном охватывая. Начиная с технологии, сочетая характеристики и требования, как реализовать такой общий инструмент — это вопрос, который стоит изучить.
2. Исследование проблемы
Ниже приведен список типичных проблем в трех аспектах: некоторые проблемы с формой, пользовательские обращения и общие возможности.
- проблема формы
- Проверка формы, исследование определения правила формы и настройка правил?
- Связывание формы, как связать поля в форме? Как связать внешнюю часть формы, когда значение в форме изменяется или вызывает событие? Как события вне формы связывают компоненты внутри формы?
- индивидуальный запрос
- Пользовательские компоненты, как настроить общий компонент? Как настроить компоненты контейнера? Если базовая конфигурация компонента не устраивает, следует ли ее переработать или расширить конфигурацию?
- Индивидуальный дизайнер, когда дизайнер встроен в бизнес-систему, какие открытые возможности должны быть у дизайнера для достижения недорогого и беспрепятственного подключения?
- Общая способность
- Интернационализация, интернационализация дизайнера, управление прогнозом перевода
- нестандартный стиль
- Одновременная настройка ПК и H5
Выше приведены лишь некоторые типичные проблемы, с которыми можно столкнуться при предоставлении возможностей в виде инструментов.Конечно, проблем гораздо больше, и обновление до платформы повлечет за собой еще больше проблем. ограниченное пространствоНижеследующее в основном исследует типичные проблемы формы сцены., и другие вопросы оставлены для последующего изучения.
1. Какие части должен иметь типовой компонент
ккарусельВзяв компоненты в качестве примера, пользователи с разным профессиональным уровнем хотят настроить разные свойства.
- дляNoCodeПользователям может потребоваться настроить только следующие свойства: количество изображений карусели, перетаскивание для добавления изображений, настройка ссылок для перехода к изображениям, ввод временного интервала карусели, выбор анимации переключения карусели и т. д.
- дляLowCodeДля пользователей, в дополнение к вышеуказанной конфигурации, вы также можете настроить интерфейс загрузки изображения, метод запроса, параметры запроса загрузки, сценарий преобразования возврата интерфейса и т. Д., Которые можно повторно использовать в большей степени, и сложность использования также повысился.
Хотя окончательный результат отображения тот же, но конфигурация отличается, можно ли в этом случае сделать его компонентом? Лично я думаю, что это возможно, например, разместить больше конфигураций атрибутов в расширенном или разрешить наследование компонентов.
Итак, какие части должен иметь компонент?
Из примера видно, что конечная часть дисплея требуется первой, часть конфигурации требуется второй, и элементы конфигурации должны быть определены. Часть, которая будет наконец показана здесь, называетсяView, в разделе конфигурации сказаноSetting, определите конфигурацию, называемуюSchema. Соотношение примерно такое:
Settingа такжеViewпройти черезSchemaсвязанные,Schemaсоздан какjsonДанные могут быть сохранены на сервере.Settingмодификация формыSchema,Schemaизменить влияниеViewРазнообразие.
2. Типичные проблемы в сценариях формы
1), проверка формы
Исследование определения правила формы и как настроить правила?
С точки зрения основной библиотеки компонентов поле ввода является более сложным, чем правила раскрывающегося списка, выбора радио, времени и других компонентов без учета правил проверки связи. Последнему нужно только сделать выбор, обычно добавляя обязательное правило, а первое требует помимо обязательной специальной проверки символов. как правилоВводимые пользователем компоненты имеют более сложные правила, чем компоненты, предоставляющие выбор опций..
Компоненты формы обычно имеют по крайней мере одно правило, типа требуется, конечно есть исключения, например компоненты переключателя (
switch),не важно какtrueещеfalseТребуется не имеет смысла
Поэтому в компонентеschemaможно определить наrequiredПоля обязательны для заполнения, если они указаны, например:
{
"name": "firstName",
"required": true,
"errorMessage": "这是必填项"
}
Для компонентов, которые требуют только обязательных правил, это определение не кажется проблемой. Однако во многих случаях компонент часто имеет несколько правил, которые действуют одновременно.Например, предполагается, что это поле является обязательным и можно настроить соответствующее сообщение об ошибке.В то же время длина строки должно быть ограничено, и может быть выдано соответствующее сообщение об ошибке, если оно слишком длинное или слишком короткое. Приведенное выше определение не очень удовлетворительно, поэтому вы можете обновить его:
{
"name": "firstName",
"rules": [
{ "required": true, "message": "这是必填项" },
{ "min": 3, "message": "最小长度不能小于3" },
{ "max": 10, "message": "最大长度不能超过10" }
]
}
Это выглядит намного понятнее и поддерживает несколько комбинаций правил одновременно. Это также проверка формы, используемая основными библиотеками компонентов пользовательского интерфейса.async-validator.rulesПоле должно быть таким же, какasync-validatorБудьте последовательны в использовании, чтобы вы могли использовать сторонние библиотеки для проверки правил,
Поскольку в форме в основном есть обязательное правило, вы можете согласитьсяrulesПоле первое правило обязательно, а остальные правила динамически добавляются конфигуратором по фактической ситуации.
Уведомлениеschema.rulesКаждый тип поля правила вasync-validatorНе тет-а-тет переписка, причина в том, что нашschemaбудетjsonФорма сохраняется на сервере или локально, поэтому некоторые специальные поля, такие как пользовательские функции проверки или регулярные выражения, должны быть преобразованы в соответствующие строки.
-
async-validatorОписание правила поля:
{
"type": "string",
"validator": (rule, value) => value === 'test',
"message": "请输入 test"
}
-
schema.rulesОписание единого правила
{
"type": "string",
"validator": "(rule, value) => value === 'test'",
"message": "请输入 test"
}
Поэтому нижний слой дизайнера должен предоставить модуль разбора правил формы (Rule). Это только реализация уровня правил.Для уровня конфигурации немного не хочется, чтобы персонал по настройке писал эти коды, и необходимо предоставить визуальный способ выбора или просто заполнения, как показано ниже:
Общие правила могут быть встроены в нижний слой конструктора. В реальном бизнесе часто используются настраиваемые сложные правила или асинхронная проверка и т. д., тогда:
Как настроить правила и расширить правила в соответствии с различными бизнес-сценариями?
Здесь от дизайнера требуется возможность расширения правил формы. Одна из возможностей — внедрить правила непосредственно через скрипты во время настройки, что применимо только к фронтенд-разработке. Во-вторых, одноклассники по разработке компонентов, заранее разработайте правила, затем разверните правила при создании конструктора и, наконец, выберите при настройке правил. Вторая реализация обсуждается здесь.
- Пример реализации правил номера мобильного телефона
// ./PhoneRule.js
export default class PhoneRule {
static get type () {
return 'phone'
}
static get name () {
return '手机号' // 用于可视化显示
}
constructor (rule = {}) {
const defaultRule = {
type: 'pattern',
pattern: '',
message: '手机号不正确'
}
this.origin = Object.assign({}, defaultRule, rule)
this.rule = {
type: 'pattern',
trigger: 'blur',
pattern: /^1[3-9]\d{9}$/g,
message: ''
}
this.update(this.origin)
}
update (rule) {
if (rule) {
this.rule.message = rule.message
Object.assign(this.origin, rule)
}
}
}
- Правила применения и примеры входящих правил
import { Rule } from 'epage-core'
import PhoneRule from './PhoneRule.js'
Rule.set({ PhoneRule })
// 应用规则：PhoneRule的type静态属性对应phone
helper.setValidators(widgets, { input: ['phone'] })
// 传入规则
new Epage({
Rule,
// ...
})
- окончательная конфигурация
inputкомпонент, вы можете видеть, что увеличениеТелефонный номерправило
2), формировать связь
Здесь сначала дайте личное понимание определения связи
Связь формы обычно относится кодно или несколько полей формыизстоимость или свойствопроисходитьРазнообразие, сделать другоеодно или несколько полей формыизстоимость или свойство Разнообразиевзаимодействие.
Вот несколько ключевых моментов:одно или несколько полей формы,стоимость или свойство,Разнообразие.
I. Пример связи
Например, это может быть любое из следующих отношений связи:
- Один к одному:
| No. | Поле удара | связь | стоимость | Затронутые поля | Атрибуты | |
|---|---|---|---|---|---|---|
| 1 | Город | принадлежать | Китай | --> | Школа | Факультативная школа |
- Один ко многим:
| No. | Поле удара | связь | стоимость | Затронутые поля | Атрибуты | |
|---|---|---|---|---|---|---|
| 1 | Город | принадлежать | Китай | --> | Школа | Факультативная школа |
| профессия | Необязательный майор |
- Многие к одному:
| No. | Поле удара | связь | стоимость | Затронутые поля | Атрибуты | |
|---|---|---|---|---|---|---|
| 1 | Город | принадлежать | Китай | --> | Школа | Факультативная школа |
| 2 | Количество учеников в школе | больше, чем | 10000 |
1а также2между может бытьа такжетакже может бытьилиОтношение
- Многие ко многим:
| No. | Поле удара | связь | стоимость | Затронутые поля | Атрибуты | |
|---|---|---|---|---|---|---|
| 1 | Город | принадлежать | Китай | --> | Школа | Факультативная школа |
| 2 | Количество учеников в школе | больше, чем | 10000 | профессия | Необязательный майор |
1а также2между может бытьа такжетакже может бытьилиОтношение
Уведомление:
- между несколькими полями удара может быть
且также может быть或связь - Воздействующие поля могут
等于,属于Отношение «равно-многие» и условие установления значения - Затронутые поля обычно не существуют между
且а также或Отношение - Многоуровневые ассоциации, такие как
aВоздействие на полеbполе,bВоздействие на полеcполя и т. д., настраиваемые с помощью нескольких двухуровневых ассоциаций
Вышеизложенное основано наПоле удараПерспективы рассматривают ассоциации. Конечно, вы также можетеЗатронутые поляЕсли рассматривать ассоциацию с точки зрения, в некоторых случаях она более интуитивно понятна, например:
{
"widget": "input",
"name": "c",
"hidden": "$a.hidden === false && $b.hiden === true"
}
Приведенное выше описание схемы будет иметь следующие недостатки:
1. сделатьhiddenбыло быbooleanтипа, но становится строковым выражением.
2. ЕслиhiddenПервоначально поле строкового типа, как отличить, является ли оно конкретным значением или выражением? Конечно, вы также можете расширить поле
3. Разбросана логика атрибутов разных полей, что неудобно для единого управления
В приведенном выше примере связи影响字段путем изменения表单值Для запуска логики связи. Значение здесь может быть等于отношения, также может быть包含,小于д., в зависимости от типа значения. Такие как:
-
логическийвозможно
等于,不等于 -
нитьвозможно
等于,不等于,包含,不包含 -
количествовозможно
等于,不等于,大于,小于,大于等于,小于不等于
Поскольку тип значения разных компонентов формы может быть разным, его можно определить как статическое свойство компонента.Schemaна, например:
class InputSchema extends FormSchema {}
Object.assign(InputSchema, {
logic: {
value: ['=', '!=', '<>', '><'] // [等于, 不等于, 包含, 不包含]
}
})
если поставитьполя формыВ качестве объекта значение формы (value) в качестве специального атрибута, а также некоторых общих атрибутов, таких как скрытый, отключенный и т. д., вы обнаружите, что связь является логической связью между атрибутами. как контролироватьvalueКак насчет изменений и общих изменений атрибутов?
valueОсновные причины, по которым он считается особым атрибутом:Изменение этого свойства вызовет
onchangeмероприятие. вести перепискуhidden,disabledДругих общих атрибутов нет, по идее, должно бытьonhidden,ondisabledсоответствующее событие.
если поставитьполя формыВсе свойства определены как реактивные, и легко получить уведомление об изменении любого свойства. Вы также можете самостоятельно реализовать метод публикации подписки, чтобы изменить свойства формы.
- Один из них заключается в том, что после того, как свойства полей формы удовлетворяют определенным условиям, свойства других полей формы связываются с изменением, которое вызывается здесь.
值联动 - Другой заключается в том, что событие происходит в компоненте формы (например,
onchange), связанный с другими изменениями атрибутов поля формы, вызываемыми здесь事件联动
В какой-то степени оба метода могут разрешить связь одних и тех же функций, например, если значение компонента А изменяется, можно также считать, что компонент А имеет место.onchangeмероприятие
ii. Реализация связи
разработать следующиеepageРазбор некоторых реализаций на примере (логика ассоциации многие-к-одному, многие-ко-многим еще не реализована)
Во-первых, логическое определение
определениеschemaЛогическая структура, которую следует сохранить. Конкретная логика задается в одном компонентеSchemaверхний или крайнийSchemaЭто может быть определено здесь в едином месте для легкого управления.
основное определениеВлияющие компонентыа такжеЗатронутые компоненты: включая тип связи, значение затронутого компонента формы соответствует определенным условиям, какие атрибуты затронутого компонента формы связаны, какие события инициируются затронутой формой и т. д.
{
// schema 其他字段
logics: [
{
"key": "kB1mKTnek", // 影响组件key
"type": "value", // 关联类型，值联动 或 事件联动
"action": "=", // 值联动是相等关系，这里定义不同符号，应该提供符号解析能力
"value": "show", // 具体值
"effects": [ // 被影响组件列表
{
"key": "kASJAJwRB", // 被影响组件key
"properties": [
{ "key": "hidden", "value": true }, // 被影响组件隐藏
{ "key": "disabled", "value": true } // 被影响组件禁用，还应可以为其他属性
]
}
]
}
]
}
Во-вторых, логический анализ
- логическое управление
На основании вышеприведенного анализа следует值逻辑а также事件逻辑. Вступает в силу при рендеринге или предварительном просмотре
import EventLogic from './EventLogic'
import ValueLogic from './ValueLogic'
class Logic {
// 检查值逻辑配置是否合法，是否有重复逻辑等
// 返回 { patches, scripts }，对应比较结果和可能的自定义脚本
diffValueLogics(){}
// 同上
diffEventLogics(){}
// 根据以上比较结果，最终修改组件Schema属性
applyPatches(){}
// 检查被影响组件是否有效等
checkEffect(){}
}
- Пример реализации части логики значений
для вышеуказанного сгенерированногоЛогикаразобрать. Если значение связаноactionСуществует множество отношений сравнения между полями (=(равный),!=(не равно),>(больше, чем),<(меньше, чем),<>(в том числе) и др.), с=Например:
class ValueLogic{
constructor () {
this.map = {
'=': {
key: '=',
value: '等于',
// left、right为用户输入值都为字符串，valueType为应该的数据类型
// 但左右值类型与valueType不一致时，根据情况进行转换后比较
validator: (left, right, { valueType }) => {
const booleanMap = { true: true, false: false }
let leftValue = left
let rightValue = right
if (valueType === 'number') {
leftValue = parseFloat(left)
rightValue = parseFloat(right)
return (isNaN(leftValue) || isNaN(leftValue)) ? false : leftValue === rightValue
} else if (valueType === 'boolean') {
if (right in booleanMap) {
rightValue = booleanMap[right]
}
}
return leftValue === rightValue
}
},
// ...
}
}
}
Чтобы сделать конструктор более общим,Определение и анализ логических отношенийРасширения разработчика компонентов также должны поддерживаться.
Некоторые реализации логики конкретных значений или логики событий могут ссылаться наepage#Logic
3. Резюме
Сделать инструмент визуальной настройки несложно, но непросто обеспечить универсальность и масштабируемость, а также вместе построить единый стандарт. Единый наборSchemaилиDSL, разные разработчики могут договориться и могут быть расширены и настроены в соответствии с потребностями, чтобы быстро достичь целей бизнеса.
портал:
Об авторской команде
EFE, фронтенд-команда Didi Efficiency Platform, вдохновлена организационной миссией постоянного повышения организационной эффективности с помощью технологий и стремится создать фронтенд-технический коллектив с передовыми технологиями, который активно участвует в мониторинге производительности, качестве мониторинг, настройка с минимальным кодом, совместная работа с документами, микроинтерфейс, веб-IDE и т. д. Во многих областях направление технологии широкое, а пространство для исследований и роста огромно.
Мы команда, полная страсти и мечтаний, с нетерпением ждем вашего присоединения. Заинтересованные могут обращатьсяdumingtan@didiglobal.com