Comments 24
Мы должны объявлять let that = this во всех методах, использующих this во вложенных функциях.
Есть объективная причина делать не
const that = this;
?Для более строгой и чёткой логики(best practice) лучше использовать const везде, где это возможно. Однако в оригинале статьи приведены именно такие примеры и они являются ознакомительными. Использования let и const всегда остаются на усмотрение разработчика, ведь этот момент затрагивает не только логический, но и семантический аспект.
В случае that или self заведомо никогда меняться не будет, так что семантика у const правильная. Даже taujavarob не сможет ничего возразить :-)
Никаких возражений, все абсолютно верно.
А в JS const — это константность ссылки на объект, а не константность значения объекта?
Т. е. не как в C++, где для const объекта можно вызывать только const методы, не изменяющие его состояния?
Т. е. не как в C++, где для const объекта можно вызывать только const методы, не изменяющие его состояния?
Вообще луше вместо that использовать переменные которые конкретно нужны функции.
const numbers = this.numbers;
Зачем затруднять сборку мусора и плодить утечки памяти.
Ещё один не разобравшийся в JavaScript пишет свои туториалы…
this теряется совсем не потому, что это вложенная функция — просто реализация setTimeout вызывает её с другим this.
this теряется совсем не потому, что это вложенная функция — просто реализация setTimeout вызывает её с другим this.
Не разу не терял this за свою жизнь
Абсурд. this — это и есть контекст, в котором вызвана функция.
Если функция вызывается не в том контексте — значит что-то с руками у того, кто её вызывает. Выпрямляйте руки.
Если функция вызывается не в том контексте — значит что-то с руками у того, кто её вызывает. Выпрямляйте руки.
В случае с вложенными функциями (Nested Functions) для решения «проблемы смены контекста» лучше всего использовать стрелочные функции ведь это одна из причин существования стрелочных функций.
В случае с функциями обратного вызова (Method as callback) и особенно React-компонентами есть один очень интересный способ решения (правда он «ESNEXT candidate stage-3») — указание метода класса через поле экземпляра класса (instance class field) и стрелочной функции как в решении с 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);
}
Говорят react это новый jQuery. :-)
В текущей версии Реакт с актуальными средствами транспилинга — вообще редко когда нужен конструктор.
State можно объявить сразу напрямую, как объект, это и будет по сути сахар для конструктора. А методы можно тоже через стрелочные функции создавать.
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 — ему всегда можно подсунуть то, что нам нужно.
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});
}
Sign up to leave a comment.
Что делать, когда “this” теряет ссылку на контекст