Playing with TypeScript #1272
Playing with TypeScript #1272
Conversation
I was in the same boat while learning Go, coming from Ruby and PHP. It felt really weird and kind of annoying that I had to specify everything up front. But after doing that for a while and then going back to working on Happa in Javascript, I started to miss some of the guarantees and editor features that a typed language gave me. What I think is also really neat about Typescript is that we can apply the typing where we need it, remaining pragmatic, and getting kind of 'best of both worlds' in some way. |
My emotional side is telling me all the time Typescript sucks!!! 😡, while my head is like Take it easy, it will take some time 🎶 ☯️ 😌
Yes, that's definitely supercool, we can define how much TS we want to use. Otherwise migrations would become impossible. |
Thanks @axbarsan! |
| this.setState({ isNameBeingEdited }); | ||
| }; | ||
|
|
||
| triggerEditName = () => { | ||
| // @ts-ignore |
There was a problem hiding this comment.
I believe this isn't needed anymore
| const { cluster, nodePool } = this.props; | ||
|
|
||
| try { | ||
| this.props.dispatch( | ||
| // @ts-ignore |
|
|
||
| function mapStateToProps(state, ownProps) { | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| function mapStateToProps(state: Record<string, any>, ownProps: INodePoolProps) { |
There was a problem hiding this comment.
| function mapStateToProps(state: Record<string, any>, ownProps: INodePoolProps) { | |
| function mapStateToProps(state: Record<string, any>, ownProps: INodePoolProps): IStateProps { |
There was a problem hiding this comment.
IStateProps have more properties defined...
Does it makes sense to have a type for this if we are defining this prop in the props interface?
There was a problem hiding this comment.
But IStateProps is supposed to contain only the props that are retrieved from the redux state.
It is useful to have them defined separately for each component (INodePoolProps, IStateProps, IDispatchProps), because it's easier to know while developing where the props are coming from (if it's an own prop, or an action, or a prop coming from the state)
There was a problem hiding this comment.
👍 ok, I get it, thanks
* Configure typescript * Resolve linter errors * Add missing types * Remove extensions from import statement * Type check theme and styled components * Revert to using global styled * Enable typing for styled theme * Maybe run yarn install next time * Configure linter and fix failing code * Add linter default typescript path * Convert eslint config to javascript, to be able to properly configure the ts root path * Adjust the tsconfig path to be at the root of the tsconfig root directory * Expose tsconfig file to docker * One more shot * Convert login to typescript * Convert VersionPicker to TypeScript * Update src/components/Auth/Login.tsx * Playing with TypeScript (#1272) * Fix linter warnings * ErrorFallback to ts * ClusterDashboardNodes to ts * UpgradeNotice to ts * NodePool to ts * index.html * Functions types in NodePool * Added types file * Fixings * More fixes * Make fixes to satisfy typechecker Co-authored-by: axbarsan <[email protected]> * Fix typechecker error * Fix types in VersionPicker Co-authored-by: ograu <[email protected]>
The purpose of this PR and this other PR is to kickstart a discussion to decide whether we finally want to add TypeScript, as this is somthing still to be decided to the mix.
In this PR:
.ts, and thenNodePoolcomponent, which is a connected onetypes.tsfile for reuse interfacesCSSBreakpointsimportingAfter two days hacking with TypeScript, these are my thoughts:
And my opinion about if we should migrate to TS or not:
Finally, food for touhgt, you will find controversial and subjective (but totally valid IMO) opinions in this relatively short vid (20 min) from MPJ, they talk also about linters: https://www.youtube.com/watch?v=_ECuXk4MX6Y
This vid pretty much sums up how I feel right now! 😬