Currently, the structure of Fable.MaterialUI contains 2 types for each MaterialUI Component, a "raw" ComponentClass and more handy to use ReactElement.
Example:
let inline materialEl<'P when 'P :> IHTMLProp>
(a:Fable.Import.React.ComponentClass<'P>) (b: IHTMLProp list) c : Fable.Import.React.ReactElement =
Fable.Helpers.React.from a (keyValueList CaseRules.LowerFirst b |> unbox) c
let AppBar = importDefault<Fable.Import.React.ComponentClass<IHTMLProp>> "@material-ui/core/AppBar"
let inline appBar b c = materialEl AppBar b c
With this approach, there are imports of all components, so tree-shaking doesn't help. There is a way to optimize it, but then I need to remove the imports of "raw" ComponentClasses, which means a breaking change.
"Raw" ComponentClass might be needed for example to pass to ReactType DU.
Example:
MaterialProp.Component (AppBar |> U3.Case2)
Basically you will be able to import it yourself, if needed. So I would prefer a breaking changing in favor to bundle optimization.
Currently, the structure of Fable.MaterialUI contains 2 types for each MaterialUI Component, a "raw"
ComponentClass
and more handy to useReactElement
. Example:With this approach, there are imports of all components, so tree-shaking doesn't help. There is a way to optimize it, but then I need to remove the imports of "raw"
ComponentClass
es, which means a breaking change."Raw"
ComponentClass
might be needed for example to pass toReactType
DU. Example:Basically you will be able to import it yourself, if needed. So I would prefer a breaking changing in favor to bundle optimization.