-
Notifications
You must be signed in to change notification settings - Fork 77
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
Clean up memo overloads #118
Comments
I will re-evaluate and review all |
Thanks! By the way (unrelated, sorry), would it be an idea to have |
What if we had a couple normal overloads and then one overload that takes a feeder function like |
Could you give an example or two of the usage you have in mind? |
Yeah sure, so we'd have the normal overloads and then a single overload for options like this: type DefaultMemo<'T> =
{ AreEqual: ('T -> 'T -> bool) option
Name: string option
WithKey: ('T -> string) option }
type React =
static member inline memo (render: 'props -> ReactElement) = Internal.memo render
static member inline memo (render: 'props -> ReactElement, options: DefaultMemo<'T> -> DefaultMemo<'T>) = Internal.memoWithOpts render options Which would then let you do things like this:
React.memo renderFun
React.memo (renderFun, fun d -> { d with Name = Some "SomeKey" })
React.memo (renderFun, fun d -> { d with AreEqual = Some (fun _ _ -> true) }) We could also swap the position with this method so we can specify the options at the beginning like @zanaptak wanted to do the first time around. |
My own preference would be render param first followed by optional args. React.memo(render, ?areEqual, ?name, ?withKey) This is straightforward and consistent with React API, which is essentially |
I'd also like to see a convenience let MyComponent =
React.functionComponent(fun props ->
Html.none
)
|> React.withMemo memoEqualsButFunctions without having to define the non-memoed component privately first. Though this helper is simple to define myself, so it's no biggie. |
Also, I think I'm with @zanaptak on this one. I don't really want to have to update records I haven't defined myself, and the single overload with optional params is both simple and general. |
@cmeeren Ideally we don't need to use additional pipes or nesting to memoize a component -- just change We probably don't need to use Some more thoughts on overloads. I still agree with the overall sentiment of this ticket. There are 8 overloads for However, one problem with having parameters after an inline render function is that it makes code formatting more awkward. You have to fiddle a bit more with parentheses and indentation to get it to work when there is a trailing parameter vs. just a final closing paren. One of the draws of this library is less awkward formatting, so this prospect does not make me very "feliz". This issue already exists for In light of these considerations, another alternative is to keep a dedicated overload for the "happy path" of React.functionComponent(name, render, ?withKey)
React.functionComponent(render, ?withKey)
React.memo(name, render, ?withKey, ?areEqual)
React.memo(render, ?withKey, ?areEqual) This relegates only the somewhat niche |
React.memo
has tons of overloads, seemingly for any combination of parameters. Many overloads makes it hard to find the one I need. I suggest having fewer overloads (one?) with optional parameters instead.The text was updated successfully, but these errors were encountered: