-
Notifications
You must be signed in to change notification settings - Fork 347
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
Rules of hooks #465
Labels
Comments
peterpme
added
docs
issues that are about providing better documentation
help wanted
labels
Apr 22, 2020
I faced this issue multiple times and end-up creating a ppx to lint the same rules of hooks as the ESLint plugin. The experiment lives here https://github.com/ml-in-barcelona/react-rules-of-hooks-ppx. Isn't complete and gives false-positives, but it might be worth spending more time on it. |
https://legacy.reactjs.org/docs/hooks-rules.html . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Have there been any plans or proposals to implement the “rules of hooks” into ReasonReact?
(ReactJS docs on the topic for context).
A common pitfall with hooks is that they have a lot of rules you have to follow to avoid breaking your app. Since ReasonReact is using hooks as the recommended way to handle state now, would it be possible to integrate these rules directly into the language?
ReactJS is actually ahead of us in this regard. Their ESLint hooks plugin will give you warnings and errors when you don’t use a hook correctly. The Create-React-App build script will even fail to compile if there are any hooks errors.
Accidentally breaking a hooks rule is very easy, even for someone who tries not to. If you have a big hook, it may be hard to keep track of the dependencies, for example. Fixing these errors can be difficult when the only symptom is that your app doesn’t seem to work as expected at runtime.
A current workaround for this issue is to run ESLint on the JS output. However, this has its own shortcomings. For example, the plugin can only understand the output of hooks if it’s destructured when it’s declared, like this:
const [count, setCount] = useState(0);
. Since BuckleScript doesn’t output JS like this, the plugin won't understand thatsetCount
is a hook dispatch, and it will throw an unncessary dependency warning if you use it inside another hook.I imagine that adding this to ReasonReact won’t be trivial, but other React features are first-class citizens already. If it’s possible, I think it would be a great new feature.
The text was updated successfully, but these errors were encountered: