Comments 4
Довольно спорный плагин. Я согласен насчет поинта про "сохранение намерений", часто, имея на руках объект, думаешь, а можно ли некоторый его метод передать в колбэк. Но плагин здесь не даст каких-то гарантий, если мы в переменную своего интерфейса принимаем некий посторонний объект, который непонятно как и где был создан. Имхо, тут пока не появится в самом TS поддержка "функций, которые можно передавать в колбэк" (или нельзя, в общем чтобы их как-то различать), то остальное малоэффективно.
С другой стороны, вид функции внутри интерфейса тоже выбирается по своим надобностям, которые никак не пересекаются с таковыми в js (в реализации). Почти всегда лучше использовать стрелочный вариант, потому что нестрелочный бивариантен по параметрам и может выкинуть сюрприз. У нестрелочных зато есть свои фичи, которые могут понадобиться наверно в 0.1% кейсов.
А в классах зачастую хочется "синтаксис метода", для экономности и нужд наследования, если заведомо известно, что будем вызывать напрямую.
Поэтому плагин, который будет принудительно связывать одно с другим, добавит головной боли, имхо.
Вот был бы ЯП который имел бы строгую типизацию и при этом обратно совместимый с JS :D
Думаю что можно предложить разделение типов методов, но не факт что их примут)
А так -- чтобы не переживать за колбэки можно использовать bind, но это по своей сути декоратор, который забивает память созданием новых функций, если его не правильно использовать.
можно использовать bind
Стрелочные функции в классах как раз и нужны для привязки this, чтобы не возиться с bind. Но да, любой такой подход создает по функции на экземпляр.
можно предложить разделение типов методов, но не факт что их примут)
подозреваю, что такое предложение уже пылится в ишьюсах репозитория ts
Во первых, как уже подметили выше, тип функции в виде стрелки вовсе не означает что реализация должна быть стрелкой. Это вообще никак не связано и я, если честно, никогда до этого не видел чтобы это так интерпретировали. Поэтому в целом смысла в такой "синхронизации" не нахожу. Стрелки в интерфейсах нужны только чтобы вариантность правильно расставлять. Какая интерфейсу разница как его реализации будут this привязывать?
Во вторых, у тс уже есть способ статически проверять привязку this:
class Foo {
bar(this: this) {}
}
const foo = new Foo()
foo.bar() // Ok
const bar = foo.bar
bar() // Error: The 'this' context of type 'void' is not assignable to method's 'this' of type 'Foo'
Синхронизация интерфейсов и их реализаций в TypeScript