5 ms·
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 f
by sbr464 7y ago
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.
- sbr464 7y agoBasically 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 7y agoI 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 7y agoI 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`.
- d357r0y3r 7y agoIt'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.
- sbr464 7y agoDefinitely agree, I just do it temporarily, typically when working on huge features.
- 013a 7y agoThe 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.