Use of ChartJs.Blazor outside Razor/Blazor

[ronaldvdv]

Describe the feature request

For one of my projects I would love to generate ChartJS configuration in JSON-format. However, I'm not using Blazor; I would like to return the JSON data from an MVC controller. Looking at this library it does exactly what I need and 95% of the code could be used without a dependency on Microsoft.AspNetCore.Components.Web.

Which charts does this feature request apply to?

(All charts)

Describe the solution you'd like

Would it be possible to split this project into two packages - one for the Blazor-specific code and one that could be reused in various other settings?

Describe alternatives you've considered

I considered writing a library like this myself, until I found the great work you did ;-)

Additional context

[Joelius300]

Thanks for contacting us!

This is actually something that has bugged me for a long time. It's also related to the namespace chaos that's currently in place.

I think it would make sense to split it into two projects, ChartJs.Blazor and ChartJs.CSharp. We would move all the model classes and converters to ChartJs.CSharp and have two nugets with ChartJs.Blazor having a dependency on ChartJs.CSharp. We might still need some additional dependencies like Microsoft.JSInterop.dll but you're right, we should be able to remove most others and make it .net standard.

This would also mean that we could finally simplify the namespaces in the project. I propose to use ChartJs as root in ChartJs.CSharp so we'd have ChartJs.Common, ChartJs.BarChart, etc. for all the models and converters. In ChartJs.Blazor we would use ChartJs.Blazor as root and put all the the components in root so the classes would be ChartJs.Blazor.ChartJsBarChart, etc.
As part of this we should also considering renaming the chart components because having them prefixed with ChartJs is completely redundant. Also they're all pretty much the same except for the inheritance. That means that we should try to make them reusable either with generics (see dotnet/aspnetcore#8433) or a common component that works for any config.

I'm not sure on the namespaces, please tell me your ideas if you have any :)

This is definitely a (breaking) change worth making. However, we need to do it after #70 otherwise there'll be a lot of merge conflicts. The other PRs also play into this but they have less changes and need some work anyway. Please comment if you have anything to say :)

[ronaldvdv]

Hi Joel,

Thanks for taking the time for the extensive answer :-) Yes, the namespacing and naming for the Blazor components makes total sense to me! I'm just wondering, would you need the dependency on Microsoft.JSInterop.dll for the ChartJs.CSharp project? If the main goals for the core library would just be describing the charts and serializing them as JSON, this could perhaps be done without a dependency on JSInterop?

Best regards,
Ronald

[Joelius300]

That's fair. I just thought that if we move all the model classes to a different project and adjust the namespaces, we'd still have some DotNetObjectReferences within the model. But it would be quite easy to do all the interop stuff in ChartJs.Blazor and move the IMethodHandler (could use a different name, I don't know) to ChartJs.CSharp. That way we could have them in the model but we wouldn't need the dependency.

[ronaldvdv]

Ah, I see... I realized I will need to spend some more time digging into your code to fully understand the C#-JS-interop. Let me wait until #70 is finished, I will keep an eye on this repository. If there's anything I can do for #70 then let me know as well.

[Joelius300]

I've known this for longer but I'll say it here publicly now.

There's another project similar to ours specifically made for asp.net core MVC called ChartJSCore. You should check out if that meets your requirements.

Once ChartJs.Blazor is fixed up (fix all the errors, add all the missing properties) and the project is split into two (probably ChartJs.CSharp and ChartJs.Blazor), I would very much consider trying to merge with ChartJSCore. I think in general our library is more enjoyable to use but at the same time it has so many wrong property names, missing properties, wrong types, etc. that I do not feel comfortable saying our library is better (which is a stupid term anyway). In my opinion, there are things they're doing right and we're doing wrong and other things where it's the other way around.

Although I've not spoken to the people in charge, I think it would be great to merge both of these libraries to ChartJs.CSharp, then have a blazor port called ChartJs.Blazor and the MVC specific parts of ChartJSCore would be moved to a new library called ChartJs.MVC or something like that.

As of right now, this is just an idea. I want to make it absolutely clear that I have not spoken to either the creator of ChartJSCore nor the original author of ChartJs.Blazor about this. Also I want to emphasize that this is not about a rivalry or anything like that. While the libraries use different licenses as of this writing, it is my goal to strive for collaboration without having to compete and I think merging the libraries would help achieve this goal.

Our library is not ready yet for a consolidation like that but when the time comes, I'll make sure to reach out and try to realize this. For now, check out ChartJSCore and see if it meets your requirements better since you're working in MVC.