Open mr-m-coetzee opened 3 years ago
This is why DynamicObj
is used in this library, it enables the init/style pattern (see here for an example where we create an object in plotly.net). It is a powerful pattern that also allows way better C# interop than the record approach (also, you do not have to handle None
for serialization, and serialization overall works like a charm).
I agree that these records should be switched to use optional fields, but i would recommend to use the same pattern we use across the plotly libs to create these json objects with optional fields. The pattern (in a slightly different/adapted form) is already used for components, see an example here.
It is definitely more verbose, but we have many clear advantages. Conversion of your example here would be:
type DropdownOption() =
inherit DynamicObj()
static member init
(
label: IConvertible,
value: IConvertible,
?Disabled: bool,
?Title: bool
) =
DropdownOption()
|> DropdownOption.style(
label,value,
?Disabled = Disabled,
?Title = Title
)
static member style
(
label: IConvertible,
value: IConvertible,
?Disabled: bool,
?Title: bool
) =
fun (dro:DropdownOption) ->
label |> DynObj.setValue dro "label" // this is where you decide the property names for json in this pattern
value |> DynObj.setValue dro "value"
Disabled|> DynObj.setValueOpt dro "disabled"
Title |> DynObj.setValueOpt dro "title"
dro
You might even just go for init
and not using style
at all, as style is usefull if you have a DropdownOption
for which you want to set/change properties - something that most likely never happens, at least for this kind of object.
So there is already a good solution using DynamicObj
.
Why do we use records then, is there a plan to replaced them with DynamicObj
?
Well I would say I overlooked that while creating the POC. If there are optional fields, the DynamicObj approach is the way to go.
Okay great.
So we can leave this issue open then with the plan of replacing records with DynamicObj
?
I can have a look at it.
Just for clarification, i would suggest that we only apply that style for objects that have optional fields. Things such as DashApp
, where everything is mandatory should stay records with JsonProperty attributes (where needed)
Also, i added some tests for serialization of component prop types (which, by design, fail at the moment) https://github.com/plotly/Dash.NET/commit/9090c1ad86b03a4087bc13310187d28ff45d872e. I am not sure which of these records have optional fields, but i would suggest starting there (removing the convert functions, using either JsonProperty or DynObj to make tests green). Would also be awesome if we could set up creation of tests together with component auto generation, but thats another issue.
Also, i added some tests for serialization of component prop types (which, by design, fail at the moment) 9090c1a. I am not sure which of these records have optional fields, but i would suggest starting there (removing the convert functions, using either JsonProperty or DynObj to make tests green)
Great - Thanks
:point_up: @kMutagene, with the tests you added - how will PR's unrelated to this pass if they're failing already?
@mr-m-coetzee I added the necessary changes to make the tests work in #33 , just need quick feedback from @plt-joey about the changes to the component generation project
Current component record implementations does not implement optional fields as optional.
Current state
Taking
DropdownOption
as an example.The fields are described as:
But is implemented as:
Usage:
Proposal
create
method making use of tuples with optional arguments (also allows overloading where curry does not).Usage:
Example
convert
method: