Great project!

[Nongzhsh]

Is it possible that getting the activity definitions from the back-end, and building them in the front ?

[sfmskywalker]

Absolutely. The component allows you to define activity definitions in 3 ways:

1. Programmatically using JavaScript
2. Declaratively using the <wf-custom-activity> tags
3. As a web component built with StencilJS

Ultimately, an activity definition is a plain old JavaScript object that looks like this:

interface ActivityDefinition {
  type: string;
  displayName: string;
  description: string;
  category: string;
  properties: Array<ActivityPropertyDescriptor>;
  getOutcomes(activity: Activity): string[];
}

Your back-end could simply store these as JSON. However one thing I might not have thought through enough is the getOutcomes field, which expects a function value that computes the available outcomes. In most scenarios, this will simply return an array of strings, but in some scenarios, that array will be based on certain attributes of a given activity.

For example, the Fork activity allows the user to specify a comma-separated list of branches. The getOutcomes function for this activity will take these branch names and return them as an array of outcomes.

Could you maybe tell a little bit more about your use case on how you were thinking to store activity definitions in your back-end?

[sfmskywalker]

I gave this some more thought, and I think I found a neat solution to allow for data-driven activity definitions. I am planning on building a reference dashboard application with Orchard Core that would allow an admin to define activity definitions from the dashboard.

Ultimately, you will be able to define activity definitions using any of the following approaches:

1. Using ActivityManager, a singleton service that exposes addActivityDefinition, accepting a simple object describing the activity.
2. Using <wf-activity-definition>, exposing attributes to configure an activity definition.
3. Using StencilJS to define custom activities.

Options 2 and 3 are complete optional, as they all ultimately just add a simple activity definition in the form of an object (serializable from and to JSON) to the internal store.

I'll close this issue and create a new one to track progress on this work, but feel free to keep posting here if you want.