compiler should remove Non-null assertion operator assignment

[paranoidjk]

Because TypeScript do not recognize React defaultProps, sometimes in our react+typescript project, access props.foo will cause strictNullChecks warning, even if props.foo had beed set in defaultProps.

So in our codebase, we use below code to walk around strictNullChecks warning:

let { foo } = this.props;
foo = foo!;

// then use foo in below code will not cause strictNullChecks warning.

But we found after ts compile, foo = foo still left in js file, it's redundancy, IMO TypeScript compiler should auto remove it.

ref: ant-design/ant-design-mobile#1873

TypeScript Version: 2.4.0 / nightly (2.5.0-dev.201xxxxx)

Code

// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.

Expected behavior:

Actual behavior:

[RyanCavanaugh]

Seems like it'd just be all-around better to write if (!foo) throw new Error(); ?

Alternatively #9640

[gcanti]

@paranoidjk in order to handle defaultProps what about this pattern?

// default props
type DP = { foo: string }

// non default props
type NDP = { bar: number }

class MyComponent extends React.Component<DP & NDP> {
  // type-checked defaultProps
  static defaultProps: DP = { foo: 'foo' }
  render() {
    // default props appear as required within the component
    const { foo, bar } = this.props
    return (
      <div>
        {foo.trim()} {bar * 2}
      </div>
    )
  }
}

// make default props optional
export default MyComponent as React.ComponentClass<Partial<DP> & NDP>

[paranoidjk]

@gcanti

Thanks, brilliant solution. I think it shoud works.
But i'm just worried it will cause lot's of extra work, since we have a large codebase.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.