-
Notifications
You must be signed in to change notification settings - Fork 158
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
[DISCUSSION] Referencing chart.js through our library #95
Comments
The most important point is:
If this is done properly, the users won't have disadvantages through the change. My problem with this is always that I as a customer wouldn't like to change these things as long as the library works properly. I mean, it's a bit more configuration and not just "install the nuget and it works" if you now what I mean :) But, of course, I understand why some people might find this useful. |
I get your point but is it really more configuration? Right now consumers have to put this in their client-side entry point:
After we remove that chart.js from our sources, they'll have to put the following instead:
Is that really a difference? In both cases, we just put it in the readme and people copy paste it into their applications, only very few will actually think about what version makes the most sense etc. And when we put it in the readme, we can even put it with SRI, it'll still be copy paste. Just installing the nuget won't be enough either way.
I still think it would be an improvement over the current solution, people can still keep a local copy if they want to. |
You're right. There's no more configuration needed, my mistake :) I just don't really like CDNs, but the script can be added locally either way, so there's no issue. |
Yea if you don't want to use a CDN or only a certain one, you can do it. But if you do that right now, the js-file will still get copied around even though you don't need it. That's what I'm trying to eliminate. |
Closing this because I recently removed the pre-built Chart.js code and also all moment.js stuff. When I release 2.0, I'll update the readme to use a CDN link with a notice that you can download the latest builds from the Chart.js page if you don't want to use a CDN. I think that's a good way to handle it. |
@Joelius300 Yeah, this seems like a good idea. |
In the README and in our samples, we reference chart.js and moment.js through our library with the
_content
directory added by blazor. It's included in the sources of this library and is automatically integrated into the client-side root of applications that consume this library.But why?
We can write what version of chart.js we currently support and we can let the consumer chose themselfs how to include the chart.js. We can also let them chose if they want the minified version or not. Why should we include the JavaScript-file of chart.js in our library as well, doesn't it just bloat the nuget size?
It would be a breaking change to remove it but here's why I think it would make sense.
Pro
_Host.cshtml
orindex.html
would change in the consumers applicationContra
If possible, I would like to hear some opinions on this before we decide anything. Can anyone tell us some good arguments for keeping it in? Or do you agree with me that it should be excluded from the project and just be documented well?
cc @mariusmuntean
The text was updated successfully, but these errors were encountered: