6 ms·

I'm finishing up migrating a large-ish web app from react-vis to echarts and am very happy with the results. There are a couple things to note: - It's not very

I'm finishing up migrating a large-ish web app from react-vis to echarts and am very happy with the results. There are a couple things to note: - It's not very react friendly out of the box. There are some good wrappers that mostly fix this, and overall I view this as a strength as someday maybe the product I work on will migrate away from react. Our graph configuration may survive that migration assuming our next ui lib supports echarts in some fashion. - it's not d3 based. This part is kind of a big deal. For those not familiar with the internals of js graphing, d3 has been a foundational lib for generalized graphing libs for a very long time ("generalized" here is meant to differentiate between something that can render 8 graph types versus a jquery plugin that can render only a bar chart). I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3. - The documentation is truly best in class. Really great stuff. I've been trying to exactly emulate the behavior from our previous lib and while that's occasionally been challenging, the docs have always come through for me. On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values. Quite a few graph libraries that support log scaling don't support this, and I think it may have to do with some fundamental conflict between ui people who (imo reasonably) look at their data and say "my log scale Y axis ticks should be -1, -100, -10000, -1000000! Why is that so hard?" And some dev with a slightly puritanical bent thinks about log(0) and log(-100) and their eye starts twitching and in the end of the day the feature never gets added. I get it math nerds, I get it. But throw me a bone, will ya?

szundi 3y ago
I would be interested how to move away from react. Either you write a lot of wrappers and not using the react-* libs at all and put in extra effor all way long, or it is quite hard, isn't it?
- Octoth0rpe 3y ago
  I am hopefully many years away from any such effort :) But there are still things one can to do prepare, such as: - cleanly separate as much of your state logic as possible into something like redux which isn't tied to react and can be used in many alternatives (svelte, solid, etc), which _increases_ but does not _guarantee_ that that logic will be reusable. - choose ui component libraries that have implementations on top of multiple libraries. Many react apps today are built using mui, and there are similar (though less powerful) implementations of the underlying design system (material _design_, as opposed to material _ui_) for other frameworks. This at least cuts down on design work/decisions. If your webapp is going to (presumably easily) look the same before/after, you don't have to have a ton of design meetings to decide how different is too different. Notably this is the reason why I wanted to move from react-vis to echarts at my job: it was possible to transition with very little visual difference. - Separate your data fetching logic out of react components. Implement a library for fetching data for your api, then implement a set of very light hooks/wrappers around that library, and then use those hooks/wrappers in your components. (note: this suggestion may be indistinguishable from 1) if fetching is very tightly tied to your store). That may seem like a lot to do, but I think 1/3 at least are good ideas even if you plan on being on react for _forever_. Most of what I wrote is based on preparing something like an SPA, and I'd imagine the considerations are very different from something that uses SSR. I'm personally not a fan of SSR, or at least the space I want to work in doesn't see any benefits from SSR, so that's not something I think about.
- jupp0r 3y ago
  If you are generally interested in how to write components that can be used by many frontend libraries (react/vue, etc), you should take a look at https://github.com/microsoft/fast https://github.com/microsoft/fast. I was tangentially involved with porting an existing component library to it and the end result was pretty framework agnostic and well made. You need to become familiar with ShadowDOM if you are not already.
sheepscreek 3y ago
> On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values. If dealing with log(0) is an issue, a simple solution is to add 1/0.1/0.01.. to all values in the sample. Pick a fraction that is within the margin of error for your calculations. This is not supposed to be a blanket advice for everyone - use your judgement based on the use-case.
- Octoth0rpe 3y ago
  This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point. Then you need to figure out if that point is _really_ 0.001, or if it was actually 0 and you just swapped it with 0.001 so that your graph lib didn't puke. FWIW echarts lets you replace 0s with null or '', but that doesn't help with the negative values issue. Edit: not disagreeing with you at all, just trying to make the situations where this might be problematic a bit more concrete.
  - jxf 3y ago
    > This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point. A data value doesn't have to be identical with the value used for plotting purposes. Haven't used Apache Echarts but this separation of concerns is trivial in D3, for example.
    - couchand 3y ago
      This comment so beautifully distills the difference in philosophy between D3 and Echarts. Charting libraries like Echarts provide a few stock visualizations and a handful of knobs to turn. If there's not a knob for the parameter you wish to adjust, you're out of luck. D3 provides instead a visual grammar: a toolbox for building your own visualizations.
