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

Enhancement: Reusable ToastMessage #20

Open
sfdcschwabe opened this issue Dec 9, 2020 · 3 comments
Open

Enhancement: Reusable ToastMessage #20

sfdcschwabe opened this issue Dec 9, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@sfdcschwabe
Copy link
Contributor

Related to #19 I would like to suggest also a helper component created by me to make toastMessages reusable.
I've called the below component toastMessageHelper.js

With this approach you don't have the same import in different components. You only have one import in one component!

`import { ShowToastEvent } from 'lightning/platformShowToastEvent';
/**
* Toastmessage for user.
*
* @param {string} title -- The title of the toast, displayed as a heading.
* @param {string} message -- A string containing a message for the user.
* @param {string} variant -- The theme and icon displayed in the toast. Valid values are:
* info—(Default) A gray box with an info icon.
* success—A green box with a checkmark icon.
* warning—A yellow box with a warning icon.
* error—A red box with an error icon.
* @param {string} mode -- Determines how persistent the toast is. Valid values are:
* dismissable—(Default) Remains visible until the user clicks the close button or 3 seconds has elapsed, whichever comes first.
* pester—Remains visible for 3 seconds.
* sticky—Remains visible until the user clicks the close button.
*
* You can see the styling for each theme in the Lightning Design System (https://www.lightningdesignsystem.com/components/toast/) documentation.
*/
const notifyUser = (title, message, variant, mode) => {
const toastEvent = new ShowToastEvent({
title,
message,
variant,
mode
});
dispatchEvent(toastEvent);
}

 /**
 * Toastmessage for user.
 * 
 * @param {string} title -- The title of the toast, displayed as a heading.
 * @param {string} message -- A string containing a message for the user.
 * @param {string} variant -- The theme and icon displayed in the toast. Valid values are:
 *  info—(Default) A gray box with an info icon.
 *  success—A green box with a checkmark icon.
 *  warning—A yellow box with a warning icon.
 *  error—A red box with an error icon.
 * @param {string} mode -- Determines how persistent the toast is. Valid values are:
 * @param {string[] or object} messageData -- url and label values that replace the {index} placeholders in the message string.
 */
const notifyUserWithMessageData = (title, message, variant, mode, messageData) => {
    const event = new ShowToastEvent({
        title,
        message,
        variant,
        mode,
        messageData
    });
    dispatchEvent(event);
}

const createToastMessage = (title, message, variant, mode) => {
    return { title, message, variant, mode };
}

export { notifyUser, notifyUserWithMessageData, createToastMessage };`
@LawrenceLoz
Copy link
Owner

I'm interesting to understand more about this - if we had this reusable module we'd still need to import it into each component to be able to use it, so are there advantages to this over importing and using the built-in toast message directly?

@sfdcschwabe
Copy link
Contributor Author

Yes, that's right. You have to import this module into every other component where you want to use it.

From my point of view, the advantage is to adapt standard components to your own needs and thus increase the added value of your own application.
If you want to adapt something to the functionality of a ToastMessage in the future, you only have to do this in one place.

I use it in the following way:
image

`/******************
* HELPER METHODS
******************/
handleResponse(httpResponse)
{
const statusCode = Number(httpResponse.statusCode);

    let toastMessage = {};
    switch (statusCode) {
        case 204:
            toastMessage = createToastMessage(
                `${this.validationName} on ${this.entityDefinitionId} was updated.`,
                null,
                'success',
                'pester'
            );
            break;
        default:
            const body = JSON.parse(httpResponse.body);

            toastMessage = createToastMessage(
                'Error!',
                reduceErrors(body).join(', '),
                'error',
                'sticky'
            );
            break;
    }

    notifyUser(
        toastMessage.title,
        toastMessage.message,
        toastMessage.variant,
        toastMessage.mode
    );
}`

We could also think about to hand over an object to notifyUser(...) instead of four parameters.

@LawrenceLoz
Copy link
Owner

Yeah this makes sense, I can imagine there being some value in extending this out from core functionality at some point. Perhaps firing an event for logging or standardising how exceptions are parsed. Yes happy to support your suggestions around how this is designed

@LawrenceLoz LawrenceLoz added the enhancement New feature or request label Apr 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants