|
|
|
|
|
by STRML
1401 days ago
|
|
Oh, man. This hits home. I wrote a bunch of libraries for public consumption with Flowtype - Facebook's competitor to TS, which was dominant circa 2016 - and there was very little on "advanced types" available to us. React types ended up being a massive pain, from the banal (React.Component vs React.Element) to the crucial (how do you represent the required props of a component, when some subset of them are being injected via context?) Like the author, I used the redux code heavily to figure out what I needed to do, but it changed often and it seemed like the authors were also discovering the best way to use it. Combine with a bunch of Facebookisms (they were literally called that inside Flowtype source!) that were half-baked and... yes, we were just doing trial and error to make our typedefs succeed. Add onto that a severe weakness of Flowtype, its propensity to coerce to `any` without telling you, making your types green but masking real errors and... it was a time. A time with a pain quotient in the neighborhood of doing async module loaders in 2012, or cross-browser DOM manipulation in 2008. It seems, we always find a new problem to tickle our brains. |
|
I don't think the `redux` core lib ever shipped any Flow types itself. Looking at the FlowTyped repo, I see community typedefs at https://github.com/flow-typed/flow-typed/tree/master/definit... , and the Git history suggests those were indeed written by community members.
(of course on the flip side, _I_ didn't even start learning TS myself until 2019, and goodness knows _that_ has been a lot of trial and error over time :) )