Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1912] Add the possibility to send feedback messages to the frontend … #1978

Merged

Conversation

frouene
Copy link
Contributor

@frouene frouene commented May 17, 2023

…after an action

Bug: #1912

Pull request template

General purpose

What is the main goal of this pull request?

  • Bug fixes
  • New features
  • Documentation
  • Cleanup
  • Tests
  • Build / releng

Project management

  • Has the pull request been added to the relevant project and milestone? (Only if you know that your work is part of a specific iteration such as the current one)
  • Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
  • Have the relevant issues been added to the pull request?
  • Have the relevant labels been added to the issues? (area:, difficulty:, type:)
  • Have the relevant issues been added to the same project and milestone as the pull request?
  • Has the CHANGELOG.adoc been updated to reference the relevant issues?
  • Have the relevant API breaks been described in the CHANGELOG.adoc? (Including changes in the GraphQL API)
  • In case of a change with a visual impact, are there any screenshots in the CHANGELOG.adoc? For example in doc/screenshots/2022.5.0-my-new-feature.png

Architectural decision records (ADR)

  • Does the title of the commit contributing the ADR start with [doc]?
  • Are the ADRs mentioned in the relevant section of the CHANGELOG.adoc?

Dependencies

  • Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
  • Are the new dependencies justified in the CHANGELOG.adoc?

Frontend

This section is not relevant if your contribution does not come with changes to the frontend.

General purpose

  • Is the code properly tested? (Plain old JavaScript tests for business code and tests based on React Testing Library for the components)

Typing

We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).

  • Variables have a proper type
  • Functions’ arguments have a proper type
  • Functions’ return type are specified
  • Hooks are properly typed:
    • useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
    • useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
    • useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
    • useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
    • useState<STATE_TYPE>(…)
  • All components have a proper typing for their props
  • No useless optional chaining with ?. (if the GraphQL API specifies that a field cannot be null, do not treat it has potentially null for example)
  • Nullable values have a proper type (for example let diagram: Diagram | null = null;)

Backend

This section is not relevant if your contribution does not come with changes to the backend.

General purpose

  • Are all the event handlers tested?
  • Are the event processor tested?
  • Is the business code (services) tested?
  • Are diagram layout changes tested?

Architecture

  • Are data structure classes properly separated from behavioral classes?
  • Are all the relevant fields final?
  • Is any data structure mutable? If so, please write a comment indicating why
  • Are behavioral classes either stateless or side effect free?

Review

How to test this PR?

Please describe here the various use cases to test this pull request

  • Has the Kiwi TCMS test suite been updated with tests for this contribution?

@pcdavid pcdavid added this to the 2023.6.0 milestone May 17, 2023
@frouene frouene force-pushed the fro/1912/message_send_back_impl branch 2 times, most recently from 7bd277f to 6bee007 Compare May 23, 2023 06:28
@frouene frouene force-pushed the fro/1912/message_send_back_impl branch from 6bee007 to 09c89a3 Compare May 23, 2023 07:20
Comment on lines 51 to 61
private String applyLevelEmoji(FeedbackMessage feedback) {
String prefix = switch (feedback.level) {
case DEBUG -> new String(Character.toChars(0x1F41B));
case INFO -> new String(Character.toChars(0x2139));
case WARNING -> new String(Character.toChars(0x26A0));
case ERROR -> new String(Character.toChars(0x274C));
};
return String.format("%s %s", prefix, feedback.message);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really mind but given the profile of our customers we may not end up keeping emojis in the user interface and doing that on the frontend would probably be better since it would allow us to customize the appearance of the toast (its color for example) but that's a subject for later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea what these emojis are given just their code point :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that for the moment we don't have in the frontend the level of the return message since we only pass the text of the message.
I can change by suffixing with the level, for example [WARNING] the warning message

CHANGELOG.adoc Outdated Show resolved Hide resolved
doc/adrs/100_feedback_messages_on_actions.adoc Outdated Show resolved Hide resolved
doc/adrs/100_feedback_messages_on_actions.adoc Outdated Show resolved Hide resolved
doc/adrs/100_feedback_messages_on_actions.adoc Outdated Show resolved Hide resolved
At first, we will join all the _string messages_ stacked in a single string, and append it to the existing `Failure` (`IStatus` implementation) _message_ parameter.
In doing so, we can keep the actual _frontend_ representation for this message.

To differentiate the level applied to the message, we will prefix it with an emoji representing this level.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emoji or icon?

packages/core/frontend/sirius-components-core/src/index.ts Outdated Show resolved Hide resolved
Comment on lines 51 to 61
private String applyLevelEmoji(FeedbackMessage feedback) {
String prefix = switch (feedback.level) {
case DEBUG -> new String(Character.toChars(0x1F41B));
case INFO -> new String(Character.toChars(0x2139));
case WARNING -> new String(Character.toChars(0x26A0));
case ERROR -> new String(Character.toChars(0x274C));
};
return String.format("%s %s", prefix, feedback.message);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea what these emojis are given just their code point :-)

}

public IStatus executeTool(Tool tool, VariableManager variableManager) {
Optional<VariableManager> optionalVariableManager = this.executeOperations(tool.getBody(), variableManager);
if (optionalVariableManager.isEmpty()) {
return new Failure(String.format("Something went wrong while executing the tool '%s'", tool.getName()));
var errorMessages = new ArrayList<>(List.of(String.format("Something went wrong while executing the tool '%s'", tool.getName())));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errorMessages => feedbackMessages

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that if the tool sends an "INFO"-level message it will get prefixed by "Something went wrong while executing the tool"?
If yes, this seems wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this first implementation we don't want to change the frontend behaviour, so we can only add stack messages on an error return.
But in the final version, if we imagine an action with several called services and before an error some information messages are stacked, then these messages will be displayed.

@frouene frouene force-pushed the fro/1912/message_send_back_impl branch 4 times, most recently from 6efd314 to 614e13e Compare May 25, 2023 06:30
@gcoutable gcoutable self-assigned this May 25, 2023
@gcoutable
Copy link
Member

I take it from here.

@gcoutable gcoutable force-pushed the fro/1912/message_send_back_impl branch 4 times, most recently from f5a6b79 to 398320d Compare May 25, 2023 14:31
Bug: eclipse-sirius#1912
Signed-off-by: Florian Rouëné <florian.rouene@obeosoft.com>
@gcoutable gcoutable force-pushed the fro/1912/message_send_back_impl branch from 398320d to a809ed1 Compare May 25, 2023 15:09
@gcoutable gcoutable dismissed pcdavid’s stale review May 25, 2023 15:42

Everything have been clarified

@gcoutable gcoutable merged commit 79512bd into eclipse-sirius:master May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide the ability for specifiers to send back error messages to the frontend
4 participants