Unify dialog CRUD on shell action center.

[zhixzhan]

Is your feature request related to a problem? Please describe.

Part of #2312 , to support dialog-driven lg/lu resource maintains. this issue focus on dialog CRUD interface design.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[zhixzhan]

Dialog CRUD interface

By splitting dialog operation from one saveData method to servral part. Delta data on dialog change and change type can be traced, operations on related lg/lu resource would be possiable.

Current visual editor handler crud logic exist on file
'Composer/packages/extensions/visual-designer/src/utils/jsonTracker.ts'
we can leverage it and move some implementation to shell dialog action center.

Add

/**

• @param id, dialogId, 'addtodo'
• @param path, add JsonPath, 'triggers[0].actions[0]'
• @paran data, add data, ' {...} '
  */
  add(id, path, data) {}

Delete

/**

• @param id, dialogId, 'addtodo'
• @param path, add JsonPath, 'triggers[0].actions[0]'
  */
  delete(id, path) {}

Update

/**

• @param id, dialogId, 'addtodo'
• @param path, update JsonPath, 'triggers[0].actions[0].activity'
• @paran data, update data, '${Hi}'
  */

update(id, path, data) {}

Cut

/**

• @param from, {id, path}
• @param to, {id, path}
• Cut is kind move, move in one dialog or cross dialogs.
• One solution is implement it as delete + add.
  */

cut(from, to) {}

Copy

/**

• @param id
• @param path
• Copy is the pre-action of Paste.
• One solution is implement it as a get method, return raw data.
• if we take this solution, then the copy can have very wide entry, such as copy from a textEditor
• Anoter implementation is after get raw data, make some modify, let the paste data be valid. e.g dereference lg, re-generate uniq id.
  */

copy(id, path) {}

Paste

/**

• @param id
• @param path
• @param data
• Paste is the post-action of Copy.
• The limitation is the Paste data must be vaild, or can convert to be valid.
• if we do nothing on data, it act as an add
• if the incoming data is raw, we need dereference lg, re-generate uniq id
• if the incomming data contains helper property, let's say '_lu', '_lg' (maked up when a copy happen), we need cut this property.
  */

paste(id, path, data) {}

[zhixzhan]

if we keep use saveData, the delta data can be calculated by a JsonDiff method, it works for Add/Delete/Update

[boydc2014]

It's good to see, we can separate the dialog operation discussion from how dialog\lg\lu work together.

Talking about this specific issue, i get the benefits from have a fine grained dialog API, it would help clarify the change type, perhaps also make undo\redo easier, basically when your interface is more fine-grained, you will have more controls.

But like you also mentioned, it's not the only way to do that, a "json diff" is also a valid approach, and i will prefer "json diff", because of the benefits on architecture wide.

A fine-grained API for dialog operations is creating a new abstraction on top of json file, that all editors will work on. Which

• adds one more layer
• this layer's position is actually not clear, as you can see in your proposal, it's somewhere between json editing and bot editing
• even we somehow be able to find a good position between json<-> bot, this layer will not as stable or json or as bot, in which any editor will have to learn the concepts in this layer

All i listed above are what i called "architectural cost", and this type of cost is usually huge as it may look like now.

Think of if our editor and our shell is only talking through a "saveData" api (which we can expand the json to be a virtual json which joined dialog, lg, lu data).

If the protocol is simple as json editing, it will be very easy to replace or add an json editor than give direct manipulation to json.

I will probably start draft a design doc about how can unify all opertaion and side effects in one plain saveData api, you can continue refine the API design here to a state you feel comfortable, we can compare those two approach's pros and cons then.

[yeze322]

addressed part of this issue in #2718
Target: to provide a basic hook structure in R9, fix the Move behavior, LU behavior.
Need to improve (after our protocol settled):

1. side effects are invoked inline, we can follow up in R10
2. diff pattern
3. integrate with plugin system

[zhixzhan]

No longer valid since we handle qna/lu/lg separately