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

Loading utility should enable success & error states #188

Open
mapsam opened this issue Oct 14, 2015 · 7 comments
Open

Loading utility should enable success & error states #188

mapsam opened this issue Oct 14, 2015 · 7 comments

Comments

@mapsam
Copy link
Member

mapsam commented Oct 14, 2015

Entered by friend Sam Bolstad while testing at his house 👍

When results from Overpass API come back negative, the icon is still a green checkmark, which is a bit misleading.

@mapsam
Copy link
Member Author

mapsam commented Oct 14, 2015

Expanding on this, the loading feature should have a success/error/info callback that dictates the icon/color - something like:

dc.util.loader = function(yes, typeClass) {
  var loader = $('<div>').addClass('dropchop-loader');

  if (yes) {
    $('body').addClass('dropchop-loading');
    $('body').append(loader);
  } else {
    $('body').removeClass('dropchop-loading');
    $('.dropchop-loader').addClass(typeClass).fadeOut(2000, function(){ // class that has icon built in
      $(this).remove();
    });
  }
};

@mapsam mapsam changed the title Don't show check mark when overpass returns no results Loading utility should enable success & error states Oct 14, 2015
@jczaplew
Copy link
Contributor

I was thinking about this last night when I noticed a similar issue with the "Import file from a URL" feature. Perhaps a more Nodejs-y convention would be passing an optional error object, and displaying an appropriate loading state icon. Something like...

dc.util.loader = function(yes, error) {
    var stateClass = (error) ? 'loader-complete-error' : 'loader-complete';
    /*......*/

        $('.dropchop-loader).addClass(stateClass).fadeOut(....
}

Operationally, it would look like

// Toggle loading state
dc.util.loader(true);

// Remove loading state with a success
dc.util.loader(false);

// Remove loading state with an error
dc.util.loader(false, error);

Thoughts?

@jczaplew
Copy link
Contributor

On a related note (this might be a separate issue) it might be best to handle the loading state on a method-by-method basis instead of universally through dc.util.xhr. Because it is handled directly in that function, there isn't a good way to handle situations like dc.ops.file['load-url'] where a valid request is made but an invalid GeoJSON object is returned.

By moving the loading state trigger out of dc.util.xhr there is more freedom to validate objects before informing the user that the process is complete.

@mapsam
Copy link
Member Author

mapsam commented Oct 16, 2015

Excellent thoughts, @jczaplew. Definitely agree that taking the loader out of the xhr is a good call. What scenarios do we need unique icons/colors for?

  • success
  • error, mishandled response
  • error, unsuccessful query (bad URL)
  • successful query but "no data" (is this an error or more of an info notification?)

It seems like if we have these errors popping up, we'll want to notify what the error is. Do you think it would make sense to build that into the loader or just use dc.notify to pass a notification separately?

@jczaplew
Copy link
Contributor

For notifying the user, I think that could be baked into the loader.

As for different icons/colors, it could possibly be generalized to

  • success - everything went a-okay
  • warning - something went right, something went wrong (good request/bad response or good request/no data, for example)
  • error - a lot went wrong

How about something like

dc.util.loader = function(yes, errorMessage, errorType) {
    var loader = $('<div>').addClass('dropchop-loader');
    var stateClass = 'loader-complete';

    if (errorMessage) {
        // If there is an error type and it equal 'warning', show the warning symbol, otherwise default to error
        stateClass = (errorType && errorType === 'warning') ? 'loader-complete-warning' : 'loader-complete-error' ;
        dc.notify('error', errorMessage, 6000);
    }

    if (yes) {
      $('body').addClass('dropchop-loading');
      $('body').append(loader);
    } else {
      $('body').removeClass('dropchop-loading');
      $('.dropchop-loader').addClass(stateClass).fadeOut(2000, function(){
        $(this).remove();
      });
    }
  }

?

That way the loader function is generic and error messages can be unique to the method producing them.

@mapsam
Copy link
Member Author

mapsam commented Oct 16, 2015

Looks good to me!

Semi-related: It seems important to have sticky notifications for errors so users can copy them without rushing before they automatically remove. Created a separate issue for this #193

@mapsam
Copy link
Member Author

mapsam commented Oct 16, 2015

The _loader.scss file probably needs some reworking to take care of the extra classes - the animation should be removed from the base class as well, and instead we can have a unique "loading" class:

.dropchop-loader {
  &.loader-loading {}
  &.loader-error {}
  &.loader-warning {}
  &.loader-success {}
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants