Fixed #3658

[ncave]

• Inline union case testers (Latest Fable fails to compile Fable.React #3658)

[ncave]

@MangelMaxime I still think we should only suppress the testers for the erased union cases, and let bundlers eliminate the unused code (same as with other already generated methods like reflection etc.).

I think it makes more sense this way, as people might be expecting these testers to be available.
I've already made that change, let me know if you disagree.

[MangelMaxime]

I still think we should only suppress the testers for the erased union cases, and let bundlers eliminate the unused code (same as with other already generated methods like reflection etc.).

@ncave I am ok with doing it this way I just have a suggestion regarding the new warning (see comment above).

[ncave]

@MangelMaxime I updated it to inline all the union case testers instead, so it should work as it does today.

P.S. I still think it's not a good idea to model free-form open-ended POJOs with F# unions, there must be a better way we can suggest for new bindings, but I guess for now this should fix existing legacy bindings.

[MangelMaxime]

Awesome thank you @ncave

P.S. I still think it's not a good idea to model free-form open-ended POJOs with F# unions, there must be a better way we can suggest for new bindings, but I guess for now this should fix existing legacy bindings.

I do agree on that, we have better ways of doing it now days using how Feliz works.

open Fable.Core
open Fable.Core.JsInterop

// Create an interface to force the representation
type IHTMlAttr = interface end

module Interop = 
    
    let inline mkIHTMlAttr (key : string) (value : obj) = unbox<IHTMlAttr> (key, value)

// Use an erased interface with inlined static members to represent the different cases
// The [<Erase>] attribute is used to not generate the constructor or reference information
// Inlining the static members minimizes the bundle size and also allows Fable 
// to generate a Literal POJO later on
// 
// Benefit of using an interface with static member versus a module and functions
// is that we gain access to overload making it possible to avoid U2<string, float>
// and instead use two separate overloads
[<Erase>]
type HTMLAttr =
    
    static member inline Href (value : string) =
        Interop.mkIHTMlAttr "href" value

    static member inline Custom (key : string) (value : string) =
        unbox<IHTMlAttr> (key, value)

// Create an helper function to guide the user in creating the object
// This is inlined to, to give a chance to Fable to generate a Literal POJO
let inline createHtmlAttr (a : IHTMlAttr list) = 
    createObj (unbox a)

// Here a literal POJO is generated
let myInstance =
    createHtmlAttr [ 
        HTMLAttr.Href "http://www.google.com" 
        HTMLAttr.Custom "data-delay" "100ms"
    ]

generates

export const myInstance = {
    href: "http://www.google.com",
    "data-delay": "100ms",
};

I should probably add similar exemple to Fable documentation officially explaining this trick to people and when documenting the keyValueList mark it has obsolete compared to this code.

Thinking about it, it is perhaps possible to upgrade Fable.React to this new style while keeping the double list syntax. The difficulty however would be how to support SSR via this style. If someone think it is worth it and want to give it a try and think it feel free to send a PR.