Add support for controlling output HTML element

[Dzoukr]

As agreed on #20, there should be (where it makes sense) something like [component].[control of the output].

[MangelMaxime]

I think this one is ready to be done, are you ok if I work on it?

[Dzoukr]

Sure, that would be great! I've created separated branch for version2.
https://github.com/Dzoukr/Feliz.Bulma/tree/version2

[Dzoukr]

I am going to work on #27 and thinking... Should we have API with HTML element even for components, where there is only one? E.g. Bulma.container.div vs Bulma.container (with default DIV) or Bulma.level.nav vs Bulma.level?

I think we should because:

1. API should be unified
2. We can add more HTML elements later if necessary without being breaking change

But I'd like to know your opinion on this, @MangelMaxime.

[MangelMaxime]

@Dzoukr You are not cool, you are returning my own argument against me here "API unification". 😂

I am sorry, my answer is probably not really clear I am just trying to express everything that I have in mind so we can weight the pros and cons. I made a summary at the end to clearly express my conclusion.

Personally, I would avoid noise when not required. I don't think it adds much to know that we are using a nav to control level class.

When using Fulma and future Feliz.Bulma here is how I think.

// I want to create a card
// I write Bulma.card
Bulma.card [
    // I know/remember that a card have sub-components
    // I write Bulma.card. <- I look at intellisense suggestions
    // Ooh so there is a header section and a content section

    // I want to begin with the header
    // I complete to get Bulma.card.header
    Bulma.card.header [
        // I know/remember that a card header have sub-components
        // I write Bulma.card.header. <- I look at intellisense suggestions
        // Ooh so there is a title and an icon 
        // etc.
        Bulma.card.header.title [
            Bulma.icon [
                prop.style [
                    style.marginRight (length.em 0.5)
                ]
                prop.children [
                    Fa.i [ icon; Fa.Size Fa.FaLarge ] []
                ]
            ]
            Html.text title
        ]

        Bulma.card.header.icon [
            Bulma.icon [
                Fa.i [ headerIcon ; Fa.Size Fa.FaLarge ] []
            ]
        ]
    ]

    // ...
]

Thanks to the hierarchy I can easily explore it and know exactly what is a valid "sub-component". Also, I just need to vaguely remember what I can do with Bulma components to be able to write them from memory. Or if I have the documentation open, just by looking at the visual of the component in the documentation.

I have the same logic when writing a button. I will first want to write Bulma.button but F# compiler will tell me hey that's not a ReactElement so I will do Bulma.button. and see here oh so I need to choose which HTML element because depending on my needs this can have an impact.

Choosing Bulma.button.a allow me to have a button which works as a link no need to listen to onClick.

Choosing Bulma.button.button in a form context allows me to listen to onSubmit event.

etc.

When I say

Thanks to the hierarchy I can easily explore it and know exactly what is a valid "sub-component".

We could argue that the current version too allows to quickly see everything.

Both choices are valid it's a matter of preference I guess.

We could also decide that component hierarchy is done via camelCase notation and specialization is done via dot notation. Specialization meaning controlling HTML output when it matters.

While working on #26, I discovered that you had supported some specialization in v1. But I never saw it probably because it was too similar to the rest.

We can add more HTML elements later if necessary without being breaking change

Thanks to Fulma history I think we should not have that much breaking changes coming. Also, the breaking changes in this kind of evolution are really simple to fix. You just follow the compiler and do .[choose my html output].

---

For me, we have 2 solutions:

1. Use camelCase to control component hierarchy and add dot notation when it makes sense for control HTML output.
2. Use dot-notation everywhere and add control for HTML output only where it makes sense

After, seeing my snippet using dot-notation everywhere I am not sure that it's that nice looking.

If we use solution n°1 the rules are simples:

1. Start with the context
2. Followed by the class represented using camelCase
3. Optional specialization

And that's something easy to document.

Solution n°2, doesn't make that clear explanation.

To conclude, after writing this analysis I am in favour of solution n°1. What do you think?

Edit: I should stop writing analysis; it always makes me change my mind 🤣

[Dzoukr]

OMG and I already got used to dot notation. 😂

Looking at example with your Bulma.card.header and it makes total sense to me. I like where it goes with Bulma.card root, where you do not control the HTML output.

It's you fault 😄 , but you totally got me on "dot side" and I like it more and more now.

[Dzoukr]

As you said

Thanks to the hierarchy I can easily explore it and know exactly what is a valid "sub-component".

I would start with it and maybe identify where we don't want to add direct control of HTML element output (like the container?)

[MangelMaxime]

After discussing with @Dzoukr, we will go for dot-notation and keep the control of HTML element only on the component which makes sense.

For example, Bulma.control.div and Bulma.control.p gives a different output. Bulma.control.p had a bit more margin for when you want to add Bulma.help

[Dzoukr]

I think this one is done now (in version2 branch), isn't it?

[MangelMaxime]

Yes, it should be good.