Handle actions in the MessageCanvas

[lyjeileen]

When designing the MessageCanvas component to handle actions such as copy, delete, or edit, it's crucial to account for the diverse message formats it may render. Each message format may require different actions, and thus, a flexible configuration approach is necessary.

One approach is to define a messageConfig object, which maps each message format to specific actions and their corresponding properties. For instance:

const messageConfig = {
  text: {
    copy: 'text',
  },
  codeSnippet: {
    copy: 'code',
  },
  image: {
    copy: 'url',
  },
  // Add other message formats and their corresponding actions here...
};

We could also store the messageConfig object in a separate JSON file or retrieve it from an API request, providing more flexibility and easier maintenance. In this configuration, the keys represent different message formats (e.g., text, codeSnippet, image). Each format is associated with an object specifying actions and their properties. For the copy action, the property specifies what data to copy. It could be a single string, an array of strings representing multiple data properties to combine, or an objects containing both data properties and their corresponding tooltip labels.

For example, if we want to copy both the URL and description of an image, along with a custom tooltip label, the configuration could look like this:

image: {
  copy:  { label: 'Copy Image Info', props: ['url', 'description'] } ,
},

This configuration specifies a custom tooltip label ('Copy Image Info') and identifies the properties ('url' and 'description') to be copied.

Alternatively, if a tooltip label is unnecessary but we still want to copy multiple properties, a simpler configuration suffices:

image: {
  copy: ['url', 'description'] ,
},

The messageConfig object can accommodate other actions such as editing. For editing functions, we can specify the editable properties or set the value to false if editing is not allowed. For instance:

image: {
  edit: 'description',
},

By adopting such a configurable approach, we can maintain code clarity, extendibility, and versatility in handling diverse message formats and their associated actions. Additionally, this approach facilitates future enhancements or modifications to action handling without the need for extensive code changes.

Another option is having a function (if/else statement) for each action to decide what should be changed.

We welcome suggestions and feedback from the community on how to handle actions effectively.

[Shiti]

I have been thinking about this. Now that the PR with interfaces/types for data has been merged, it might make it easier to discuss this. Most common actions on messages would be constant and do not change irrespective of the DataFormat. For example, deleting a message, forwarding a message, replying to a message, etc.

In case of copy, what if instead of having a generic copy action, we something more specific like - copy text and copy link for files like images and media ?

Also, what are the other actions do you anticipate which may vary by DataFormat ?

[lyjeileen]

@Shiti For copy, do you mean we could use if/else statement to copy different things based on DataFormat? I am also wondering which kind of data people can copy for formats like table, chart and calendar? The original datasets?

Other than copy, edit function would also vary based on DataFormat. Some formats might not have editing feature e.g. video and image. If we want to support editing for formats like table, chart and calendar, we need to add specific logic for it.

[Shiti]

I was thinking that the copy function need not be supported for every type of DataFormat, we should just support something simple like copy the value of the text field.

In case of tables, charts etc, copy does not add any value. The components could have their own supported features/settings for example a table component may have option to export as CSV or as excel file etc. Similarly, for the chart, it could be exported as an image or CSV, etc.

On second thought, maybe we shouldn't provide copy through MessageCanvas actions. Users can still select all/part of a text message and copy it.

Since edit would only be applicable to data/input added by user, I was thinking we only need to support it for text content.

The navigator.clipboard API is a recent addition to the specification and may not be fully implemented in all browsers.

[lyjeileen]

So do we still want to provide copy function through MessageCanvas actions?

I think only targeting text-based message makes sense. Is CodeSnippet also counted as text content?

[Shiti]

I think we can close this discussion as we decided to provide Copy Text. For any actions in future, we think that defining the scope will be sufficient and we may not need a configuration for these. Also, the actions can be selected, extended and customized by app developers so thereby eliminating the need to try and manage them through configuration.