Towards v2.0

[Dzoukr]

I think it is good to think about version 2 and API changes / breaking changes to make library better. Based on great summary written by @MangelMaxime at Zaid-Ajaj/Feliz#155 I think some (most) of Maxime's feedback issues should be fixed.

The things I fully agree and would love to fix them in v2.

Some of the components don't follow the same convention ⚠️
There should be unified way of dealing with components. Most likely in a way Bulma.input.text or Bulma.input.password instead of Bulma.inputPassword. Approach like this will also resolve another point I agree with:

Feliz.Bulma doesn't provide a way for controlling which HTML element we want to output. ⚠️
Yes, mentioned API like Bulma.field.div would resolve this, but I would not add it to every element - there must be sane defaults (based on Bulma docs). Otherwise the API would be too talky with low added value. Also, for elements like Button, I need to double think. Bulma.button.a looks better than Bulma.buttonA, but Bulma.button.button (default with using button element) looks terrible. But generally fully agree and everyone can search for [<Obsolete>] in current version to see that I have been already fighting with such design mistake. Fixing that in v2 is a must!

It is not easy to add new colour support. ⚠️
That was my mistake with understanding Bulma documentation. Was not sure if I can add any defined color to every element so I added colors for each component type based on docs, but if so, then Fulma approach with having one list of colors should be the way. However on API level, I'd like to keep button.isDanger. Maybe some kind of code generator would help for this. Another approach would be not having colors directly under element modifier, but use color.isDanger everywhere. Not sure here, really.

The things I don't see as a big issue:

Feliz.Bulma is an exact mapping over Bulma - You need to know Bulma well enough or have Bulma documentation opened 🤔
Yes, that is correct. This library was created on two monitors going through Bulma docs and adding elements and modificators. I don't think it is the bad way - there is (almost) no added layer of abstraction. On the other hand, the Bulma.tabs is a great example how ugly such approach can be at some cases. The way for v2 could be to identify the "troublemakers" (like tabs or select, which needs to be wrapped in div by default) and the tiniest abstraction possible over it.

Feliz.Bulma makes it easy to mix components behaviours. 🤔
As Maxime wrote: Is can be nice way to extend existing component behavior, but also can lead to creating invalid code. I think it is the price for full compatibility with Feliz. Not ideal, but not the biggest issue here.

This list is not finite and will be updated during discussion with @MangelMaxime.

Updated 9. 4. 2020

Major indentified points for v2.

• Add support for controlling output HTML element #21
• Change the way how component color is defined and set #22
• Follow the same convention, even for extensions #23
• Add tiny abstraction over elements where low-level control doesn't make sense #24
• Special Text component  #28

[MangelMaxime]

I am really happy that we have the same vision in terms of the improvement that can be made for Feliz.Bulma :)

These two points are indeed related and in Fulma they do use the same convention.

Some of the components don't follow the same convention ⚠️
Feliz.Bulma doesn't provide a way for controlling which HTML element we want to output. ⚠️

It would give something like that for Feliz.Bulma Bulma.[component].[control of the output].

Bulma.button.button is not really fun to look at indeed but that's an edge case where an exception where the component has the same name as the HTML element 🤷‍♂️.

In Fulma, we have Button.button, Button.a , etc. and that's works.

It is not easy to add new colour support. ⚠️
Maybe some kind of code generator would help for this

TBH I don't see how code generation would help us here and I think it will requires some setup from the user perspective.

I am in favour of using button.color color.isDanger because it can be extended like that:

type BulmaColor with
    static member myCustomColor = ...

Feliz.Bulma is an exact mapping over Bulma - You need to know Bulma well enough or have Bulma documentation opened 🤔

Oh, it was just an ascertainment. It is neither bad or good just different. It's also important to note that when using Fulma I don't need Bulma documentation but I designed the library for hours, used it daily for more than 2 years and feel at home with it :D. I suppose most of Fulma users do use Bulma documentation because it's more complete than Fulma one.

All that to say, the current Feliz.Bulma documentation is good and does the job. If something could be changed, it is the styling to make it more "clean" but this is a matter of taste and not a priority IHMO.

On the other hand, the Bulma.tabs is a great example how ugly such approach can be at some cases

We can think about it indeed but from my experience in general even with Fulma helpers for the Tabs I still needed to create my own in order to mutualize the code. Another thing to know when designing this kind of helpers is that you lose a bit of control.

In certain case, it is not really a problem in the case of Tabs it isn't either is it for the Pagination.

// This is the code for Pagination.Link.a, here we lost control over the `<li>` element but I don't see people needed to control that one

/// Generate <li><a class="pagination-link"></a></li>
/// You control the `a` element
let a options children = link a options children

But in the case of "complex" component like checkradio coming from bulma-checkradio extension.

I had to create specials attributes in order to allow the user to control the label and the input properties from a single component.

/// Generate
/// <fragment>
///   <input class="is-checkradio" type="checkbox">
///   <label>One</label>
/// </fragment>
let checkboxInline (options : Option list) children =
    genericElement "checkbox" "is-checkradio" options children

Source code

This an exception but that's component is using several HTML element to shows only one component but I prefered to mention it.

Feliz.Bulma makes it easy to mix components behaviours. 🤔
Not ideal, but not the biggest issue here.

I agree and that's why I said we need a middle-ground between Feliz.Bulma simplicity and Fulma completeness but verbosity.

For information, I don't use simplicity as a bad thing. And completeness is probably not the right word but I can't figure out another word.

[Dzoukr]

Hi Maxime, I created few more issues to track work on them separately. Will not get into it before Easter, but just to do not forget. If you think something is missing, let me know or create new one. We can discuss then separately on each topic.

[MangelMaxime]

Hello @Dzoukr awesome.

[Dzoukr]

Ok, all sub-issues are now closed. I think we should release v2.0, what do you think @MangelMaxime?

[MangelMaxime]

@Dzoukr I agree with you :)

When done, I will update Fable REPL to Feliz.Bulma v2 in order to check everything is working as expected.

[Dzoukr]

Version v2 is out (indexed on Nuget soon). Thanks Maxime for amazing contribution and help! 🙏