Component refactoring

[javier-godoy]

In #6 we made the internal grids protected instead of private, so that they can be configured by extending the component (they were not made public in order to conceal the data provider from the public API, however increasing their visibility is still an option).

Since grids are not public, feature #9 required adding SIX methods to the public API (three for left-delegation and three for right-delegation):

• setLeftGridClassName / setRightGridClassName that delegate on left/right setClassName
• addLeftGridClassName / addRightGridClassName that delegate on left/right addClassName
• removeLeftGridClassName / removeRightGridClassName that delegate on left/right removeClassName

This (anti)pattern was not noticeable when there was only a single pair of withLeftColumnCaption / withRightColumnCaption methods, but the evolution of the component seems to be guided by chirality. #25 attempts to address this ambidextrous code duplication on the component internals, but the public API still suffers from it.

On the other hand (pun intended) addColumn is cool-fluent, thus #8 had to introduce addSortableColumn(Book::getIsbn, comparing(Book::getIsbn), "ISBN") when addColumn(Book::getIsbn, "ISBN").setComparator(comparing(Book::getIsbn)) would have sufficed. There are still many other settings such as classNameGenerator. resizable, flexGrow and key, that cannot be configured through public API.

Latest PR #33 exposes this situation up to the point where a refactoring has to be considered.

Any thoughts?

[mlopezFC]

Good point.

The following things pops into my mind. Maybe we should consider that this component was meant to be a better replacement of List Builder, giving the features of dealing with the cases were more data is needed for displaying a lot of items (columns, filtering, sorting, etc.). Taking that into account, now I think that giving the possibility of customizing each of the grids individually goes beyond the idea of the original use case, because if you want to move around data from two different looking grids is maybe another different component.

Thinking in that direction, those methods that we added to configure the styles of each grid, could have been 3 instead of 6, and simply to add a suffix for each of the class names of the internal grids ("-left" and " -right ") would do the trick with a smaller API.

So basically I think that giving the possibility of customizing each of the grids should be something achievable only by extending the component, but the API should remain clean for the original purpose of the component (basically almost every customization should apply to each of the grids at the same time).

[javier-godoy]

Back to triage.

I think that giving the possibility of customizing each of the grids should be something achievable only by extending the component.

I disagree. There is and/or there should be public API for customizing the component.

[javier-godoy]

Unassigning myself because this issue still needs triage.

[javier-godoy]

Closing in favor of #108 and #116.