couchand 3y ago
> it's not d3 based. ... I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3. I think your history is a bit muddled here, and it shows when you suggest "generalized" means "at least 8 charts". The reason D3 has the adoption it does is due to not being a charting library. Charting libraries like Echarts come and go. Some have more or fewer of this or that, but they all suffer the same design limitation: because they don't provide a visual grammar that you can recombine at will, you're forever limited by the scope of the charts provided by your library. Going from D3 to Echarts is like going from Rust to Excel: it's a good move if your team is more productive in that environment, but you need to have a sober understanding of what you're giving up.
- lelanthran 3y ago
  > The reason D3 has the adoption it does is due to not being a charting library. Okay, then what is it? A more general tool/framework to implement actual charts?
  - couchand 3y ago
    It's a programming language for working in the domain of interactive data visualization.
    - Octoth0rpe 3y ago
      I think my original description - a foundational lib for generalized graphing libs - is more accurate than this. I mean, d3 is literally not a programming language. It's written in js, and used in js (ignoring ts/coffeescript, etc). It's a library that provides a large toolbox of useful functions for drawing, and for the kinds of math one needs when implementing a broad array of charts. One builds on top of it, and IME it is _rarely_ directly used. d3 describes itself as '[a] JavaScript library for bespoke data visualization'.
      - couchand 3y ago
JohnVideogames 3y ago
Matplotlib for python solves this with a SymLogScale, which is allows you to chart (-10 ^3, - 10^2,..., 10^2, 10^3) in the way that you'd expect. It does this by being linear between two small limits (to avoid doing log(0) and upsetting the mathmos) and showing sign(x) * log(abs(x)) elsewhere. You can probably do the transformation yourself directly on your data, and then do the inverse transformation relatively easily for your tool tips. https://matplotlib.org/stable/api/scale_api.html#matplotlib.scale.SymmetricalLogScale https://matplotlib.org/stable/api/scale_api.html#matplotlib....
zer0tonin 3y ago
I'm curious about what you mean when you mention it not being "react friendly". I didn't encounter any issues when simply putting the chart creation in a useEffect hook (that calls the chart.dispose function in callback).
- Octoth0rpe 3y ago
  The solution you've mentioned - building your option object in an effect - is straightforward, but from my perspective very un-reacty. In some sense, the attributes in the option object will end up becoming various types of svg nodes. I can imagine that a more react-friendly implementation of e-charts would have components for each part of the option object. I also think echarts update process (setOption, merge/notMerge, etc) doesn't map very well to react's lifecycle concepts. That said, none of this is a dealbreaker from my perspective. It's an awesome library and it's _generally_ a joy to work with in react. But there's a bit of friction and that's ok.

szundi 3y ago

I would be interested how to move away from react. Either you write a lot of wrappers and not using the react-* libs at all and put in extra effor all way long, or it is quite hard, isn't it?

Octoth0rpe 3y ago
I am hopefully many years away from any such effort :) But there are still things one can to do prepare, such as: - cleanly separate as much of your state logic as possible into something like redux which isn't tied to react and can be used in many alternatives (svelte, solid, etc), which _increases_ but does not _guarantee_ that that logic will be reusable. - choose ui component libraries that have implementations on top of multiple libraries. Many react apps today are built using mui, and there are similar (though less powerful) implementations of the underlying design system (material _design_, as opposed to material _ui_) for other frameworks. This at least cuts down on design work/decisions. If your webapp is going to (presumably easily) look the same before/after, you don't have to have a ton of design meetings to decide how different is too different. Notably this is the reason why I wanted to move from react-vis to echarts at my job: it was possible to transition with very little visual difference. - Separate your data fetching logic out of react components. Implement a library for fetching data for your api, then implement a set of very light hooks/wrappers around that library, and then use those hooks/wrappers in your components. (note: this suggestion may be indistinguishable from 1) if fetching is very tightly tied to your store). That may seem like a lot to do, but I think 1/3 at least are good ideas even if you plan on being on react for _forever_. Most of what I wrote is based on preparing something like an SPA, and I'd imagine the considerations are very different from something that uses SSR. I'm personally not a fan of SSR, or at least the space I want to work in doesn't see any benefits from SSR, so that's not something I think about.
jupp0r 3y ago
If you are generally interested in how to write components that can be used by many frontend libraries (react/vue, etc), you should take a look at https://github.com/microsoft/fast https://github.com/microsoft/fast. I was tangentially involved with porting an existing component library to it and the end result was pretty framework agnostic and well made. You need to become familiar with ShadowDOM if you are not already.

sheepscreek 3y ago

> On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values. If dealing with log(0) is an issue, a simple solution is to add 1/0.1/0.01.. to all values in the sample. Pick a fraction that is within the margin of error for your calculations. This is not supposed to be a blanket advice for everyone - use your judgement based on the use-case.

Octoth0rpe 3y ago
This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point. Then you need to figure out if that point is _really_ 0.001, or if it was actually 0 and you just swapped it with 0.001 so that your graph lib didn't puke. FWIW echarts lets you replace 0s with null or '', but that doesn't help with the negative values issue. Edit: not disagreeing with you at all, just trying to make the situations where this might be problematic a bit more concrete.
- jxf 3y ago
  > This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point. A data value doesn't have to be identical with the value used for plotting purposes. Haven't used Apache Echarts but this separation of concerns is trivial in D3, for example.
  - couchand 3y ago
    This comment so beautifully distills the difference in philosophy between D3 and Echarts. Charting libraries like Echarts provide a few stock visualizations and a handful of knobs to turn. If there's not a knob for the parameter you wish to adjust, you're out of luck. D3 provides instead a visual grammar: a toolbox for building your own visualizations.

couchand 3y ago

> it's not d3 based. ... I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3. I think your history is a bit muddled here, and it shows when you suggest "generalized" means "at least 8 charts". The reason D3 has the adoption it does is due to not being a charting library. Charting libraries like Echarts come and go. Some have more or fewer of this or that, but they all suffer the same design limitation: because they don't provide a visual grammar that you can recombine at will, you're forever limited by the scope of the charts provided by your library. Going from D3 to Echarts is like going from Rust to Excel: it's a good move if your team is more productive in that environment, but you need to have a sober understanding of what you're giving up.

lelanthran 3y ago
> The reason D3 has the adoption it does is due to not being a charting library. Okay, then what is it? A more general tool/framework to implement actual charts?
- couchand 3y ago
  It's a programming language for working in the domain of interactive data visualization.
  - Octoth0rpe 3y ago
    I think my original description - a foundational lib for generalized graphing libs - is more accurate than this. I mean, d3 is literally not a programming language. It's written in js, and used in js (ignoring ts/coffeescript, etc). It's a library that provides a large toolbox of useful functions for drawing, and for the kinds of math one needs when implementing a broad array of charts. One builds on top of it, and IME it is _rarely_ directly used. d3 describes itself as '[a] JavaScript library for bespoke data visualization'.
    - couchand 3y ago

JohnVideogames 3y ago

Matplotlib for python solves this with a SymLogScale, which is allows you to chart (-10 ^3, - 10^2,..., 10^2, 10^3) in the way that you'd expect. It does this by being linear between two small limits (to avoid doing log(0) and upsetting the mathmos) and showing sign(x) * log(abs(x)) elsewhere. You can probably do the transformation yourself directly on your data, and then do the inverse transformation relatively easily for your tool tips. https://matplotlib.org/stable/api/scale_api.html#matplotlib.scale.SymmetricalLogScale https://matplotlib.org/stable/api/scale_api.html#matplotlib....

zer0tonin 3y ago

I'm curious about what you mean when you mention it not being "react friendly". I didn't encounter any issues when simply putting the chart creation in a useEffect hook (that calls the chart.dispose function in callback).

Octoth0rpe 3y ago
The solution you've mentioned - building your option object in an effect - is straightforward, but from my perspective very un-reacty. In some sense, the attributes in the option object will end up becoming various types of svg nodes. I can imagine that a more react-friendly implementation of e-charts would have components for each part of the option object. I also think echarts update process (setOption, merge/notMerge, etc) doesn't map very well to react's lifecycle concepts. That said, none of this is a dealbreaker from my perspective. It's an awesome library and it's _generally_ a joy to work with in react. But there's a bit of friction and that's ok.