[d357r0y3r]

Imagine creating this beast of a "framework" and not even using TypeScript or Flow. What are you thinking?

Edit: It does use Flow.

[mmckelvy]

Sigh. I really wish people would just accept the fact that JavaScript is a dynamically typed language and stop making things unnecessarily difficult.

[Klathmon]

That's why I love Flow and Typescript so much. They are as opt-in as you want them to be.

I've seen a team use typescript, but have zero types in most of their files, they just used it from libraries to get some IDE autocomplete and some very small typing on core areas.

[sbr464]

My only issue is TS usage with extremely large/complex components/containers. For example, files around 500 lines of code, I've temporarily removed TS, done a few other optimizations (ternaries for obvious If/Else statements, etc) to reduce to ~200-230 lines total. The file is instantly easier to reason about and modify.

I wish there was a plugin that just did this automatically so you could toggle it back on when done. To clarify, it's mostly when working with 3rd party/other libs, where you don't have the background of the team.

[d357r0y3r]

It's best to leverage type inference if possible. I can point to entire TypeScript files that could be copied and pasted into a JavaScript file and work with no changes.

At some point, yes, you have to use annotations to get the most of it. But, ultimately, I'd much rather trade the additional characters now for the alternative: insanity producing runtime errors in production later.

[013a]

The big problem with type inference, at least at API boundaries, is that its hard to tell who's "fault" an error might be.

FuncA() returns T1, inferred. FuncB() expects it to return T2. Is FuncB expecting the wrong thing? Or is FuncA returning something incorrect?

Always annotating the return types fixes this. That's one area that I think inference is always risky.

[sbr464]

Definitely agree, I just do it temporarily, typically when working on huge features.

[sbr464]

Basically a complex version of this example, done over and over, for larger methods.

  togglePanel = (newTogglePanelComponentState: Boolean) => {
    return this.setState({ panelToggleState: newTogglePanelComponentState });
  }

  togglePanel = bool => this.setState({ panelToggle: bool })

[paavohtl]

I don't understand what you're trying to demonstrate with your example. Your TS(?) example is needlessly complicated, and syntactically invalid.

Here's a better TS implementation:

  togglePanel = (panelToggle: bool) => this.setState({ panelToggle })

[sbr464]

I agree, it wasn't a good example. More was (attempting) to make a point when inside a complex file, what I've seen. With long interface names mixed in with long variable names, contributing to larger files sizes than necessary. It varies depending on project/company. It's lowercase `boolean`.

[paavohtl]

You're right, sorry! I write TS every day at work but for some reason I sometimes forget which languages use bool and which use boolean ;)

[sbr464]

<3

[miksuv]

It does use Flow.