Yup this is a legitimate concern. I feel similarly and I think we are definitely open to enforcing with types. But I’d like to see some of this work happening in the community because I think there are a few ways to encode this information and it doesn’t make sense to force a decision without folks trying them.
That’s good to hear. I look forward to what happens here.
We link to the ReactJS hooks docs pretty aggressively because they already have pretty thorough guidance. I want to be sure to document everything that differs, but I’m not sure it makes sense to repeat on the RR page. A huge benefit of this change is that now writing a component is basically the same as in JS. Much less that’s different to document.
Well, as far as I can tell there are decisions made in the typing of the functions which by definition cannot be found in the JS docs. It makes sense to not repeat it, but I think documenting the type signatures would be really useful. I tried looking them up on Github, and besides being inconvenient, they were not at all obvious to me - a lot of function and unit arguments which are not self-documenting.
Deprecation is a was a poor word choice. My apologies. Think of it as feature frozen. Will change anywhere I see it in the docs. ReasonReact benefits much more from this switch than React does.
That sounds great! I look forward to experimenting with hooks