Based on the following tutorials
aurelia-and-toastr-using-typescript
They used toastr directly in the project.
From the design point of view, I want to know, Is it reasonable that a library like toastr.js would become a service and have a CSS file(s)?
Does it have any advantages or disadvantages? Or the services should only be the code (js/ts) and no other related files.
To me, one of the biggest advantage of Aurelia is how permissive it is. Aurelia allows 3rd party js to directly touch DOM. It almost does not prevent me from anything, my experiences with other front-end framworks were totally opposite.
You can directly use toastr.js as it designed to.
Pro: why not, I don’t want to write extra code.
Cons: code coupling on all components calling toastr funcs.
You can wrap it in service. You can either use aurelia-pal DOM.injectStyles() to handle inline css (as js string) in the service js file, or use your top level app.html to require toastr css.
Pro: ride on aurelia DI, means decoupled code, easy testing. Possible to replace toastr.js without breaking api.
Cons: effort. DOM.injectStyles sounds like better choice to encapsulate toastr.js within one file.
I would like to introduce another kind of wrapper.
Create a light component using @noView(['some.css']), just like what aurelia tutorial did for nprogress. Instead of using binding to talk to MyToastr component, we use EventAggregator. In MyToastr component, subscribe a type of event. And then just publish that events anywhere in your code.
Pro: decoupled code, easy testing on event. No need extra injection. Possible to replace toastr.js without breaking api.
Cons: effort. Need to add <my-toastr></my-toastr> to app.html.
I have been using all 3 options in my projects.