0

We have multiple Lightning Web Components added to a page and each of the component handles errors using toast messages. Sometimes, there is a long chain of toast messages that display when errors occur when loading the components.

We have been thinking about couple solutions:

  1. Use a Lightning web component to aggregate and display all errors.
  2. Use public properties on each component to display the error messages.
  3. Use a tag to display in-place error messages.

What should be the most recommended solution in order to improve the user experience?

Note: we are not really sure if option 3 could really help in this case

1 Answer 1

1

Have you read Messaging States in the Salesforce Lightning Design System manual? It starts off with this:

Error state can appear in these scenarios:

  • A user submits a form that contains error on one or more fields
  • A user completes an action (e.g. submitting a form), but system-related issues prevent the action to be truly executed
  • A card’s content cannot be loaded
  • A system-related error is affecting the user’s current session
  • A system-related error occurs at random
  • A page’s content is inaccessible (e.g. it cannot be found, user doesn’t have sufficient privilege, etc).
  • A process that the user initiated (e.g. data import) has errors.

Each of the scenario above shows the error message a little differently. Below are some guidelines around what components to use for each case.

It then goes on to describe various scenarios and how to handle them.

In general, if the errors are related to failing to load data or something, it should have a different appearance than an error because the user forgot to fill out a required field, and so on. Please read the documentation for specific details.

2
  • Yeah so basically each component calls a method in Apex which may or may not end with an error. Depending on different scenarios, multiple server-side errors are thrown and with the current implementation, they are displayed using a simple Toast Message in each LWC. There is not the case for not filling out required fields and so on, we are just looking for a better handling of this errors for this use cases and we thought that building a separate lwc like an error-aggregator component and using a <template> tag would be useful in this case but this is just an opinion. Commented Jul 1, 2023 at 19:23
  • @HenryJones The docs include a bit about system messages. Inline errors are probably more appropriate for most regular types of automated actions that end abnormally. Like I said, I'd suggest reading the docs and understanding recommendations. A common messaging system might not make sense to a user, since it won't be easy to identify those problems. Maybe consider investing in a logging framework, instead.
    – sfdcfox
    Commented Jul 1, 2023 at 19:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .