Idea for 3.0 API

[rijkvanzanten]

Hey @caroso1222! Thanks for the project ❤️

I have been thinking about the API and a way to extend the API so it's easier to add more notification types than just success and error.

Seeing that the code that makes the two "types" is nearly identical, it should be pretty "easy" to turn it into a loop:

Instead of using

var notyf = new Notyf({
  delay: 1000,
  alertIcon: 'fa fa-exclamation-circle',
  confirmIcon: 'fa fa-check-circle'  
})

I propose moving to:

const notyf = new Notyf({
  types: {
    success: {
      delay: 1000, // #7
      duration: 2000, // #6
      icon: 'fa-foo-fi-fu'
    },
    error: {} // use all defaults
  }
});

const errorNotification = notyf.error({
  title: 'Something went wrong..',
  message: 'We had some trouble while processing your request'
});

errorNotification.close(); // #20
errorNotification.on('close', () => console.log('Notification closed'));

notyf.success({
  html: "<p>Hooray! <code>image-124.jpg</code> has been uploaded!</p>" // #17
});

By nesting the types in the types key, we keep the "root" level open for global options, for example
position: bottom left|bottom right or classPrefix: noty__.

By using an object instead of a string for the individual

This API change should take care of #6, #7, (half) #13, #17, and #20. Oh, and #21 of course 😉

[rijkvanzanten]

Love to hear what you think! @caroso1222 @honzabilek4

[rijkvanzanten]

Just thought of another thing! We might want to consider changing the way icons work, seeing that this method is pretty specific to font awesome. If you want to use material design icons for example, it wouldn’t work..

Just thinking aloud here, maybe something like:

Icon:

• class
• tag
• text

could work, where if type of icon is string it defaults to class

[honzabilek4]

Hey @rijkvanzanten ,
I pretty much like the configuration object you've proposed. However, I think we should use some sensible defaults so you don't always have to fill out all the configuration. Meaning it should work just as fine without any config, while still maintaining the flexibility if needed.

I was also thinking about allowing to override the configuration per function call, but now I doubt if it's really necessary. Maybe having the notifications consistent throughout the entire app is more desirable in general.

[caroso1222]

Hey @rijkvanzanten, this is simply awesome, thanks a lot! I really appreciate all the love given to Notyf. It's impressive that this single issue is taking care of a lot of issues, I love it.

I like the API, let's roll it in 3.0.0. I'll also take into consideration the input from @honzabilek4 as having default configs is critical for the success of the project.

Thanks both for this, made my day. I'll work on this right away and keep you posted here.

[caroso1222]

Hey everyone. I finally released v3.0.0 and this issue was the cornerstone of this major release. Thanks everyone for the great ideas and suggestions on this thread. I've mentioned you all guys in the credits for 3.0.0.

There are still some things in the roadmap like the ability to programmatically close the toasts, but I'll release that in 3.1.0 for sure.

Thanks again, you're the best.