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

Председатель комитета по клиентскому интерфейсу Alibaba Group @ Circle Heart возлагает четыре надежды на будущее клиентского интерфейса: создание сервисов, бессерверные решения, интеллектуальные функции и IDE. Если хорошенько подумать, то воображаемое пространство «системы визуального построения» может идеально отразить эти аспекты.Где граница front-end и где ценность для бизнеса, можно было бы успокоиться и подумать об этом с точки зрения «визуального построения системы».

—— Некоторые люди говорят, что интерфейсная «система визуального конструирования» — это просто игрушка, созданная путем многократного сборки колес; некоторые люди говорят, что интерфейсная «система визуального конструирования» — это, по сути, перечисление компонентов, что бессмысленно. Одностороннее познание должно иметь свои причины, но мы могли бы также начать с более высокой точки зрения и применить его на практике.Может быть, вы обнаружите, что как FEer, мы можем делать больше вещей.

Обзор жанров технологий построения страниц и пасхальных яиц

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

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

В этом контексте особенно важна технология быстрого построения страниц.

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

• Байду H5
• iH5
• Кубическая платформа Zhuanzhuan
• Платформа настройки страницы еды на вынос Baidu: блоки
• Ctrip Лего Система
• Операционная платформа Renrendai
• Новая версия редактора WeChat
• Любань H5
• Алиюн Папилио
• MAKA
• Платформа Ма Лян
• grapes
• Визуальная загрузка макета
• Гражданская программа: конвейер-редактор
• Зарубежная гражданская программа: vvvebjs

Похожие статьи по техническому анализу:

• Инструменты построения визуализации страниц в прошлом и настоящем
• Технические моменты инструментов построения визуализации страниц
• Эволюция и техническая практика платформы управления событиями членства в QQ - эффективная работа с событиями
• Система строительных блоков для максимизации операционной системы
• Практика платформы автоматизации деятельности
• Визуальное построение интерфейсной разработки - Али Фейбинг понимает
• Уроки летающего льда для активных двигателей
• Система визуального построения для инженерной практики
• Как разработать масштабируемую онлайн-платформу для создания веб-страниц
• Любань H5 Автор: @小小鲁ban
• Устали писать страницы активности? Приходите и получите конструктор страниц!

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

По целевой аудитории можно выделить:

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

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

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

Когда технология редактора соответствует требованиям построения страницы

Вернемся к широкому и интересному вопросу: "В чем сложность фронтенд-разработки?".

В этом вопросе старый @ Yu Jiangshui упомянул два момента:

• Бизнес-логика сложна и изменчива
• Вертикальные решения не просты

Вот простая обработка и расширение его ответа, Первоначальный ответ можно сослаться на:Ответ Юй Цзяншуй.Следуя этому ходу мысли, давайте проанализируем,Вышеупомянутые страницы операционной деятельности - просто разработать эти страницы не очень сложно. Но для фронтенд-команды, если частые и изменчивые операционные требования вырываются наружу за короткий промежуток времени, это становится системной проблемой. Например, крайние случаи: для крупных рекламных акций Taobao Double Eleven и JD.com просто нагромождение людей и нагромождение времени — это капля в море. Так родилась платформа для создания страниц.

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

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

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

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

Давайте поговорим о «составном пользовательском бизнес-блоке», отличном от форматированного текста. Мы знаем, что окончательная построенная страница будет заполнена различными продуктами Sku, пользовательскими компонентами, пользовательскими карточками и другими блоками, и окончательный вывод этого контента должен быть понят и проанализирован средством визуализации C-стороны.

Проиллюстрируем это следующим рисунком:

Блок 1 — это традиционное форматированное текстовое содержимое, блок 2 — это составной настраиваемый бизнес-блок — карточка Sku, а блок 3 — еще один составной настраиваемый бизнес-блок — карточка пользователя. Таким образом, редактор больше не является одним редактором форматированного текста, а является многофункциональным редактором, конечный вывод которого представляет собой сложный тип JSON.

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

Гибкий и мощный редактор Markdown и новаторская попытка создания страниц

Я считаю, что сегодня нет программиста, который не знает Markdown, он очень дружелюбен к программистам или всем интернет-практикам. Проще говоря, Markdown — это легкий язык разметки, который позволяет нам писать документы в формате простого текста, который легко читать и писать. Сегодня многие веб-сайты широко используют Markdown для написания справочных документов или для отправки сообщений сообществу. Например: GitHub, Wikipedia, Jianshu, reddit и т. д.

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

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

• Расширения Markdown и пользовательские парсеры
• Улучшите взаимодействие с пользователем и создайте возможности генерации страниц

Подробно объясняются два аспекта.

Расширения Markdown и пользовательские парсеры

Исходный сценарий использования Markdown предназначен для документов и письма, а поддерживаемые им уценка и синтаксис не могут удовлетворить потребности всех сценариев. Поэтому в сообществе существует множество парсеров Markdown, целью которых является парсинг и расширение исходного контента Markdown. Среди множества парсеров наиболее известным являетсяmarked.js. Вот простой анализ принципа работы библиотеки marker.js, который поможет понять наш план реализации в будущем.

Говоря о разборе, это фактически классическая «принцип компиляции». Примените его для размета .js, как показано ниже:

Механизм работы очень прост: после того, как mark.js примет исходную текстовую строку, он создаст экземпляр лексера:

const lexer = new marked.Lexer()

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

const tokens = lexer.lex(content)

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

Далее, marker.js создает экземпляр синтаксического анализатора:

const parser = new marked.Parser()

Анализатор парсера получает токены и генерирует форматированный HTML-текст из токенов:

const html = parser.parse(tokens)

Конечно, это очень грубый процесс, но внимательные читатели могут получить представление: **Если вы хотите расширить синтаксис Markdown: мы можем изменить функцию лексера для генерации токенов, цель состоит в том, чтобы добавить наш собственный Markdown синтаксис для синтаксического анализа в новый тип токена Возможность; в то же время изменить функцию синтаксического анализа синтаксического анализатора, чтобы генерировать ожидаемые результаты в соответствии с новым типом токена. **Я не буду здесь вдаваться в подробности этого процесса.На самом деле решение, которое мы приняли, не разветвлялось, чтобы модифицировать код mark.js, а инкапсулировало парсер более высокого уровня, основанный на mark.js.

Улучшите взаимодействие с пользователем и создайте возможности генерации страниц

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

Например, введите:

<SkuCell>live@12345@rondStyle</SkuCell>

Это значит, что на страницу вставлена ​​Sku-карта с id 12345.

Несомненно, болезненно и неприемлемо позволять учащимся вручную вводить вышеуказанное грамматическое содержание. Поэтому мы разработали кнопку редактора Markdown: «Добавить ячейку Sku». После нажатия на кнопку появится диалоговое окно формы. Введите тип и идентификатор Sku оператором, а затем автоматически вставьте строку содержимого в положение курсора в редакторе Markdown:

<SkuCell>live@12345@rondStyle</SkuCell>

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

**Чтобы выполнить требование «что видишь, то и получаешь», нам необходимо анализировать источник ввода одновременно с вводом содержимого. **Процесс синтаксического анализа необходимо выполнять построчно:

• Если содержимое проанализированной текущей строки соответствует исходному синтаксису Markdown, используйте markdown для синтаксического анализа, получения проанализированного результата форматированного текста и поместите его в стек данных результата (стек данных здесь представляет собой массив результатов).
• Если синтаксический анализ содержимого текущей строки соответствует недавно расширенному синтаксису Markdown, используйте собственную функцию синтаксического анализатора (сейчас называемую feParse) для анализа строки (Реализация функции синтаксического анализатора представляет собой простой процесс компиляции сегментации слов.)
• Функция feParse получает расширенный новый синтаксический контент и использует различную вспомогательную обработку для разных идеографических методов, таких как обработка<SkuCell>live@12345@rondStyle</SkuCell>будет обрабатываться функцией skuCellHelper
• Функция skuCellHelper анализирует содержимое и получает результат сегментации слов (помеченный как formData):

type: 'live',
sku_id: 12345,
style: 'rondStyle'

• В соответствии с приведенными выше результатами сегментации слов запросите внутренний интерфейс для получения данных, соответствующих Sku, таких как оперативные данные с идентификатором 12345 (помечены как liveData):

author: 'live 作者名',
id: 12345,
created_date: '2019 10-12 20:34',
description: 'live 介绍',
duration: '20mins',
// ...

• Согласно приведенным выше двум типам данных: formData и liveData, форматированный текст skuRichText, соответствующий компоненту Sku, получается с использованием возможностей рендеринга на стороне сервера React:

const skuRichText = ReactDOMServer.renderToString(<SkuCell data={... formData, ... liveData} />)

• поместить skuRichText в стек результатов

Наконец, результат нашего построчного разбора:

result = [
	'第一行富文本内容'，
	'第二行 Sku 卡片对应的富文本内容'，
	// ...
]

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

Обобщая ключевые моменты для достижения «что видишь, то и получаешь»:

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

Следует отметить, что в реальной реализации:Операция находится в редакторе, и данные, сохраненные и отправленные на сервер, отличаются от приведенного выше результата.Это также массив: submitData, который используется для представления содержимого ввода операции. Для исходной грамматики Markdown мы напрямую используем соответствующий форматированный текст; для новой расширенной грамматики мы не используем соответствующий форматированный текст, а используем указанную выше структуру данных formData., который в конечном итоге отправляет что-то вроде:

submitData = [
	{
		type: 'richText',
		content: '<p>XXXX</p>'
	}，
	{
		type: 'sku',
		content: {
			type: 'live',
			sku_id: 12345,
			style: 'rondStyle'
		}
	}，
	// ...
]

** Это соображение предназначено для конечных пользователей C, чтобы получать последние данные Sku в режиме реального времени при запросе страницы. **Как понять данные Sku в реальном времени? При работе со страницей редактирования предположим, что информация о заголовке артикула вставлена ​​как «Заголовок 1». Еще через день информация о названии Sku стала «Title Two». Если мы сохраняем и используем расширенную текстовую информацию, используемую при оперативном редактировании, то страница C-стороны должна иметь «Заголовок 1», а не самый последний «Заголовок 2». Поэтому мы отправляем только идентификатор этого Sku. Когда пользователь на стороне C запрашивает страницу, серверная часть обращается через RPC/Http для получения последних данных, а компонент отображает содержимое на стороне сервера и, наконец, возвращает его интерфейсной части.

Весь процесс выглядит следующим образом:

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

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

• Вход - это то, что вы видите, что вы видите, это то, что вы получаете
• Поддержка гибкого расширения, может поддерживать все типы грамматик и произвольные компоненты на основе парсера
• Операция должна быть знакома только с основным синтаксисом Markdown, а расширенный синтаксис завершается нажатием кнопки

Финальные рендеры:

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

Больше, чем просто текстовый редактор

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

• Содержимое синтаксиса Markdown в редакторе по-прежнему неясно для работы.
• Эксплуатация по-прежнему требует определенных затрат на обучение и использование
• «То, что вы видите, это то, что вы получаете», полагаясь на синтаксический анализ и рендеринг в реальном времени.
• Для каждого нового компонента создайте новый синтаксис Markdown.

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

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

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

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

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

Не найдя подходящего решения, давайте сначала проанализируем с точки зрения спроса:

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

Подводя итог решений требований и проектирования, мы выбрали Proke.js в качестве основной структуры этого многофункционального редактора. Одно предложение достаточно, чтобы обобщить причины этого выбора: ** Prank.js - это не на самом деле богатый текстовый редактор. Это на самом деле инфраструктура для строительства богатого текстового контента и богатых текстовых редакторов. ** Как аналогия: если вы сравните богатый текстовый контент на картину, Proke.js обеспечивает только рисунок бумаги и кисти. Что касается того, как рисовать, разработчики имеют много свободы - (из статьи:Практика Draft.js в Zhihu).

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

Versatile переводится как «Универсальный; универсальный; универсальный; универсальный, универсальный». В настоящее время Versatile Editor полностью взял на себя все потребности редактирования фоновой системы. Его технический дизайн и система также очень понятны. Ниже мы в основном

• проектирование структуры данных
• Плагин дизайн системы
• Поддержка нескольких источников данных
• Дизайн пользовательского опыта
• Поддержка шаблонов страниц
• другие детали

Анализируются шесть аспектов.

Уникальная структура данных

** Идея дизайна структуры данных заключается в следующем: ** Используйте стек данных результатов (массив) для хранения каждого содержимого на уровне блока редактора Draft.js, и каждый элемент данных соответствует каждому элементу блока в последовательности. Эти блочные элементы делятся на две широкие категории: чисто форматированное текстовое содержимое и чистое содержимое настраиваемых компонентов. Для чисто форматированного содержимого мы повторно реализовали инструментальную функцию draftToHtml для анализа и преобразования неизменяемой структуры данных Draft.js в форматированный текст; для чисто настраиваемых компонентов мы извлекаем только минимальные данные восстановления компонента (например, артикул компонент Sku Cell).id и т.д.).

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

Конкретно объясните основное содержание ContentState на рисунке. contentState — это объект типа ContentState, который указывает, как хранить конкретное форматированное текстовое содержимое, включая текст, блочные элементы, встроенные стили, метаданные и т. д.

Здесь следует отметить одну вещь: в выходных данных мы отправляем как минимум два типа данных в серверное хранилище:

• rawContent
• renderTreeData

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

**RenderTreeData — это данные, отправленные после расчета и обработки. Его цель — сохранить их в базе данных, чтобы серверная часть могла вернуться на страницу C. Страница C-стороны, наконец, отображает полную страницу операции с помощью средства визуализации в соответствии с для рендерингаTreeData. **Как видно из рисунка выше, для генерации renderTreeData мы разработали метод generate на экземпляре RenderTreeGenerator:

new RenderTreeGenerator(
  contentState,
  getToHtmlOptions(contentState, this.props.editorConfig),
  this.customBlockModules
).generate()

Как показано на рисунке:

RenderTreeGenerator получает неизменяемый тип данных Draft.js contentState в качестве первого параметра, настраиваемый элемент конфигурации в качестве второго параметра, коллекцию компонентов React this.customBlockModules в качестве третьего параметра. this.customBlockModules — это массив, который содержит все блоки Имя пользовательского компонента React, когда тип пользовательского массива пропущенного блока необходимо активировать блок и генерирует структурированные данные.

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

generate() {
	this.output = []
	this.blocks = this.contentState.getBlocksAsArray()
	this.totalBlocks = this.blocks.length
	this.currentBlock = 0
	this.indentLevel = 0
	this.wrapperTag = null
	this.richTextArray = []
	this.finalOutput = []

	const processRichText = () => {
	  this.output.push({
	    type: 'RICHTEXT',
	    data: this.processRichText()
	  })
	}

	while (this.currentBlock < this.totalBlocks) {
	  const block = this.blocks[this.currentBlock]
	  let blockType = block.getType()
	  let type = blockType
	
	  // 对于 atomic 类型，如果当前类型在 this.customBlockModules 当中，则 export 出渲染数据以及当前 type
	  if (block.getEntityAt(0)) {
	    const entity = this.contentState.getEntity(block.getEntityAt(0))
	    type = entity.getType()
	
	    if (this.customBlockModules.has(type)) {
	      const entityData = entity.getData()
	
	      this.output.push({
	        type,
	        data: entityData
	      })
	
	      this.currentBlock += 1
	    } else {
	      // 不在 this.customBlockModules 当中，仍按照富文本导出
	      processRichText()
	    }
	  } else {
	    processRichText()
	  }
	}

	// 其他美化或清理工作，比如连续富文本区块的合并

	return this.finalOutput
}

Здесь есть два основных момента, которые отличаются от предыдущего редактора Markdown:

• Слушаем событие onBlur блока редактора, и когда это событие сработает, начинаем генерировать данные результата
• «То, что вы видите, это то, что вы получаете» — больше не нужно вручную анализировать реализацию рендеринга в режиме реального времени. Поскольку Draft.js — это редактор на основе React, мы можем визуализировать компонент React непосредственно в редакторе.

Как показано ниже:

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

Плагин, портативная плагина и конструкция компонента

Многофункциональность многофункционального редактора - это не просто разговоры, чтобы поддерживать огромные функциональные требования, и, учитывая удобство расширения сторонних функций, мы разработали хорошую систему плагинов для редактора. **В настоящее время в проекте используется 11 плагинов, они охватывают: **Вставка кода, вставка формулы, вставка ссылки, вставка ссылки, вставка видео, копирование и вставка, восстановление содержимого, вставка изображения, вставка ключевого стиля, вставка заметки и т. д. ** Проект также включает большое количество бизнес-компонентов, в том числе: ** компонент page meow, компонент диаграммы баннера, компонент карты Sku, различные компоненты кнопок, компоненты списка прокрутки, компоненты галереи изображений и т. д. Все компоненты и плагины, в принципе, доступны для сообщества и третьих лиц, а последующие планы требуют только пакета NPM для доступа к новой функции или новому типу пользовательского компонента. **Это также закладывает основу для последующего проектирования рынка компонентов и проектирования без/с малым кодом.

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

Поддержка нескольких источников данных

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

**Наше решение для этого: **После получения источника данных в редакторе, если сниффинг осуществляется в историческом формате Markdown, сначала используйте markdown.js для преобразования содержимого в этом формате Markdown в расширенный текстовый контент, а затем в соответствии с в форматированное текстовое содержимое Контент преобразуется в неизменяемые структуры данных, поддерживаемые Draft.js.

Подводя итог, поток обработки источника данных (rawContent) при инициализации редактора выглядит следующим образом:

Для данных rawContent, полученных редактором, мы используем функцию инструмента isDraftJson, чтобы определить, может ли rawContent быть проанализирован многофункциональным редактором с данными, поддерживаемыми Draft.js: если это так, это доказывает, что rawContent — это отправленные данные. с помощью нового многофункционального редактора. Содержимое редактора можно использовать напрямую и восстанавливать. Если параметр isDraftJson(rawContent) оценивается как ложный, это означает, что он не может быть проанализирован с помощью Draft.js. Он должен быть совместим с историческим синтаксисом Markdown. Форматированный текст анализируется с помощью marker.js, а затем передается в Draft. js для обработки, а форматированный текст создается с помощью Draft.js. Неизменяемые данные; в случае сбоя синтаксического анализа rawContent рассматривается непосредственно как содержимое текстовой области и заполняется непосредственно в редакторе.

На рисунке не показано, что происходит, если rawContent пуст (или отсутствует). На самом деле, если rawContent пуст, мы используем метод ContentState.createFromText('') для создания неизменяемых данных, инициализированных пустым содержимым.

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

Продолжайте улучшать пользовательский опыт

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

举一个例子：按照 Draft.js 的设计，每一个区块之间上下都会有个空行。 Как показано на рисунке:

Таким образом, при отправке содержимого редактора сгенерированные данные пользовательского блока будут содержать два пустых данных блока до и после, и в конечном итоге отображаемая страница также будет содержать две пустые строки, что напрямую влияет на эффект дизайна страницы. В сообществе есть много вопросов об этом дизайне, таких какEmpty line on adding atomic block.

** На самом деле, это сделано для гибкости добавления или удаления контента до и после пользовательских блоков. **Представьте, если бы мы добавили три пользовательских блока подряд: карточка артикула A, карточка артикула B, карточка артикула C. **Если между A, B, C нет пустой строки, то как мы можем вставить новую карту D между картой A и картой B? **Если между картами ABC есть пустая строка, пользователь может использовать курсор, чтобы найти пустую строку между AB и вставить карту D.В этом смысл автоматического наличия пустых строк до и после пользовательских блоков.

Некоторые разработчики могут подумать: мы можем сохранить эту пустую строку и можем ли мы автоматически удалить пустую строку, когда данные будут окончательно сгенерированы? На самом деле, когда мы получаем данные редактора Draft.js, мы не можем судить, является ли это ожидаемой пустой строкой, созданной собственным нажатием пользователя Enter, или пустой строкой до и после пользовательского блока, поэтому мы можем t напрямую грубить данные результата, удалять пустые строки.

Для улучшения взаимодействия с пользователем: Разработанный нами подключаемый модуль FocusPlugin элегантно решает проблему: по-прежнему нет пустой строки до и после каждого пользовательского блока, но с помощью подключаемого модуля FocusPlugin каждый пользовательский блок можно щелкнуть «Выбрать», или используйте клавиши вверх и вниз на клавиатуре для перемещения по выбору.После выбора вы можете напрямую нажать клавишу Enter, чтобы добавить пустую строку, или даже нажать клавишу удаления, чтобы удалить блок. Как показано на рисунке: Когда выбран пользовательский блок:

В конце концов, это решение на основе плагина FocusPlugin делает взаимодействие более плавным и естественным и позволяет добиться лучших результатов. Исходя из этого, мы можем очень плавно завершить изменение пользовательского блока: например, текущий выбранный блок — это карта Sku с идентификатором 1234. Если операцию необходимо заменить на карту Sku с идентификатором 5678, достаточно выделить текущий блок, выбрать Затем изменить содержимое id в появившейся справа области редактирования и после подтверждения завершить замену, как показано на рисунке:

На основе плагина FocusPlugin в качестве примера возьмите изменение текущего идентификатора карты Sku, после изменения идентификатора отправьте данные для получения нового идентификатора и позвоните после успешного получения данных.modifyAtomicBlock(entityKey, data)метод, триггерreplaceEntityData(editorState, entityKey, data)метод для обновления неизменяемых данных редактора, иhandleEditorStateChangeМетод также обновляет состояние, которое в конечном итоге отражается в представлении редактора.

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

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

• Вступительный экзамен в колледж
• Борьба с эпидемией - дань памяти ретроградам, ушедшим на передовую
• Люблю выбирать "соль"
• Страница занятий Ланг Ланга - обязательный мастер-класс для каждого ребенка, который любит музыкуи другой контент с высоким трафиком.

Поддержка шаблонов страниц

Содержимое редактора Daft.js полностью основано на состоянии данных.Он использует неизменяемую базу данных для операций обновления данных, придерживаясь чисто функциональных обновлений, поэтому он, естественно, поддерживает функцию «путешествия во времени (Отменить/Повторить)». С другой стороны, все данные также позволяют нам реализовать функцию «шаблон страницы» очень просто и гениально.

Мы можем разбить все шаблоны на несколько больших пользовательских блоков и создать данные, соответствующие этому активному шаблону: Например, для шаблона А: заголовок — это баннер заголовка, мы можем создать заполнитель в редакторе Изображение баннера, представленное рисунком; второй блок — список 10 лучших электронных книг, вы можете создать компонент Ranking в редакторе и заполнить его данными 10 электронных книг в любом месте и так далее. После отправки данных вы можете получить данные, описывающие этот шаблон страницы.

Когда оператор создает страницу и выбирает использовать «Шаблон таблицы лидеров A», мы используем предварительно созданные данные в качестве rawContent для инициализации редактора. После получения шаблона вы можете добавить и изменить операцию, чтобы быстро завершить создание страницы шаблона.

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

другие детали

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

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

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

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

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

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

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

Суммировать

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

В этой статье кратко излагаются все аспекты отраслевых исследований технологии «визуального построения страниц», а также систематизируются различные соответствующие технические блоги и аналитические статьи.Мы также представили прорыв и инновации, которые технология редактора и технология редактора могут привнести в «визуальное создание страницы».Исходя из этого, мы болееНачиная с самостоятельно разработанной «визуальной системы построения страниц» на уровне компании, представлена ​​история эволюции от стадии исследования до стадии зрелости.

На самом деле тема «Визуальная система построения страниц» далека от завершения:Мы изучаем больше возможностей в этом направлении: «микрокомпоненты/микроинтерфейсы», «возможности атрибуции страниц», «технология без/малого кода», «встраивание пользовательских компонентов и возможности A/B-трафика», «конструкция компонента во время выполнения и решения для рендеринга», даже «Serveless», «Cloud IDE»Ждать. Мы продолжим публиковать соответствующие статьи в будущем, пожалуйста, продолжайте обращать внимание на:технический блог, мы тожеШироко ищите таланты.

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

Удачного кодирования!