score:3

Accepted answer

This is the result of TSLint no-shadow rule. It allows to avoid mistakes that result from unintentionally shadowed variables. And it requires to provide workarounds for variables that could be safely shadowed.

Here addTodo import is shadowed by addTodo prop. It seems this was intentional, the rule is an obstacle in this case.

Such problems with no-shadow can be avoided by enforcing a style where objects aren't destructured if variables may become ambiguous. This allows to resolve common problems with similarly named properties, e.g. in props and state objects. This also can improve the readability in some places because no backtracking is needed, while other places may become more verbose:

import * as actions from "../../redux/actions";

// ... component code
  handleAdd = (todo: Todo) => {
    const { props } = this;
    // some code ... eventually:
    props.addTodo(todo);
  } 

export default connect(
  mapStateToProps,
  { addTodo: actions.addTodo }
)(MyComponent);

For multiple action creators as props, some pick implementation could be used instead of { addTodo: actions.addTodo }.

This style may be in conflict with ESLint prefer-destructuring rule.


Related Query

More Query from same tag