Custom Colors

[EJH2]

Resolves #5

This PR aims to add the ability to change progress bar colors in a (noob-)friendly fashion (basically not having to override the whole function just to change one line). Usage would look as follows:

CeleryProgressBar.initProgressBar(taskURL, {barColors: {'progress': '#ef4'}})

The above example would change the progress bar color to yellow. Any colors that aren't expressly overridden will defer to the default value, as specified in the documentation. This would also allow us to add new colors (such as IGNORED) without necessarily needing to break everything if people are only overriding for color changes.

[EJH2]

I don't think the default value documentation is the best looking, so I'm definitely open to suggestions on that.

[czue]

@EJH2 on a roll! 👏 👏

Does the static method change have any unexpected side effects? e.g. if someone was referencing those functions directly in their code for some other purpose? (not exactly sure when/why that would happen, just want to understand the implications...)

[EJH2]

I don't see any immediate issues with making these methods non-static from my testing, but @OmarWKH might be better equipped to comment on potential side-effects of this change.

[OmarWKH]

I think if someone was referencing one of the changed static methods this PR will break their code.

But I don't think users are referencing them and the documentation doesn't direct them to do so.

[EJH2]

To be fair, removing stop_task is a breaking change and we didn't really give much thought to that. So I'll go ahead and merge this in so I can start on the next one.

[OmarWKH]

I think if someone was referencing one of the changed static methods this PR will break their code.

But I don't think users are referencing them and the documentation doesn't direct them to do so.

@czue @EJH2

While investigating #66. I realized there's an obvious use case to reference the default handlers. You may want to do something upon success but then call the default success handler to show the result.

Might be too late :/

[EJH2]

Wouldn't this change make it theoretically easier to accomplish that, since you can just do

onSuccess: function(progressBarElement, progressBarMessageElement, result) {
    console.log(progressBarElement, progressBarMessageElement, result);
    this.onSuccessDefault(progressBarElement, progressBarMessageElement, result);
}

in the bar declaration? Now that you mention it, this PR does the old reference method of having to type CeleryProgressBar instead of this, though.

[OmarWKH]

You are absolutely right.