Методы EditorComponent::canBeParent(parent) и EditorComponent::canBeChild(child)

Fi1osof
9 июня 2019 г., 12:10

Методы EditorComponent::canBeParent(parent) и EditorComponent::canBeChild(child)

Всем привет!

Сегодня добавил очень полезные методы в компоненты фронт-редактора - canBeParent(parent) и canBeChild(child). Они предназначены для того, чтобы решать какие компоненты могут быть дочерними или родительскими для других. Это очень важная и полезная функция, так как не всегда отдельные компоненты могут быть вложенными для других. Для примера можно взять EditableObject. К нему прилагаются еще два отдельных компонента - DefaultView и EditableView (они описаны в статье про EditableObject). Изначально было рассчитано, что эти два компонента могут быть добавлены дочерними только непосредственно в EditableObject и больше никуда. В свою очередь в EditableObject могут быть добавлены и любые другие допустимые компоненты. Вот если не учитывать эти правила в визуальном редакторе и никак не ограничивать, то пользователь может какие угодно компоненты добавлять в какие угодно компоненты и в лучшем случае они или не будут работать (или работать неправильно), а в худшем случае возникнет фатальная ошибка. И вот эти методы как раз созданы для решения этой задачи. В DefaultView прописано (как и в EditableView):
canBeParent(parent) { return parent instanceof EditableObject && super.canBeParent(parent); }
То есть для этих компонентов родительскими могут быть только производные от EditableObject и никакие другие. При чем посмотрите внимательней на основные методы:
/** * В новом компоненте проверяет может ли компонент на странице стать родительским для него. */ canBeParent(parent) { /** * Может, если этот компонент может быть дочерним для целевого. */ return parent.canBeChild(this); } /** * В родительском компоненте проверяет может ли новый компонент стать дочерним. */ canBeChild(child) { return child ? true : false; }
canBeParent(parent) по умолчанию возвращает parent.canBeChild(this), то есть родителем может быть только тот компонент, для которого этот компонент может быть дочерним, то есть выполняется обоюдная проверка и для родительского компонента, и для дочернего по отношению к нему, что позволяет проверять как в родительском, так и в дочернем.

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

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

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

Вот как это выглядит: https://youtu.be/uSt9quBuC-o. Согласитесь, так гораздо удобней:)

UPD: Вот получился отличный кейс. На проекте есть различные формы подписок, у которых один и тот же контейнер. Контейнер оформлен в отдельный компонент (потому что если в нем что-то поменяется, должно поменяться для всех форм), а сами формы тоже оформлены в самостоятельные компоненты. При этом без контейнера эти формы не должны существовать, то есть добавить их можно только в такой контейнер. Но тут еще момент: в одном контейнере может находиться только одна форма. То есть если уже есть в нем форма, другую добавить нельзя. Вот как это выглядит в действии: https://youtu.be/2DBusXVlQR4

Добавить комментарий