alertifyjs / alertify.js

JavaScript Alert/Notification System
https://alertifyjs.org
MIT License
523 stars 105 forks source link

Closing persistent alert from inside callback #55

Open ollie314 opened 8 years ago

ollie314 commented 8 years ago

It would be great to have a way to be able to show a toast an close it inside a callback. It may use when a remote transaction is processing.

Note : According to the material design recomandation, it shouldn't contains an icon.

I'm trying to explain the concept whith a pseudo code.


// here is a sample deferred process
function deferredProcess(params, context) {
    var promise, processor, domInfo;

    context = context || window;
    domInfo = {
        domId: null
    };

    response = {}; // this should be a response (from remote server for instance)

    // here promise follow the jQuery pattern (done, fail, always) for readability reason
    processor = function(resolve, reject) {
        // show a presistent notification and
        // set the dialog Id with the id of the DOM element
        // this ID will be use later to close the dialog
        alertify.delay(0).notify("Loading process", domInfo);

        // do something asynchronously
        doSomethingAsync.done(function(response) {
            resolve(response);
        }).fail(function(response) {
            alertify.delay(5).error("An error occurred during processing " + response.message);
            reject(response);
        }).always(function() {
            // hiding the persistent dialog
            alertify.hideMessage(domInfo);
        });
        // hiding the previousDialog.
    }
    promise = new Promise(processor);
    // ...
    return promise;
}

To keep the alertify's chaining, I'll use an object whiches store DOM object information.

The point here is I'm not sure about the relevance of both, the principle and the way of working (as a client like presented above). I'm also not sure about the way of working with "message stacking". For now, if the "stack" is full, messages are automatically hidden. If the persistent message should be hide, it will be. When the hideMessage is called, the DOM id will give a blank result so nothing happend.

I'll make this soon if a positive feedback is given.

bradberger commented 8 years ago

To me it definitely seems useful to be able to close a log message via code, I like that and would like to see it added.

As far as message stacking, that's actually a feature that I've never been 100% thrilled with. To me, it seems that if there's more than one message being displayed at the same time, then something is wrong from a user experience point of view. How many messages is it practical to push to the user as the same time?!

I only bring that up because obviously removing the stacking, or making it non-default at least, would effect the way the manual closing of an element would work, and could potentially make it a lot simpler. So I guess my point is I'm wondering what everybody would think of that?

That's actually the first I've seen the material design spec, and it makes a lot of sense to me. I actually think it would make sense to implement as much of it as we can. As an example of it in action, Angular Material toasts have a global method for hiding an existing message, and that works because there is never more than 1 at a time.

ollie314 commented 8 years ago

Ok, I'm inline with that. I purpose to split the issue in two. The first one is dedicated to never have more than 1 toast at a time, the second one to implement a global method which hide the existing message.

bradberger commented 8 years ago

That sounds good. Thanks in advance!