По вашему описанию это звучит так, как будто вы пытаетесь создать систему приборной панели или HTML WYSIWYG редактор. это довольно широкий архитектурный вопрос, и подходы будут очень зависеть от требований вашего проекта / сроков и т. д. c ... Моя первая рекомендация - сделать поиск, чтобы увидеть, есть ли какие-нибудь инструменты, которые уже делают то, что вы хотеть. т.е. Ck Editor с настройкой даст вам нужную вам? ...
не найдя его, если вам нужно свернуть свой, вот несколько уроков, извлеченных из моего опыта с этим.
- либо создайте пользовательскую директиву, которая использует native HTML drag and drop или используйте одну из библиотек angular, которая предоставляет вам возможность перетаскивания (т. е. drag & drop материала и т. д. c ...)
- Определите, какая у вас страница модель будет выглядеть следующим образом.
- Используйте Observables, чтобы гарантировать, что отдельные компоненты остаются изолированными друг от друга. тем не менее можно использовать общие службы / наблюдаемые для связи друг с другом
- , группировать как можно больше общих «свойств» и делать их частью вашего базового класса.
Определите, что ваш Модель страницы будет выглядеть как
- как вы будете хранить представление о том, что делает пользователь? в HTML, JSON?
- у нас был спор между использованием HTML над JSON внутри, но в итоге мы получили JSON, так как команда почувствовала, что он лучше подходит для них. но вы также можете использовать HTML как свою модель. например:
export interface Widget {
name: string;
type: string;
style: CSSProperties;
widgets?: Widget[];
}
export interface Text extends Widget {
textContent: string;
}
export interface Image extends Widget {
url: string;
}
export interface Table extends Widget {
source: string;
}
вы всегда можете расширить свои интерфейсы, но, по крайней мере, потратить достаточно времени на понимание того, как будет выглядеть структура. если готово свойство, добавление новых компонентов с их собственными интерфейсами становится проще простого. в некотором смысле, именно здесь использование HTML в качестве модели может иметь больше смысла.
, но с этой моделью вы, "TextComponent", можете ожидать, что ей будут предоставлены данные, соответствующие " Текстовый интерфейс. то же самое для изображения, таблицы и c ...
. Этим вы можете пометить html вашего компонента с указанным свойством c, которое вы будете использовать sh. т. е. в случае TextComponent вы просто используете "{{textContent}} в своем HTML, поскольку это свойство интерфейса для этого компонента.
Drag and Drop
- Понимаете, если вам нужно поддерживать вложенное перетаскивание?
- в зависимости от требований вашего проекта, найдите библиотеку, в которой есть функция перетаскивания, которую вы можете использовать (перетаскивание материала и т. Д. c ...)
- ИЛИ создайте директиву, которая реализует встроенную функциональность перетаскивания HTML 5
, какой бы подход вы ни использовали, все перетаскивания имеют Событие 'drop'. это событие срабатывает, когда пользователь прекращает перетаскивание. большинство инструментов перетаскивания также позволяют передавать данные во время «перетаскивания», даже если обработчик события «перетаскивания» может их обработать.
Как только вы определили свои модели, вы можете передать модель для текущего компонента в событии перетаскивания. и на «Drop» вы можете проверить widget.type из переданных данных. это позволит вам определить, с каким типом компонента вы имеете дело.
Используйте Observables, чтобы гарантировать, что отдельные компоненты остаются изолированными друг от друга
- it вначале будет заманчиво, когда у вас будет только несколько компонентов, позволить вашим различным компонентам напрямую взаимодействовать друг с другом. потенциально даже изменяя состояния и / или данные друг друга.
- Однако, по мере того, как ваш список компонентов растет, и у вас появляется потребность во взаимодействии компонентов, вы начнете очень быстро обнаруживать проблемы. т. е. при выборе диапазона дат в Компоненте A необходимо также обновить данные, отображаемые в Компоненте B
В итоге мы выбрали решение для управления состоянием (NgRX), чтобы помочь отделить состояние от макета. Поскольку мы сделали это на полпути, изначально это было больно, но как только это было сделано, добавление новых компонентов стало намного быстрее. К вашему сведению: вам не нужно использовать NgRx, службу или совместно используемую наблюдаемую программу, которая будет отслеживать данные ваших различных компонентов. Использование Rx JS BehaviorSubject, чтобы позволить поздним подписчикам получить текущее значение, например
, это позволило обрабатывать сценарии ios, такие как
- Компонент B зависит от Компонента A
- Когда в Компонент A вносится изменение, а не Компонент A, проходящий по всему компоненту для поиска зависимостей, Компонент B подписывается на хранилище и вносит изменения. Само по себе свойство компонента A Changes
- позволило нам отделить логику макета c от бизнес-логики c в приложении. т. е. всякий раз, когда хранилище обновляется компанией A, если применяется бизнес-логика c, она обрабатывается вне компонента отображения. это помогло, поскольку наш список компонентов продолжал расти.
- это позволило нам обрабатывать многокомпонентные события. т.е. если пользователь удерживает клавишу shift и выбирает более одного компонента, и хочет изменить цвет фона для всех выбранных компонентов. выбранное свойство Components css для цвета фона обновляется в хранилище (NgRX), а компонент (через подписки и обнаружение изменений) автоматически обновляется на экране.
в конечном итоге этот подход позволил нам Чтобы отделить логику представления c наших компонентов от логи данных c.
, это может быть очень сложно, в зависимости от того, насколько сложным он должен быть. если это проект, который вам просто нужен, чтобы быстро и грязно что-то сделать, то, конечно, делайте то, что должны. однако, если у вас есть время посвятить этому, я бы посоветовал потратить некоторое время на то, чтобы понять вашу модель, а также то, каким будет взаимодействие компонентов.
Надеюсь, что кое-что из этого было полезным. удачи.