What I love about React is the unidirectional information flow. I think that's because I am a backend developer: in Rails, you load something from a database, muck with it a bit, and then render it in a view. Your view is entirely a product of a particular set of a data, rather than something that's built up over time. React's the same: the HTML that is generated by the JSX is entirely dependant on the component's properties and state.
Effectively, this makes it much easier for the developer to reason through how the component will appear in response to different interactions.
ESLint is my favourite linter for one reason: its documentation. With other linters I quite often find that it'll tell me off for doing something but not offer me a constructive way to resolve that problem.
ESLint, on the other hand, prints an easily-googlable rule name along with each warning, and the documentation for that rule often lists workarounds or conditions where the rule shouldn't apply.
For example, I was recently hit by react/no-unescaped-entities as I added
doesn't (note apostrophe) to some JSX I was writing. The documentation not only goes in to why that's a problem, but also gave me a workaround: use
This could have easily been TypeScript, but I learned Flow first, and it felt like a better fit for our existing project.
The less obvious thing I love about Flow is that you can have the best of both worlds: by using the any type, you can effectively prototype code as you would dynamically, and then later treat the
any typedefs as TODOs and correct them when you have more confidence in your architecture.