Type specific default options

[jwschram]

While using toastr in my project I realised that I really wanted different default options per toast type (info/warning/error/etc.).

I could make a wrapper but that feels redundant given how simple the wrapper would be.

I can do the work and I can do it without causing a breaking change, but I wanted to make sure that maintainers agree it's worth implementing.

[leehoss]

this is what I expect would be awesome
toastr.load(status,message,blah);

[jwschram]

I'm not sure I understand the load function. I'm suggesting something that isn't message specific, by building it into the global options object. Something like this.

toastr.options = {
  // default options
  "closeButton": false,
  "debug": false,
  "newestOnTop": false,
  "progressBar": false,
  "positionClass": "toast-top-right",
  "timeOut": 3000,
  "extendedTimeOut": 3000,
  ...
  "typeoverrides": {   // takes 0 or more of the available toast types
    "error": {   // toast type as object key
       // subset of option properties valid in calls to toastr (i.e. toastr["error"](msg, opts) )
      "timeOut": 0
    },
    "warning": {
      "progressBar": true
    }
  }
}

My thinking is that options would remain hierarchical as they are currently. So that toastr.error(msg, calloverrides) would use global -> global.typeoverrides.error -> calloverrides to determine the final set of options to use for the call.

What do you think? Is this in keeping with the design principles of the project?

[jwschram]

Turns out this is about 5 lines so I did it and will publish it as a PR. The new property is

options = {
  typeBasedOverrides: {
    info: {},
    success: {},
    warning: {},
    error: {}
  }

[ivansammartino]

This would be very fine! I was just thinking that I'd like to persist error and warning messages instead of fading them after a while (while keeping success messages fading)
Hope it would be implemented soon! :-)

[jwschram]

I have already implemented it and submitted a pull request. I'm waiting on acceptance. #574

…

This would be very fine! I was just thinking that I'd like to persist error and warning messages instead of fading them after a while (while keeping success messages fading) Hope it would be implemented soon! :-)

[AlexH-HankIT]

I really could use that too. Is this gonna get merged soon by any chance? Thanks.

[banda13]

I'm waiting for this merge too!