PF4: Donut Chart: Missing attrs for nodes in DOM

[abalakh]

Recently donut chart was updated and existing classes for its elements like chart-container or chart-label were removed. This is problematic from automation point of view as there's no unique class names/ids/tags left to distinguish widget's components, forcing us to build ugly locators with either redundant DOM traversing or element indexing. Returning classes (or bringing in anything in exchange, like ids, labels, whatever) would help us a lot. Ideally i'd like to see one for entire widget, one for labels, one for chart container and one for chart legend.

Also i'm not sure how we should fetch actual values for donut chart. For example, let's take a look at "Blue theme donut chart" in docs:

There're no values for cats/dogs/birds either visually or in DOM. The only possible way is to mouse over each bar separately and wait for tooltip with value to appear. But since tooltips aren't present in DOM until bars are in focus, it's not an option to rely on them at least in automation. Imo labels with name/value pairs should be added to nodes in DOM.

[dlabrecq]

Are you attempting to automate testing for the examples in the react-charts package?

Note that the chart-container and chart-label selectors were created specifically for this example, not the pie component itself. The donut, legend, and label are all separate components.

Ideally, testing should not rely on selector names, but IDs. Probably not best practice to add selectors just for testing purposes. However, we can easily add IDs to these examples.

Regarding values, please keep in mind that Victory generates SVGs for its charts, legends, labels, etc.

[abalakh]

Are you attempting to automate testing for the examples in the react-charts package?

Smth like that. We have a lib for automating UI which uses pf4, and to test the lib we use official docs pages for reference.

Ideally, testing should not rely on selector names, but IDs. Probably not best practice to add selectors just for testing purposes. However, we can easily add IDs to these examples.

IDs would be great, but do you mean ids for those examples only or ids which will be automatically generated when user adds chart to his page? First option won't help me, as my goal is not to automate just examples page but to have automated widget which can be used in any app, which follows pf4 rules.

Due to lack of ids or classes, to access chart-container i have to build smth like .//div[*[name()='svg'][*[name()='text'] and not(*[name()='rect'])]] which isn't nice, having either chart-container back or similar id would be much better.

Regarding values, please keep in mind that Victory generates SVGs for its charts, legends, labels, etc.

Is there any easy way to get data from it? Are they stored somewhere in DOM or at least accessible via js command (some var with access to data)?

[dlabrecq]

Please keep in mind that chart-container was never output by the chart component. That was part of the example code only -- you should not rely on that.

The component could generate a unique ID, but it wouldn't be guaranteed to be the same each time. Unless you provide the ID, that also would not be reliable for your testing.

We could add IDs to the components used in the example. However, that's just an example and not reliable. It could be changed or removed at any time, but may be your best option?

Data is not stored in the DOM; however, the SVG is. It may be possible to traverse that, but looks complicated. You might be able to read some text tags, but doubt you could get meaningful data from a path.

https://stackoverflow.com/questions/5201782/accessing-the-svg-data-through-javascript

[dgutride]

the example classes are still present @abalakh - I'd recommend using the new ones (ws-example is the root). Moving to closed based on this - I think the value attributes issue is not related to the css classes missing - if you'd like to discuss having a different way to retrieve the data, we should discuss. Testing svg's that way would be nice to see this possibly considered in an a11y conversation as that's the only area we'd be adding some additional values for screen readers.