Separate React from Bulma

[chrissimon-au]

On #60 I had some questions about implementing with tailwind - this ticket is more a longer term speculative thought inspired by considering that issue.

Looking at the structure, it seems that it might be nice to evolve towards separating between React and Bulma - the html structures in the Bulma assembly generally look fine, but the hard coded bulma classes make it hard to use with other css frameworks.

I was wondering it could evolve like so:

1. Rename Fable.Forms.Simple.Bulma to Fable.Forms.Simple.React, remove all the hard coded css class names and make classNames available as a base attribute value (appreciate it might require a few different attribute properties in some cases, as some Fields encapsulate multiple html elements that you might like to add classNames to).
2. Implement Fable.Forms.Simple.Bulma as a wrapper around Fable.Forms.Simple.React that passes in the bulma css class names

Then someone using, e.g. tailwind, could just use Fable.Forms.Simple.React and pass in the tailwind classes, and someone using Bulma could use it and it would be backwards compatible.

Once I get through my current task I'd be happy to take a look at helping with that if there is interest? And if so - any thoughts on recommendations?

[chrissimon-au]

As I've looked more into this I appreciate it's more complex than I assumed - I was just looking at the emitted html, but now that I'm looking more deeply at Fable.Forms.Simple.Bulma I can see how deeply it is dependent on a dedicated Bulma assembly that manages html structures, so this proposal probably doesn't make sense.

That said, I can still see value in a layer that permits more easily creating custom views without taking a dependency on Bulma at all... - at least that would help my situation. Will keep digging.

[MangelMaxime]

Hello,

Like you discovered it is not possible to create a package which ask the user for CSS classes only because each CSS framework require different HTML structure too.

However, Fable.Form is built in a way which allows people to extends it without additional dependencies outside of Fable.Core and Fable.Form at the lowest level.

For example, this is what allows us to provide packages like Fable.Form.Simple.Sutil.Bulma and Fable.Form.Simple.Bulma which both use different rendering libraries.

Note they have Bulma in the name because I provided support for this CSS framework but you can create your own packages depending on React + any CSS framework you want.

The easiest way to do that would be to depends on:

• Fable.Form
• Fable.Form.Simple - UI-agnostic library that provides a simple way to manage forms in Fable applications.
• Fable.Form.Simple.Fields.Html -
  provides a set of common HTML fields that can be used by libraries targetting the browser. It avoid you the need to think about how to represent an input, checkbox, etc.

You can look at how Fable.Form.Simple.Sutil.Bulma and Fable.Form.Simple.Bulma are implemented for reference. In theory, it would consist on forking Fable.Form.Simple.Bulma and updating all the XXXField.fs files to use the CSS framework you want to use.

[chrissimon-au]

Thanks @MangelMaxime , yes, because of being blocked on #60 I started looking at this, just updating each component one at a time as I need it.

I noticed that there is still a lot of bulma-agnostic logic in Fable.Form.Simple.Bulma and I wonder if you think there is a role for that logic in either Fable.Form.Simple.Fields.Html or perhaps the new layer Fable.Form.Simple.React I proposed earlier?

e.g. in FormList, the only bulma-specific rendering is between line 180 and line 262 - the rest of the file is quite generic and would be great to be re-used.

I'm thinking of trying to modify the Fable.Form.Simple.Bulma fields to be exactly the same, but to accept a set of view functions that take in relevant config and return a ReactElement.

This is similar to the original idea, but about injecting field specific 'view functions' rather than just css. Some complex fields might take multiple view Functions (like Form.list taking in a listItem function and a list function (That would accept the config and a list of reactelements for the list of items)

Then creating a new view layer would just be a matter of supplying those functions, probably by wrapping the Form.textField or Form.list methods and passing in the view functions, so that the consumer could use those methods the same way as the consume Fable.Form.Simple.Bulma, but the rest of the logic for managing the list, mapping values, outputs, etc. would all be re-usable from Fable.Form.Simple.React (cloned from Fable.Form.Simple.Bulma)

Any thoughts on this approach?

[MangelMaxime]

e.g. in FormList, the only bulma-specific rendering is between line 180 and line 262 - the rest of the file is quite generic and would be great to be re-used.

I would need to think more about it, but it is possible that we could extract the logic inside of Fable.Form.Simple.Fields.Html yes. I don't think creating yet another package would be beneficial because it could add confusion to the end user.

I'm thinking of trying to modify the Fable.Form.Simple.Bulma fields to be exactly the same, but to accept a set of view functions that take in relevant config and return a ReactElement.

I am not sure to understand, to me the implementation of a field in Fable.Form.Simple.Bulma is already quite minimal.

For example, I don't see how more minimal we can make the definition of the DateField

Fable.Form/packages/Fable.Form.Simple.Bulma/DateField.fs

Lines 9 to 52 in 176e89c

	module DateField =
	type Field<'Values>(innerField: DateField.InnerField<'Values>) =
	inherit IStandardField<'Values, string, DateField.Attributes>(innerField)
	interface IField<'Values> with
	member _.MapFieldValues(update: 'Values -> 'NewValues) : IField<'NewValues> =
	Field(Field.mapValues update innerField)
	override _.RenderField(config: StandardRenderFieldConfig<string, DateField.Attributes>) =
	Bulma.input.date [
	prop.onChange config.OnChange
	match config.OnBlur with
	| Some onBlur -> prop.onBlur (fun _ -> onBlur ())
	| None -> ()
	prop.disabled config.Disabled
	prop.readOnly config.IsReadOnly
	// For date field we need to use uncontrolled input, otherwise it will not work
	// properly when using the keyboard to input the date
	prop.defaultValue config.Value
	if config.ShowError && config.Error.IsSome then
	color.isDanger
	match config.Attributes.Max with
	| Some max -> prop.max max
	| None -> ()
	match config.Attributes.Min with
	| Some min -> prop.min min
	| None -> ()
	match config.Attributes.Step with
	| Some step -> prop.step step
	| None -> ()
	prop.autoFocus config.Attributes.AutoFocus
	]
	|> Html.View.withLabelAndError config.Attributes.Label config.ShowError config.Error

And outside of Group and FormList field which are special, all the others field have a similar implementation as DateField.

I suppose, I would need real code example in order to understand what you have in mind.