Open Stack

On Fri, Aug 4, 2017 at 9:33 AM, Honza Pokorny <honza at redhat.com> wrote:

> About 10 years ago, we were promised a fully semantic version of HTML.
> No more nested divs to structure your documents.  However, all we got
> was a few generic, and only marginally useful elements like <footer> and
> <article>.
>
> On 2017-08-03 18:59, Ana Krivokapic wrote:
> > Hi TripleO devs,
> >
> > 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.
> >
> > 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:
> >
> > 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.
>
> While this is useful for addressing a particular element, I think it
> would still require quite a bit of parsing.  You'd find yourself writing
> string-splitting code all over the place.  It would make the code harder
> to read without providing much semantic information --- unless of course
> every single element had some kind of ID.



>
> > 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.
>
> I like this option the best.  It seems to be the most natural way of
> adding semantic information to the bare-bones building blocks of the
> web.  Classes are simple strings that add information about the intended
> use of the element.  Using jQuery-like selectors, this can make for some
> easy-to-understand code.  Do you want to grab the power state of the
> currently expanded node in the list?
>
>     $('#node-list div.node.expanded').find('.power-state')
>
> By default, Selenium can query the DOM by id, by class name, and by
> xpath.  It can be extended to use pyquery which is the Python
> implementation of the jQuery css selector.  I think many of the
> automation implementation headaches can be solved by using pyquery.
>
> https://blogs.gnome.org/danni/2012/11/19/extending-selenium-with-jquery/


I agree with this solution. Using IDs for unique elements in the page and
classes for elements which are repeating (list items) seems most natural
to me. In combination with pyquery it should be sufficient IMHO.

Also, to make sure that classes won't repeat and it is simple to identify
the desired element, we should use BEM [2] similarly as we do with IDs

Also note that incrementally we are extracting presentational components
into separate building blocks (see [1] for example), which makes the code
much more readable and classnames won't be cluttered any more.
e.g. instead of having code such as
<div className="nodesList__listItem list-group-item list-view-pf-stacked
list-view-pf-expand-active">content of item</div>
we'll have
<ListGroupItem className="nodesList__listItem">content of the
item</ListGroupItem>
IIUC this is the semanticity Honza is looking for.

[1]
https://github.com/patternfly/patternfly-react/pull/50/files#diff-b2dff316cba6ec51de4d1712eef132d0R76
[2] https://codepen.io/Merri/post/advanced-bem-with-react-components

-- Jirka


>
> Furthermore, I think that classes can be used effectively when
> describing transient state like the expanded/collapsed state of a
> togglable element.  It's easy to implement on the client side, and it
> should be helpful on the automation side.
>
> Relying on patternfly presentational class names won't suffice.



>
> > 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.
>
> This seems pretty drastic.  I wonder if there is a way we could extend
> the React component class to give us automatic and painfree ids.
>
> > 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.
> >
> > [1] https://blueprints.launchpad.net/tripleo/+spec/testing-ids
> > [2] https://review.openstack.org/#/c/483039/
> >
> > --
> > Regards,
> > Ana Krivokapic
> > Senior Software Engineer
> > OpenStack team
> > Red Hat Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170908/8a1f02b8/attachment-0001.html>