为拖放页面构建器选择哪种技术堆栈

Question

我们有多个用角度8内置的模板，其中包含滑块，产品列表以及一些带有图像，文本等的块。我需要创建一个拖放页面构建器，用户可以在其中选择模板，添加或删除任何元素以及编辑元素（样式），例如带有图像，标题，价格，按钮等的产品包装盒。我不知道如何进行技术堆叠，最终将模板保存为有角度的。几乎所有组件都显示从API加载的动态数据

• 画布是不可选项
• 我是否需要为组件在页面上的/元素位置创建一个json对象？
• 使用'ComponentFactoryResolver'动态创建组件会有所帮助吗？但是如何在实时编辑时以及保存角度构建后保存后绑定数据]
• 当在可放置区域中创建组件时，如何检测到它包含图像或文本，并且必须针对所选元素打开可编辑选项

任何帮助将不胜感激，我愿意进行任何讨论

Answer 1

根据您的描述，听起来您正在尝试构建仪表板系统或HTML WYSIWYG编辑器。这是一个相当广泛的体系结构问题，方法将非常取决于您的项目的需求/时间表等。我的第一个建议是进行搜索，以查看是否有任何工具已经在执行您想要的工作。即具有自定义功能的Ck编辑器是否可以满足您的需求？ ...

找不到一个，如果您需要自己动手，这是从我的经验中学到的一些教训。

或者创建一个使用本地HTML拖放的自定义指令，或者使用其中一个可以为您提供拖放的角度库（即材质拖放等...）
• 定义页面模型的外观。
• 充分利用Observable，以确保各个组件彼此之间保持隔离。却可以使用共享服务/可观察对象相互通信
• 将尽可能多的通用“属性”组合在一起，使它们成为基类的一部分。

定义页面模型的外观

您将如何存储用户所做的表示？在HTML，JSON中？

我们在内部使用基于JSON的HTML之间存在争论，但是最终我们得到了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;
}

您总是可以扩展您的界面，但是至少要花足够的时间来了解结构的外观。如果属性为done，则使用其自己的接口添加新组件变得轻而易举。在某些方面，使用HTML作为模型可能更有意义。
但是在使用此模型的情况下，“ TextComponent”可以期望向其提供符合“ Text”接口的数据。图片，表格等也一样...
这样，您就可以使用要使用的特定属性标记组件的html。即，对于TextComponent，您只需在HTML中使用"{{textContent}}，因为它是此Component接口的属性。
拖放
了解是否需要支持嵌套拖放？

根据项目的要求，找到具有可使用的拖放功能（材料拖放等...）的库

或创建一个实现HTML 5的本机拖放功能的指令

无论采用哪种方法，所有拖放操作都会发生'drop'事件。用户停止拖动时触发此事件。大多数拖放工具还允许您在“拖放”期间传递数据，以便“拖放”事件处理程序可以对其进行处理。

一旦定义了模型，就可以在拖动事件中为当前组件传递模型。在“ Drop”上，您可以检查所传递数据的widget.type。这将使您能够确定要处理的组件类型。

通过使用可观测对象来确保各个组件之间保持隔离

起初，当您只有少数几个组件时，很诱人的是允许您的各个组件直接相互交互。甚至可能会修改彼此的状态和/或数据。

但是，随着组件列表的增加，并且开始需要组件交互，您将很快发现问题。即在组件A中选择日期范围还需要更新在组件B中显示的数据

我们最终使用状态管理解决方案（NgRX），以帮助将状态与布局分离。由于我们是在过程中完成的，因此最初很痛苦，但是一旦完成，添加新组件的速度就大大加快了。仅供参考：您不需要使用NgRx，一项服务或共享的可观察性也可以跟踪各种组件的数据。使用RxJS BehaviorSubject允许后期订阅者获取当前值，例如

这允许处理诸如以下的场景>

组件B对组件A有依赖性
• 当对组件A进行更改，而不是对组件A进行遍历所有组件以查找依赖关系时，组件B订阅了存储并自行更改了组件A Changes的属性
• 这使我们能够将布局逻辑与应用程序中的业务逻辑分开。即，只要公司A更新了商店，如果存在要应用的业务逻辑，那么它将在显示组件之外进行处理。随着我们的组件列表不断增长，这有所帮助。
• 这使我们能够处理多组件事件。也就是说，如果用户按住shift键并选择了一个以上的组件，并且想要更改所有选定组件的背景颜色。在商店（NgRX）中更新了选定的背景颜色的Components css属性，并且该组件（通过订阅和更改检测）在屏幕上自动得到更新。

最终，这种方法使我们能够将组件的表示逻辑与数据逻辑分离。

这可能会变得非常复杂，具体取决于您需要的复杂程度。如果这是一个项目，您只需要快速，轻松地完成工作，那么当然可以做。但是，如果您有时间专用于此，我建议您花一些时间了解模型以及组件之间的相互作用。

我希望其中一些有用。祝你好运。