Skip to content
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

Blazorise.Charts and ChartJs.Blazor #1454

Closed
Joelius300 opened this issue Nov 11, 2020 · 3 comments
Closed

Blazorise.Charts and ChartJs.Blazor #1454

Joelius300 opened this issue Nov 11, 2020 · 3 comments

Comments

@Joelius300
Copy link

Joelius300 commented Nov 11, 2020

Heyo Blazorise

I'm the maintainer of ChartJs.Blazor which is basically a stand-alone version of Blazorise.Charts if I understand correctly.

I just released version 2.0 and now the future is uncertain because our situation isn't great.

I opened this issue just to ask openly how you would feel about a collaboration.
Having worked on ChartJs.Blazor for over a year now, I have learned some things about issues you've surely encountered as well. The most obnoxious being that you cannot customize the serializer used in IJSRuntime and thus you can't avoid null values without some crazy workaround.

Here are some of the most notable difference that I found:
Disclaimer: I have not used Blazorise.Charts myself, I only looked at the code and the docs.

  • ChartJs.Blazor uses JSON.NET behind the scenes in order to avoid the limitations System.Text.Json currently has.
  • ChartJs.Blazor uses inheritance in their option models so it's serialize-only (with some exceptions like the event-parameters).
  • More Callbacks are supported with typed arguments.
  • Things like Easing, FontStyle, etc. are all typed with custom enums (called StringEnum) which basically implement the "type-safe enum pattern" and thus aren't as nice to use as standard C# enums but are extendable and make much less trouble for serialization.
  • Other options which only accept certain values like FillingMode but may have different types use the ObjectEnum which is the more open alternative to StringEnum and has similarities to discriminated unions. These make the use of those options much nicer.
  • ChartJs.Blazor supports Indexable options via IndexableOptions
  • Blazorise.Charts handles colors better than ChartJs.Blazor but things like gradients aren't supported in either.
  • In ChartJs.Blazor you can do changes to the dataset completely separate from the chart and then just call update to apply the changes. Currently, these do not track where and what changed so Chart.js has to figure that out by themselves in order to play the most appropriate animation but for what I've used it, Chart.js is pretty good at that. In Blazorise.Charts you have to call appropriate custom methods to update the datasets.
  • ChartJs.Blazor uses nullable options everywhere which means it will use the Chart.js default (which can be changed) instead of the hardcoded C# default
  • Blazorise.Charts supports streaming (through Blazorise.Charts.Streaming and chartjs-plugin-streaming).
  • Blazorise.Charts can only contain one type of item in a chart which prevents many mixed chart scenarios.

I'm sure there's more but I think both ChartJs.Blazor and Blazorise.Charts try to achieve more or less the same.

I have no specific idea in mind and this is just a really open question but I think it's worth bringing it up here. It was brought to my attention in this comment.

So what do you think? 😄

Ps and note to self: If we're doing something big here, maybe do something for non-blazor users as well.

@stsrki
Copy link
Collaborator

stsrki commented Nov 11, 2020

Hi @Joelius300 thank you for reaching out. I have read your comments and your story so far and I can only imagine how difficult your journey was.

Now regarding collaboration, I'm always open to it. To tell you the truth, a long time ago Blazorise.Charts was actually inspired by ChartJs.Blazor. So there are some similarities in how they both work. But over time, naturally, they both go a different route. We both have some features that are available in one library, or some that lack.

Since you're not interested in going forward with ChartJs.Blazor I think the best option would be to continue work on Blazorise.Charts and implement some missing features, or transfer some that are good to have. Obviously, there would be a lot of work involved.

Who would do all the work? The best choice would be you, as you already have more than enough experience. And you already know all the pitfalls. So just let me know if you want to join us. I would really like it if you do :)

Br!

@Joelius300
Copy link
Author

Joelius300 commented Nov 13, 2020

Thank you.

To be honest, I'm about equally interested in continuing with ChartJs.Blazor as I'm interested in Blazor. I'm more of a backend-guy anyway and recently I've tried getting into Angular and Vue but Blazor is still too young for me (especially since I'm still just getting into frontend). There's a high chance that I'll come back to it when .NET 6 releases but probably not before then.

So unfortunately, I don't think I'm interested in doing this migration. I'm open for discussions, happy to assist and may contribute a feature here and there but probably not more than that.

However, I think there's still a lot to take away from this collaboration.

  • If you're not afraid of breaking changes, you could simply integrate the entire ChartJs.Blazor library and adjust it to the Blazorise ecosystem. However, this will definitely come at some costs and although less than other options, take quite a bit of time.
  • If you like specific features, you could implement them one-by-one although many of the features I like about ChartJs.Blazor would cause a breaking change in Blazorise.Charts too. Such features might be
    • More complete callbacks
    • Indexable options
    • Default taken from Chart.js
    • Type-safe enum pattern for enum-like options
  • Some features that aren't in ChartJs.Blazor would also be interesting like
    • Gradient support
    • Scriptable options
    • Datasets which track the changes made and apply those (I'd probably even like to implement something like this)
    • A plugin system (which could incorporate Blazorise.Charts.Streaming)
  • The most expensive but lovliest approach would be to take ChartJs.Blazor as starting point but make some substancial changes like
    • Splitting the models and the blazor part
    • Remove JSON.NET
    • Automatic translation of callbacks and co. by walking the object tree

I feel like that's not how you use lists but I hope it got my points across 😄

Do you think you'd still want to work with ChartJs.Blazor even if I wouldn't be the one doing all the work?
Since I'm familiar with many of the pitfalls and the internals of ChartJs.Blazor, I'd definitely be there to help if there are struggles while doing this.

@StefH
Copy link
Contributor

StefH commented Jan 6, 2021

@Joelius300 : Note that the issue for serialization was more or less solved by this code:
https://github.com/stsrki/Blazorise/blob/93c016408b7a0f12b9014c6fc7dcdd779f8cbf6c/Source/Blazorise/Utils/Converters.cs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants