You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I appreciate all the thought and effort that went into designing the new hooks API. It maximizes the admirable design goal of the library, to prevent runtime errors as much as possible.
However, after using it a bit I feel like it isn't the best ergonomically. Some observations that come to mind:
There are two APIs, "primary" and "secondary." They are sort of "overloaded" in some sense, which sometimes confuses IntelliJ, which is a big productivity loss.
Hooks are defined without a name. With Primary they never get a name. With Secondary the same name has to be "reinvented" on each usage, since further hooks that use it and the render method access it as a function parameter that has to be named to use it.
By the same token, you can't ctrl-click the hook to see all its usages, or ctrl-click a usage to see which hook it comes from. Instead, you have to count hooks mentally to keep track which is which.
If you delete a hook you have to update all the subsequent usages (for Primary, changing .hook<N> to .hook<N-1> for N>M, for Secondary deleting it from all the function parameters)
In my own codebase I've started using the following approach instead. It's based on for comprehensions. It still prevents a lot of kinds of violations of the "Rule of Hooks", though perhaps not as many as the current API, but I find it a lot more ergonomic and readable.
I happen to be using Settable rather than StateSnapshot. (Partially because it's more safely de/composable, being based on a "modify" function rather than a "set" function. I know you once told me that breaks Reusability, which I've only recently begun to learn, and don't fully understand this yet, but anyway it's besides the point of the overall approach
The text was updated successfully, but these errors were encountered:
I appreciate all the thought and effort that went into designing the new hooks API. It maximizes the admirable design goal of the library, to prevent runtime errors as much as possible.
However, after using it a bit I feel like it isn't the best ergonomically. Some observations that come to mind:
Primary
they never get a name. WithSecondary
the same name has to be "reinvented" on each usage, since further hooks that use it and the render method access it as a function parameter that has to be named to use it..hook<N>
to.hook<N-1>
for N>M, for Secondary deleting it from all the function parameters)Also, #1087
In my own codebase I've started using the following approach instead. It's based on for comprehensions. It still prevents a lot of kinds of violations of the "Rule of Hooks", though perhaps not as many as the current API, but I find it a lot more ergonomic and readable.
Here is an example component:
Here is that component using the current API:
Here is how it's defined:
Some notes:
withDisplayName
is from ScalaFnComponent doesn't include displayName #1087Settable
rather than StateSnapshot. (Partially because it's more safely de/composable, being based on a "modify" function rather than a "set" function. I know you once told me that breaksReusability
, which I've only recently begun to learn, and don't fully understand this yet, but anyway it's besides the point of the overall approachThe text was updated successfully, but these errors were encountered: