-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[#11947] Improve UI of Error Toasts #11948
Conversation
I'm OK with the proposed UI. 👍 |
If I may ask, what is the behaviour if this is not followed? (Using List::toString() instead) |
@samuelfangjw A solution to deal with it (where the developer is not responsible for using |
I'm not comfortable with the proposed solution at the moment. I'll preface this by saying that you are right when you say that the current error messages could be improved. The backend should be providing reasonable error messages, i.e. not array::toString(). However, the backend really should not be specifically formatting error messages for a specific consumer, the frontend in this case. Think about it this way, there shouldn't be a way for an error message sent on the backend to break/affect the formatting on the frontend, however improbable. If we do it this way, the developers working on the backend also have to be conscious of how any changes will affect the frontend as well. I'm not saying this cannot be done or there's no examples of strong coupling in the current codebase, I'm saying this is something we should try to avoid unless absolutely necessary. There's also an issue of consistency. The fact that the format of the error message in the response and the way it should be parsed differs depending on the endpoint doesn't sit well with me. In my opinion, this is a short sighted workaround to this issue and the tech debt from this will cause more issues in the future. The alternative suggested is definitely a cleaner solution, and one that I have been considering for awhile now. However, I'm not keen on rushing this out at the moment. Any solution that affects error handling has to be well thought out and designed in a way that is consistent yet extensible enough to handle all the different use cases in our application. A simple compromise I would like to explore: We can try formatting the error messages by joining the array using newlines instead. This is more reasonable than the current toString implementation and should display nicely enough on the frontend within the toast. It's not as pretty as a bulleted list, but i suspect it might be enough for our use case. Thoughts? |
@samuelfangjw I understand your concerns. I agree with you. My intentions were to avoid large scale refactor of the Error Messaging in the back-end, which should preferably be solved under a different issue since it is more general and have direct impact on multiple points of the back-end. Thank you for pointing this out. I am interested in working on you idea for the compromise. I think it is an elegant way to solve the issue without major refactoring. Furthermore, this would also solve the issue of inconsistency on the manner which the front-end deals with error messages. |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
@thikhinab Any updates for this PR? |
@fsgmhoward I believe that the proposed solution is completed and is pending review. However, I need to examine why the E2E tests are failing |
@thikhinab It can fail randomly for many reasons. You can check whether it is due to your modification. I have updated this PR as to be reviewed. |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 8 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
I will try to take a look at this again this week |
@fsgmhoward I verified that toast with |
@thikhinab Could you run a local check and see if it fails or not? |
@fsgmhoward It does not run locally. To check if it is isolated to my working branch, I tried running the tests in |
@fsgmhoward I tried running again locally, this time the test worked: |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
E2E tests are passing on my local machine as well, which makes this difficult to debug. One way to debug this without spamming the PR itself would be to enable GH actions on your own forked repo, duplicating this branch, and making a PR to your own repo's master branch. Once the PR is up, you can make edits to your branch (e.g. removing changes incrementally to see which change caused the E2E tests to fail) and wait for the E2E test results on GH actions to see if they pass. Maybe you can start by removing the change to |
@zhaojj2209 Thank you for the verifying this! I will set up GH actions on the fork and tryout the workflow you mentioned. |
Guys, This PR seems to be stalling (no activities for the past 8 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 14 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 16 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 19 days). 🐌 😢 |
@thikhinab Any updates on this PR? Let me know if you need help debugging the E2E tests. |
Guys, This PR seems to be stalling (no activities for the past 23 days). 🐌 😢 |
@zhaojj2209 It would be great if I could get your assistance. |
Then I guess my suspicions were correct; it seems that |
Guys, This PR seems to be stalling (no activities for the past 7 days). 🐌 😢 |
@zhaojj2209 Understood, will update. |
Guys, This PR seems to be stalling (no activities for the past 10 days). 🐌 😢 |
Since PR failing E2E tests even with the new changes, I would close the issue until the issue is resolved or alternative is found. |
Guys, This PR seems to be stalling (no activities for the past 10 days). 🐌 😢 |
Guys, This PR seems to be stalling (no activities for the past 16 days). 🐌 😢 |
Fixes #11947
Outline of Solution
The back-end:
ErrorMessageFormatter
to format list of error messages that could be parsed from the front-end.CreateFeedbackQuestionAction
,SubmitFeedbackResponseAction
,UpdateFeedbackResponseAction
) where the Lists of messages are used to create error responses.The front-end:
Toast
interface to facilitatestring
arrays.StatusMessageService
to clean and parse the back-end error response.Toast
component to render multiple error messages as bullet points.UI
Shortcomings & Alternatives
Future developers must be aware to use
ErrorMessageFormatter
instead of callingList::toString()
. An alternative is to ensure that there is a class such asErrorMessageList
embedded at points where error messages outputted. This would ensure that all error messages will follow the desired format. However this alternative will require to refactor the entire validation process and exception handling.