<div dir="ltr"><div>Hi TripleO devs,<br></div><div><br></div><div>In our effort to make the TripleO UI code friendlier to automation testing[1], there is an open review[2] for which we seem to have some difficulty reaching the consensus on how best to proceed. There is already a discussion happening on the review itself, and I'd like to move it here, rather than having it in a Gerrit review. </div><div><br></div><div>The tricky part is around adding HTML element ids to the Nodes page. This page is generated by looping through the list of registered nodes and displaying complete information about each of them. Because of this, many of the elements are repeating on the page (CPU info, BIOS, power state, etc, for each node). We need to figure out how to make these elements easy for the automation testing code to access, both in terms of locating a single group within the page, as well as distinguishing the individual elements of a group from each other. There are several approaches that we've come up so far:</div><div><br></div><div>1) Add unique IDs to all the elements. Generate unique `id` html attributes by including the node UUID in the value of the `id` attribute. Do this for both the higher level elements (divs that hold all the information about a single node), as well as the lower level (the ones that hold info about BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI codebase with many `id` attributes that would otherwise not be needed.</div><div><br></div><div>2) Add CSS classes instead of IDs. Pros for this approach: no need to generate the clumsy ids containing the node UUID, since the CSS classes don't need to be unique. Cons: we would be adding even more classes to HTML elements, many of which are already cluttered with many classes. Also, these classes would not exist anywhere in CSS or serve any other purpose.</div><div><br></div><div>3) Add custom HTML attributes. These usually start with the 'data-' prefix, and would not need to be unique either. Pros: avoids the problems described with both approaches above. Cons: AFAIU, the React framework could have problems with custom attributes (Jirka can probably explain this better). Also, casual readers of the code could be confused about the purpose of these attributes, since no other code present in the UI codebase is using them in any way.</div><div><br></div><div><br></div><div>It seems that a perfectly optimal solution does not exist here and we will have to compromise on some level. Let's try and figure out what the best course of action here is.</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/tripleo/+spec/testing-ids">https://blueprints.launchpad.net/tripleo/+spec/testing-ids</a></div><div>[2] <a href="https://review.openstack.org/#/c/483039/">https://review.openstack.org/#/c/483039/</a></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Regards,</div><div>Ana Krivokapic</div><div>Senior Software Engineer</div><div>OpenStack team</div><div>Red Hat Inc.</div></div></div>
</div>