Hi Jonathan.

 wonder if there's an opportunity for chart developers to be
> able to express via function when they want labels to show or hide based on
> the available label container space.
>

It's a very useful suggestion.

I've seen several similar scenarios in the zoomable chart like graph, tree,
map. Supporting callback on `label.show` is a good solution for this.
And bounding rect of the element can be one of the parameters.

In your case I think the code can be as simple as:
```js
label: {
  show(params) {
      return params.rect.width >= params.labelRect.width &&
params.rect.height >= params.labelRect.height;
  }
}
```

Thanks!

On Wed, Apr 8, 2020 at 9:21 PM Jonathan Avila <avilajonat...@gmail.com>
wrote:

> @pissang,
>
> 5.0 Sounds amazing!!!. Looking forward to these improvements. One the topic
> of labels, I wonder if there's an opportunity for chart developers to be
> able to express via function when they want labels to show or hide based on
> the available label container space. Maybe even change the rotation or font
> size. For instance, we use ECharts on dashboards with widgets that can be
> resized to very small sizes. We have added some logic to the charts to
> dynamically hide labels when we know the label won't fit in the containers.
> In other instances, we reduce the font size as you make the chart's width
> or heigh smaller. Here is an example of what we do for treemap series
> labels
>
> echarts.registerLayout(this.resolveCustomChartConfigLogic);
>
> resolveCustomChartConfigLogic(ecModel) {
>     const seriesComponent = ecModel.getComponent('series');
>
>     if (seriesComponent) {
>         const treeNode = seriesComponent.getViewRoot();
>         treeNode.children.forEach(node => {
>             const nodeLayout = node.getLayout();
>
>             // only process this logic if the node layout exists
>             if (nodeLayout) {
>                 const label = node.name;
>                 const seriesLabelModel = seriesComponent.getModel('label');
>                 const nodeLabelModel = node.getModel('label');
>                 nodeLabelModel.mergeOption({
> ...seriesLabelModel.option, ...nodeLabelModel.option });
>                 const labelRect = nodeLabelModel.getTextRect(label);
>                 const labelFits = nodeLayout.width >= labelRect.width
> && nodeLayout.height >= labelRect.height;
>                 nodeLabelModel.mergeOption({ show: labelFits });
>             }
>         });
>     }
> }
>
> As you can see, we had to register a layout and then explore the ecModel
> until we found the information about the nodes layout. Any idea if this can
> be expressed in more straightforward fashion?
>
> Thanks,
>
> Jonathan
>
> On Wed, Apr 8, 2020 at 1:32 AM Yi Shen <shenyi....@gmail.com> wrote:
>
> > Purpose of This Discussion
> >
> > Collect and discuss features included in 5.0 with the community. Finally,
> > have a draft to describe the Roadmap of ECharts 5.0 which can be posted
> on
> > the medium.
> >
> > You are welcomed to send feedback on these topics or other features that
> > should be further discussed.
> > Things have been Done
> >
> > We just finished migrating our codebase to TypeScript in the last month.
> > Discussions about migrating to TypeScript can be referred to in [1].
> >
> > Here is some brief on the pros of using TypeScript:
> >
> >    - With static typing, refactoring code can be more efficient and
> >    confident.
> >    - Type definition can be exported and provided to the developers using
> >    TypeScript.
> >    - It will be more efficient when exploring the source code.
> >
> > Also, we have created a branch named next[2] for 5.0 developing. Some of
> > the refactoring work has been started on this branch.
> >
> > Meanwhile, we will keep fixing bugs in the master branch and releasing
> 4.x
> > minor versions before 5.0 is finally released.
> > Topics to be Discussed
> >
> > Here are 7 topics I summarized from the discussions earlier. Each of the
> > topics may contain several smaller features or changes. Most of them are
> > concluded from the requested features of developers.
> >
> > It's not settled yet and may change during the discussion or even
> > developing. Please leave your comments and discuss with us if you have
> any
> > suggestions at any time.
> > 1) Animation Improvement in the Scenario of Storytelling
> >
> > Animation is very frequently used in visualization storytelling. It's
> > important to use transitions to show the relationship of data between two
> > frames. We already have a timeline component and transitions to be used
> in
> > storytelling.
> >
> > Ovilia has made a wonderful tutorial[3] about visualizing COVID-19
> > increment of each Country with timeline component.
> >
> > Still, animation provided in ECharts is not enough. In storytelling, all
> > things should all be animated nicely and smoothly. No sudden change is
> > expected.
> >
> > So in 5.0, we will take the animation effect to another level with more
> > expressive animation configurations. Not only the basic position and
> scale
> > transitions:
> >
> >    - Text can be animated. To achieve the effect like bar chart race[4]
> or
> >    line chart race.
> >    - Add transition between two different shapes. For example, a rect
> shape
> >    in the bar chart can be transit to a sector shape in the pie chart
> > smoothly.
> >    - If data is grouped or separated. The shapes will be merged or split
> >    with a nice animation.
> >
> > 2) Label Auto-placement.
> >
> > Labels are used for showing more details of data. A neatly drawn label on
> > the chart can help users understanding the chart better.
> >
> > But currently, label overlapping is still a big issue that bothers
> > developers a lot. They need to write verbose code to determine which
> labels
> > should be displayed to avoid overlapping.
> >
> > The targets of label placement in 5.0 are flexible, intuitive and display
> > nice. We are planning to add the following enhancements for label
> > placement.
> >
> >    - Label position can be a callback. For the convenience of something
> >    like aligning labels on the edge of chart.
> >    - Label auto-placement will use the developers' specified position as
> an
> >    anchor and adjust itself around it to avoid overlapping.
> >    - Label will be hidden if the placement degenerates in the previous
> >    layout stage.
> >    - For each label, a line will be used for guiding if it's far from the
> >    element. And hover-link will be applied.
> >
> > 3) More Powerful Custom Chart
> >
> > ECharts have custom series to let developers draw charts we not provided,
> > for example OHLC chart[5]. In 5.0 we will add more features in the custom
> > series to be possible of drawing more kinds of charts.
> >
> >    - Developer can specify animated properties in the renderItem
> function.
> >    - Provide more API to developers to get the necessary data to draw a
> >    proper shape.
> >    - Draw shape for the whole series instead of each item.
> >
> > Su Shuang has a more detailed summarization in the issue [6]
> > 4) Transforms of Dataset.
> >
> > Dataset is introduced since ECharts 4.0. It can use an array table or a
> > key-value object as data source. So developers don't have to process the
> > data before setOption.
> >
> > In 5.0. We can provide more powerful statistics methods in the dataset so
> > developers can get rid of most of the data processing code.
> >
> > There is an extension[7] of ECharts that already did the statistics job.
> > But the API it provided is loose for ECharts. We can integrate it in the
> > dataset component and provide a more declarative API.
> >
> > Besides the usage convenience brought by deep integration. We can easily
> > find the connection between raw data and statistics results underlying.
> On
> > top of this, more advanced interactions like linked highlight, merge and
> > split animations described in the first topic can be achieved.
> >
> > vega-transform[8] is also a good example for us about designing a
> > declarative statistics API.
> > 5) Provide More States for User Interaction.
> >
> > Currently, most of our charts only have two states during user
> interaction.
> > normal and emphasis.
> >
> > When mouse is on the element. The element will enter emphasis state and
> > being applied with a highlight style. When mouse leaves the element. The
> > element will leave emphasis state and returns to normal.
> >
> > Two states are far from enough if we want to apply more complex user
> > interactions. For example:
> >
> >    - Highlight selected data with mouse click.
> >    - Focus on the hovered element while fadeout others.
> >    - Highlight the specific data while the chart is initialized. And keep
> >    it highlighted during user interaction.
> >    - ...
> >
> > To solve this issue, we are planning to add two more states: blur and
> > selected. They are states like normal and emphasis which can be
> configured
> > with different styles respectively. Some basic rules explained:
> >
> >    - Item/series will enter blur state when some other item/series is
> >    focused.
> >    - Item/series will leave blur state when none of the item/series is
> >    focused.
> >    - Item will enter selected state when it's clicked or being selected
> by
> >    brush component.
> >    - Item will leave selected state when others or blank area is clicked.
> >
> > It may have more complex behaviors in some of the charts.
> > 6) Performance Improvement.
> >
> > Performance improvement is mostly about reducing initialize time and heap
> > memory cost, especially for the line chart.
> > 7) Squash Bugs and Other Improvements
> >
> > Improvements that matters in 5.0 but not included in the above topics:
> >
> >    - Enhance 'time' type axis
> >       - Different formatter for different time unit.
> >       - More flexible interval configuration. Each tick can be configured
> >       as 'nth day of each month'.
> >    - Align the axis ticks of both sides.
> >    - More detailed legend style.
> >    - Map with SVG data source.
> >    - ...
> >
> > Issues to be solved in 5.0 will be put in the GitHub milestone[9]
> >
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/9bd278fd81853eb5fb9e2706c343545fed4d145690e1977b99ced591%40%3Cdev.echarts.apache.org%3E
> >
> > [2] https://github.com/apache/incubator-echarts/commits/next
> >
> > [3]
> >
> >
> https://medium.com/@Ovilia/making-a-covid-19-map-with-echarts-and-leaflet-30fdcd8739c6
> >
> > [4] https://app.flourish.studio/@flourish/bar-chart-race
> >
> > [5] https://echarts.apache.org/examples/en/editor.html?c=custom-ohlc
> >
> > [6] https://github.com/apache/incubator-echarts/issues/11870
> >
> > [7] https://github.com/ecomfe/echarts-stat
> >
> > [8] https://vega.github.io/vega/docs/transforms/
> >
> > [9] https://github.com/apache/incubator-echarts/milestone/10
> > Regards!
> > --
> > Yi Shen
> > Apache ECharts(incubating) PPMC
> >
>


-- 
Yi Shen
Apache ECharts(incubating) PPMC

Reply via email to