Практика построения логики в построении фронтальной визуализации

История и ценность

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

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

Эта статья будет общаться с вами через дизайн и деловую практику логической организации и визуализации.

Оркестратор

Основные понятия

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

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

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

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

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

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

общий дизайн

дизайн компонентов

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

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

Тип компонента

В зависимости от того, содержат ли компоненты логику, компоненты делятся на две категории: базовые компоненты и бизнес-компоненты. Схема дерева выше.

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

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

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

Оценка бизнес-компонентов будет сложной.Согласно спецификации дизайна компонента, можно определить, что при создании компонента существует несколько выходных результатов.Результат> 1, а также будут выходные выходные данные в фиксированном формате схемы. Например, оценка того, вошел ли пользователь в систему, делится на два случая: вошел в систему и не вошел в систему; если оценка бизнес-элемента не равна ни 1, ни 0, вывод также может быть a, b, c, д... многоцелевая ориентация. Таким образом, общий сервисный элемент имеет один входной узел, N выходных узлов, а его форма выполнена в виде ромба.

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

Регистрация компонентов

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

G6.registerNode(
  'diamond',
  {
    draw(cfg: Cfg, group: GGroup) {
      const size = [94, 64]; // 转换成 [width, height] 的模式
      const width = size[0];
      const height = size[1];
      // svg 自定义主体形状
      const path = [
        ['M', 0, 0 - height / 2], // 上部顶点
        ['L', width / 2, 0], // 右侧顶点
        ['L', 0, height / 2], // 下部顶点
        ['L', -width / 2, 0], // 左侧顶点
        ['Z'], // 封闭
      ];
      ...
    },
    afterDraw(cfg: Cfg, group: GGroup) {
      const size = [100, 64];
      const width = size[0];
      const height = size[1];
      // 分支描述信息
      addDesc(cfg, group, width, height, cfg.outLine);
      // 分支线
      addLine(group, width, height, cfg.outLine);
      // 连接锚点（小圆点）
      addNode(group, width, height, cfg.outLine, cfg.showNode);
    },
    ...
  },
  'base-node',
);

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

const addLine = (group, width, height, outLine) => {
  group.addShape('path', {
    attrs: {
      path: [
        ['M', -width / 2 * (outLine - 1), height + 3],
        ['L', width / 2 * (outLine - 1), height + 3],
        ['Z']
      ],
      ...edgeStyle
    },
    draggable: true,
  });
}

Узел элемента делится на входной узел и группу выходных узлов, а положение выходного узла по-прежнему определяется контуром

const addNode = (group, width, height, outLine, isShow) => {
  // x坐标
  let xPosition = i => {
    return -width / 2 * (outLine - 1) + width * i;
  }
  outLine && new Array(outLine).fill(0).forEach((d, i) => {
    group.addShape('circle', {
      attrs: {
        x: xPosition(i),
        y: height + 4,
        r: 4.5,
        ...dotStyle
      },
      name: `circle-shape-${i + 1}`
    });
  })
}

Создание компонентов

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

index.js — основной файл логики функции компонента, функция обычно имеет входные параметры и позволяет пользователям гибко настраивать. Файл input.json определен как стандартный протокол Schema для базовой информации о конфигурации функций.Это содержимое может отображаться как форма на стороне платформы, чтобы пользователи могли настраивать базовую информацию, и передаваться в соответствующую функцию в качестве параметра полезной нагрузки во время логики. процесс исполнения.

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

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

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

Если проверить компонент входа в систему, он вернет два случая входа в систему и не входа в систему, затем основная функция вызовет соответствующий API и сделает выбор между двумя случаями возврата после суждения. Возвращаемая информационная ветвь равна 0, что является незарегистрированным статусом возврата первого элемента массива, соответствующего файлу ветвей; ветвь равна 1, что является состоянием входа в систему второго элемента массива, соответствующего файлу ветвей, а возвращаемые данные также соответствуют информации о входе в систему. Длина массива файла ответвления — это количество результатов вывода компонента, и содержимое массива также семантически соответствует. Это проектирование общей структуры компонента и соответствующая спецификация входа в разработку, согласно которой разработчик может создать новый компонент соответствующего типа.

Мы также предоставляем [Visual Building Form Designer] для данных стандартного протокола схемы входных и выходных файлов, чтобы разработчики могли быстро создавать соответствующий контент.

Визуальное построение на основе формы-рендера

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

Студенты технических специальностей могут создать форму конфигурации путем визуального перетаскивания в соответствии с функциональными требованиями; нажмите «Экспортировать схему», чтобы экспортировать стандартную информацию о протоколе схемы json, которая является источником протокола InputSchema для базовой информации о конфигурации в процессе регистрации компонента, а также стандартный протокол для вывода данных outputSchema Information Sources.

Предоставляет встроенный рынок компонентов

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

логическое расположение

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

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

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

бизнес-лендинг

Комбинированный дизайн пользовательского интерфейса и логического макета

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

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

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

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

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

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

До и после - в чем преимущества

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

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

Такое преимущество в том, что пользовательский интерфейс, частая смена пользовательского интерфейса, логика не будут слишком зависеть от развития технологий, технического выпуска, будут переработаны в многосимвольную легкую работу, и мы мультиплексировали от модулей, опускаясь до более Компоненты с мелким размером частиц используются повторно, что освобождает от «движущейся кирпичной» работы персонала НИОКР. Доказано, что традиционная разработка исходного кода, вероятно, требуется для оценки 2 дней с момента получения запроса до запуска, а решение в сочетании с логикой пользовательского интерфейса требуется только в течение 2 часов. Реально достигнутый эффект затрат. И самым большим преимуществом является достижение разделения логики и пользовательского интерфейса.

Когда черновик дизайна пользовательского интерфейса изменяется, сравнение процесса «до» и «после»:

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

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

Структурная схема

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

Логическая оркестровка разделена на три части: Orchestrator, DSL и Runtime.

Аранжировщик основан на синтаксическом анализе схемы и механизме рисования G6 в сочетании с определением и регистрацией типов компонентов для рисования четырех компонентов с различными формами и функциями для построения холста; компоненты разрабатываются разработчиками, и компонентами можно управлять на странице управления компонентами. . Холст включает в себя функции панели инструментов, такие как масштабирование и отмена.В процессе создания пользователя мы обеспечиваем интеллектуальное выравнивание, проверку спецификаций, автоматическое исправление ошибок, онлайн-тестирование и другие возможности с помощью технических средств, что позволяет пользователям создавать логику более плавно и стандартизированно.
Преобразователь DSL Преобразование всей информации холста в json и предоставление ее бизнес-стороне
Отправной точкой логики на стороне бизнес-платформы является логика активного триггера и логика пассивного триггера. После срабатывания логики API, предоставляемый средой выполнения, зарегистрирует компоненты и начнет выполнение. Продукты данных, соответствующие выполнению каждого компонента. будут переданы бизнесу через контекст.Данные, соответствующие полю привязки, изменяют состояние, что приводит к изменению локального пользовательского интерфейса и общего состояния модуля. После выполнения действия поток переходит к следующему действию, и так до тех пор, пока логика не завершится.

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

Суммировать

Логическое расположение сделало прорыв в следующих трех аспектах:

Логика может быть повторно использована: избегать дублирования разработки кода студентами-исследователями, экономить трудозатраты, сокращать затраты и повышать эффективность, а также снижать затраты на изменение спроса;

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

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

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