25 ms·

I've noticed people stripping out Flow (material-ui mostly), but their reasoning links to more and more people complaining about Flow on various platforms, and

• seattle_spring 9y ago
  I've been following the MUI changes closely. I'll say the following with the utmost respect for their authors: Flow, and probably TypeScript, work best when you do things "the Flow(/TS)" way. MUI authors insist on writing code as they would without Flow, and then inserting Flow in after the fact. Typed JavaScript does not work well when it's treated simply as vanilla JavaScript with annotations. To be successful, it should be treated as a different (yet similar) language, and written within the confines of what the typed language supports. The frustrations from the linked attempts at upgrading Flow in MUI stemmed from an insistence on supporting defaultProps through HoCs. This works fine, but requires some slight hacks to get it typed properly. The authors were not willing to make the exchange of implementing these hacks in exchange for an easier upgrade path, as they would have changed the generated documentation. The contributors of material-ui did not experience an issue with TS because their codebase does not use TS, it only provides external interfaces for it. I am confident they would have experienced similar issues with TS at some point, had it been used for the safety of the library itself instead of just its external API.
  • mikewhy 9y ago
    Agreed that throwing Flow/TS types on top of a library that wasn't built with them leads to frustration. There is, at least, an ongoing effort to use TS internally in MUI: https://github.com/mui-org/material-ui/pull/9561 https://github.com/mui-org/material-ui/pull/9561