ElementsFactory and css as static import instead of implements interface

[vegegoku]

When we started the new version of domino-ui 2 we wanted to reduce the amount of code you need to write as much as possible, and we managed to cut a lot of the boilerplate code for sure, one thing we did we made the ElementsFactory an interface that is implemented by default by all Domino-ui components, same for the Css interfaces -DominoCss- this was very convenient for sure it allowed us to write code like this :

package com.dominokit.samples;

import elemental2.dom.HTMLDivElement;
import org.dominokit.domino.ui.elements.DivElement;
import org.dominokit.domino.ui.utils.BaseDominoElement;

public class SampleComponent extends BaseDominoElement<HTMLDivElement, SampleComponent> {

    private DivElement root;

    public SampleComponent() {
        this.root = div()
                .addCss(dui_flex, dui_flex_col, dui_p_4)
                .appendChild(h(1))
                .appendChild(p("sample paragraph"))
                .appendChild(span());
    }

    @Override
    public HTMLDivElement element() {
        return null;
    }
}

We could create new elements or add css classes without the need to import any other classes.

But this came with some serious issues that affected other parts of the user experience :

Problem 1

It allows some weird syntax that might cause issues and errors that are hard to spot, for example in the following code :

package com.dominokit.samples;

import elemental2.dom.HTMLDivElement;
import org.dominokit.domino.ui.elements.DivElement;
import org.dominokit.domino.ui.utils.BaseDominoElement;

public class SampleComponent extends BaseDominoElement<HTMLDivElement, SampleComponent> {

    private DivElement root;

    public SampleComponent() {
        this.root = div()
                .addCss(dui_flex, dui_flex_col, dui_p_4)
                .appendChild(h(1)
                        .p("Sample paragraph")
                        .span()
                );
               
    }

    @Override
    public HTMLDivElement element() {
        return null;
    }
}

On the Span element will be actually appended, the factory allowed a wrong chain of elements creation as the h and p elements will be discarded and only the last element in the chain will be used. this is sneaky in complex components or views that can go deep in the nesting.

Problem 2

Methods from ElementsFactory or Css classes from the Css interfaces will appear in the javadocs of every component, making it a very long scroll journey to reach the actual useful docs and makes it harder to find the docs we actually looking for.

Problem 3

Having all these methods as part of every component, causes problems to IDEs auto complete and hinting, since the list is extremely long it introduces tow mains issues here, the auto complete hints become very slow and it is way harder to get the result we expect.

With those issues in mind we are switching back to use static factory imports in the next RC release.
Please share your concerns and feedback on this topic.

[FrankHossfeld]

That has an huge impact on existing projects. Especially when you have to fix the imports in several hundreds of classes.

[jhickman]

My preference is to not go with the is-a relationship here. I agree with the descriptions stated problems. The biggest one for me is with the IDE content assist as mentioned with Problem 3. It's very difficult to identify which methods are part of the widgets API vs the building block methods that are convenient only within the development of said widget.

Possible Problem 4:
Let's say I implement a widget with a foo() method (use whatever you want) and then, in a future release of Domino, the ElementsFactory, DominoCss, etc adds a new foo() method as well. This change wrecks my widget as I would then have to rename and find all usages in my app (and any apps that may use my library) to update those as well. It'd be awesome if java supported interfaces that provide 'protected' methods.

My vote is to separate this out as utility methods. There could be some composite interface/class that's used to join those interfaces so that it's a one-stop shop for static imports. That way, the ElementsFactory, DominoCss, etc can continue the way they are today, but just not implemented everywhere.

[FrankHossfeld]

can someone explain how the switch to static imports prevent the first problem, please. (may be I am blind?)

[jhickman]

Makes it a 'has-a' relationship instead of an 'is-a'. If you do static imports of methods, they don't make them part of that classes API, but implementing an interface or extending a class that has those methods do.

[FrankHossfeld]

Thanks, got it ...

[howudodat]

can you post an example of what the code would look like if you switched? As Frank mentioned this could affect quite a few files in my project.

[vegegoku]

Well we are talking about a single extra import

import static org.dominokit.domino.ui.utils.Domino.*;

once you add that mostly everything else will remain the same.

and the interfaces will not be removed right away, we might even keep them for anyone who wants to use them for other purposes.

[vegegoku]

@FrankHossfeld this ☝️