Incorrect use of "keyValueList CaseRules.LowerFirst"?

[zaid-ajaj]

Incorrect use of "keyValueList CaseRules.LowerFirst"?

[Zaid-Ajaj]

I am pretty sure keyValueList is not just for DU's and I think will behave pretty much the same as createObj. When you say "incorrect use", do you mean it is generating something in a wrong way?

[cmeeren]

Nope, I just figured it was incorrect since it goes against the function's documentation, which explicitly says "Create a literal JS object from a collection of union constructors", and since there's another function createObj which is #seq<string, obj> -> obj which is exactly what we want.

Also AFAIK having casing rules makes no sense since we already have names as strings, not as union case names.

[Zaid-Ajaj]

I see, nowadays keyValueList is my swiss army knife when doing interop as it has evolved from just working with DU's and my guess is that the docs are outdated but createObj should be just fine. (Even though I think of createObj of something that works in compile-time to get a nice object literal but it should work with lists created dynamically as well AFAIK)

Alright, will look into it soon

[MangelMaxime]

keyValueList has been created for working with DUs in the fist place indeed, but at compilation, Fable replaces the DUs name by the string representation.

And so it's become similar to what we do for Feliz. For example, you are probably already using the string representation version if you ever used Style in one of your application.

By using keyValueList, we also help keep the bundle size-tiny because we don't have to re-implement the same function in our code. So if the user uses Fable.React in his application or any library who use keyValueList then adding Feliz don't duplicate the code.

[cmeeren]

By using keyValueList, we also help keep the bundle size-tiny because we don't have to re-implement the same function in our code. So if the user uses Fable.React in his application or any library who use keyValueList then adding Feliz don't duplicate the code.

Wouldn't that be the case for createObj too?

[MangelMaxime]

I not sure if the signature of createObj is the same or not but perhaps yes.

[cmeeren]

The signature isn't the same. For example, createObj doesn't take any case formatting rules as input, just seq<string, obj>, because it uses the strings as names as-is (of course).

I'm not sure how the signature is relevant though; my point was that createObj is built-in (just like keyValueList) and that using createObj instead of keyValueList won't add overhead. (I may be wrong.)

[MangelMaxime]

By signature, I wanted to mean the list argument.

createObj add a bit smaller overhead than keyValueList because it doesn't check the case formatting args.

[cmeeren]

So createObj is the optimal choice in Feliz?

[Zaid-Ajaj]

So createObj is the optimal choice in Feliz?

Probably but it needs testing to make sure it does what it should do like keyValueList does, PR please 🙏?