-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add seq<ReactElement> overload to Html.div? #30
Comments
Hello, I can't find in the source where What does the user code look like when doing so? |
Line 96 in ac24190
I'd guess user code looks like: Html.div (
Html.x [ ... ]
) |
Ah yes, I missed this one thank you. Personally, I would just implement // Dummy type definition for Fable REPL
type ReactElement = class end
type IProp = interface end
type Html =
static member inline div (value: ReactElement) : ReactElement = unbox ""
static member inline div (value: ReactElement seq) : ReactElement = unbox ""
static member inline div (value: IProp seq) : ReactElement= unbox ""
static member inline div (value: string) : ReactElement= unbox ""
let xx =
Html.div (
Html.div [
Html.div "Maxime"
Html.div "Mangel"
]
)
let yy =
Html.div [
Html.div [
Html.div "Maxime"
Html.div "Mangel"
]
] When having passing a single child we have to use |
Fine by me. I'm not sure I want to do the same in |
I have been thinking about this from the start but I have a couple of "problems" with this approach First of all, using Second is when refactoring : if you start writing your code while prototyping with the following snippet Html.div [
Html.h1 "Fable"
Html.h2 "React"
] then you realize "Oh, I actually need to add a class to the div", suddenly you have to move the whole structure back to the following syntax Html.div [
prop.className "shiny"
prop.children [
Html.h1 "Fable"
Html.h2 "React"
]
] I think The What do you guys think? @cmeeren @MangelMaxime |
I agree that Line 11 in dc905aa
So I'm happy. :) |
According to the REPL Fable is able to determine the correct overload: type ReactElement = class end
type IProp = interface end
type Props =
| Width of float
| Height of float
interface IProp
type Html =
static member inline div (value: ReactElement) : ReactElement = unbox ""
static member inline div (value: ReactElement seq) : ReactElement = unbox ""
static member inline div (value: #IProp seq) : ReactElement= unbox ""
static member inline div (value: string) : ReactElement= unbox ""
let xx =
Html.div (
Html.div [
Html.div "Maxime"
Html.div [
Width 2.
]
]
)
let yy =
Html.div [
Html.div [
Html.div "Maxime"
Html.div [
Width 2.
]
]
] @Zaid-Ajaj Your point make sense, personnally I not a big fan of If I was to use Feliz (didn't had the time to test it for real yet), I think I would prefer to always use |
@MangelMaxime I think @Zaid-Ajaj specifically meant an empty list (literal @Zaid-Ajaj For completeness: A trick you can use to help F#'s overload resolution (which I've used in several libraries) is to implement some members (often the more general/generic ones) as extension members (in an auto-opened module). For example, if you have an overload that takes |
According to REPL it compiles too. let yy =
Html.div [
Html.div [
Html.div "Maxime"
Html.div [ ]
]
]
Yes and no. |
Huh! Strange, I remember having problems with empty lists matching multiple overloads in other contexts. Truly, F# overload resolution worketh in mysterious ways. |
Yeah really weird, if I use the following, the compilation fails type overloads =
static member inline func(xs: string list) = "string list"
static member inline func(xs: int list) = "int list"
overloads.func [ ]
|> printfn "%s" but if I change type overloads =
static member inline func(xs: #seq<string>) = "string list"
static member inline func(xs: int list) = "int list"
overloads.func [ ]
|> printfn "%s" // int list Weird stuff |
Again, I will keep this issue open until someone has better ideas, for now it seems that it won't help to have |
Strange. In any case, I'm happy without such an overload, I just wanted to mention it. :) |
The |
Actually while thinking on this issue, I think that my assumption that you almost always need props is not really the case, especially for third-party libraries that already "include" classes and props in the default component implementation. Take reactstrap/Forms for example you have the snippet: <Form>
<FormGroup>
<Label for="exampleEmail">Email</Label>
<Input type="email" name="email" id="exampleEmail" placeholder="with a placeholder" />
</FormGroup>
</Form> Here, Form.form [
FormGroup.formGroup [
Label.label [
label.htmlFor "exampleEmail"
label.text "Email"
]
Input.input [
input.email
input.name "email"
input.id "exampleEmail"
input.placeholder "with a placeholder"
]
]
] So for completeness sake, I will the |
I notice that
div
can take a singleReactElement
, but not multiple. Would it make sense to add such an overload? I personally don't have a problem writingprop.children
and indenting one level further, but since it already hasReactElement
, it might make sense to also haveseq<ReactElement>
.The text was updated successfully, but these errors were encountered: