Pull to refresh

Comments 24

Мы должны объявлять let that = this во всех методах, использующих this во вложенных функциях.

Есть объективная причина делать не const that = this;?
Для более строгой и чёткой логики(best practice) лучше использовать const везде, где это возможно. Однако в оригинале статьи приведены именно такие примеры и они являются ознакомительными. Использования let и const всегда остаются на усмотрение разработчика, ведь этот момент затрагивает не только логический, но и семантический аспект.
В случае that или self заведомо никогда меняться не будет, так что семантика у const правильная. Даже taujavarob не сможет ничего возразить :-)
А в JS const — это константность ссылки на объект, а не константность значения объекта?

Т. е. не как в C++, где для const объекта можно вызывать только const методы, не изменяющие его состояния?
В JS const — это неизменяется переменная. Объект на который она указывает можно изменять.

Вообще луше вместо that использовать переменные которые конкретно нужны функции.
const numbers = this.numbers;
Зачем затруднять сборку мусора и плодить утечки памяти.

Не факт что в данном случае это более удобно, но часто для таких случаев использую
const { numbers } = this;

Более реальный пример:
const { propOne, propTwo } = this.props;
Ещё один не разобравшийся в JavaScript пишет свои туториалы…
this теряется совсем не потому, что это вложенная функция — просто реализация setTimeout вызывает её с другим this.
UFO landed and left these words here
Абсурд. this — это и есть контекст, в котором вызвана функция.
Если функция вызывается не в том контексте — значит что-то с руками у того, кто её вызывает. Выпрямляйте руки.
Ну так и весь пост — это и есть инструкция по выпрямлению рук. В чем тут абсурд-то?
Абсурд в том, что ссылка на контекст — теряет ссылку на контекст. Согласитесь, это невозможно ни с какой точки зрения.
Вот функцию по ошибке не в том контексте вызвать — можно.
В случае с вложенными функциями (Nested Functions) для решения «проблемы смены контекста» лучше всего использовать стрелочные функции ведь это одна из причин существования стрелочных функций.

В случае с функциями обратного вызова (Method as callback) и особенно React-компонентами есть один очень интересный способ решения (правда он «ESNEXT candidate stage-3») — указание метода класса через поле экземпляра класса (instance class field) и стрелочной функции как в решении с Nested Functions:

class Service {
  constructor(){
    this.token = "token"; 
  }
  
  doSomething: () => console.log(this.token)
}

// Равносильно:

class Service {
  constructor(){
    this.token = "token"; 
    this.doSomething = () => console.log(this.token);
  }
}

// Или:

function Service() {
  this.token = "token"; 
  this.doSomething = () => console.log(this.token);
}

Для React я использую npm пакет react-autobind. Вызывается 1 раз в конструкторе и все методы в объекте будут приколочены, потом можно не париться.
constructor() {
  super();
  autoBind(this);
}

jQuery очень хорош, если уметь его "готовить". Что получается у меньшинства :(
Абсолютно тоже самое можно сказать про React, но здесь полегче.

В текущей версии Реакт с актуальными средствами транспилинга — вообще редко когда нужен конструктор.
State можно объявить сразу напрямую, как объект, это и будет по сути сахар для конструктора. А методы можно тоже через стрелочные функции создавать.
class MyComponent extends PureComponent {
  state = {counter: 0};

  myMethod = () => doSomething...

  render() {...}
}

this не умеет терять ссылку на контекст. Многие программисты умеют неправильно готовить js, ибо this в javascript и является контекстом исполнения функции, зависящим от того, как она была вызвана. Рекомендую к прочтению книгу "you don't know JS", раздел про this.

Тут теряется не this, а разработчик при работе с ним. Прочитав статью, человек как не разбирался с this, так и не будет разбираться. Хорошо было бы указать почему меняется this и какой его значение при вызове в примерах.

К переводчику никаких претензий.
Нда… Я не знаю, почему автор назвал статью именно так, но многих это может ввести в заблуждение, ибо…
this не может потерять контекст, так как this и есть ссылка на контекст!
Правильнее говорить о том, что делать, если контекст не тот, который ожидал разработчик.
И после этого всё встаёт на свои места.
this можно использовать в инициализаторах и в тех местах, где конкретный контекст гарантирован. А если уж есть готовый метод, который использует this — ему всегда можно подсунуть то, что нам нужно.
А почему для реакта бы вместо того, чтобы городить такой костыль
constructor(){
   super();
   this.todos = [];
   this.handleChange = this.handleChange.bind(this);
   this.add = this.add.bind(this);
}

Не объявить функцию так?

handleChange = event => {
     //Cannot read property 'setState' of undefined
     this.setState({desc: event.target.value});
}

100 раз разобрали же уже… Или это не тут разбирали?


Чтобы в классе-наследнике можно было переопределить handleChange. Если наследование не используется — разницы нет никакой.

Sign up to leave a comment.

Articles