Allow opting out of certain function names

I don't really see what is wrong with this behaviour. On the contrary, exceptional behaviours make it harder to read someone else's code.

Look for instance at this piece of code I found in the React docs:

class ScrollingList extends React.Component {
  constructor(props) {
    super(props);
    this.listRef = React.createRef();
  }

  getSnapshotBeforeUpdate(prevProps, prevState) {
    // Are we adding new items to the list?
    // Capture the scroll position so we can adjust scroll later.
    if (prevProps.list.length < this.props.list.length) {
      const list = this.listRef.current;
      return list.scrollHeight - list.scrollTop;
    }
    return null;
  }

  componentDidUpdate(prevProps, prevState, snapshot) {
    // If we have a snapshot value, we've just added new items.
    // Adjust scroll so these new items don't push the old ones out of view.
    // (snapshot here is the value returned from getSnapshotBeforeUpdate)
    if (snapshot !== null) {
      const list = this.listRef.current;
      list.scrollTop = list.scrollHeight - snapshot;
    }
  }

  render() {
    return (
      <div ref={this.listRef}>{/* ...contents... */}</div>
    );
  }
}

I know about render and componentDidUpdate but I have never heard of getSnapshotBeforeUpdate. Is this a built-in react method? Without override I need to break my flow and check it myself. What if this class had many custom methods as well. override helps tell apart what's component lifecycle and what is not. (Many might be tempted to insert a fat multi-line comment to cut their file in sections like // ===== Lifecycle methods ===== for that purpose actually).

Granted render is über-common and everyone knows about it, but the feature you are asking for opens the door to abuse for little apparent benefit.

I'll keep this open to debate but I am against it for now.

hmil / tslint-override

Allow opting out of certain function names #6