Comments 19
Вот как выглядит описание TodoModel с использованием ключевого слова class:
Вот — описание того же самого объекта, выполненное средствами фабричной функции
не совсем корректно, т.к. методы, которые объявлены в ES6 классе будут свойствами прототипа
Честно говоря не совсем понимаю Крокфорда. Если в мире сложились стандарты и общие представления ООП для всех языков, то зачем в JS городить свои велосипеды и все усложнять? Основное преимуществ ООП, на мой дилетантский взгляд, легкость обслуживания приложения в дальнейшем. И если в JS ООП будет, как и везде, то жить станет легче.
Фабричные функции содействуют использованию композиции вместо наследования, что даёт разработчику более высокий уровень гибкости в плане проектирования приложений., при том что это абсолютно такой же не менее популярный метод и в случае классов, однако «более гибкий», хоть и ограничивает один из подходов. Пункт про безопасность тоже особо весомым не нахожу, ибо если кому-то действительно сильно надо влезть в контекст замыкания, то он может воспользоваться грязным хаком через Function.prototype.toString(). И самое удивительное неужели человек склоняющий к функциональному программированию высказывается против стрелочной нотации которую повсеместно для этого используют. Статья была бы хороша как сравнение подходов, но в итоге в конце она превратилась в сплошное осуждение классов.
Все верно подмечено про стрелочные функции, мы теряем название функции в стеке ошибок, что серьезно усложняет понимание в каком месте отвалилось. Их нужно использовать с умом.
Все верно подмечено про стрелочные функции, мы теряем название функции в стеке ошибок, что серьезно усложняет понимание в каком месте отвалилось.
Если присваивать стрелочную функцию переменной, то в стеке отобразится имя этой переменной.
(() => {
throw new Error('Some error');
})();
// Uncaught Error: Some error
// at <anonymous>:2:12
const funcName = () => {
throw new Error('Some error');
};
funcName ();
// Uncaught Error: Some error
// at funcName (<anonymous>:2:11)
(() => {
throw new Error('Some unnaned func error');
}).name;
// ""
funcName.name;
// "funcName"
2018 год на дворе, надо пользоваться асинхронными функциями:
async function doSomething() {
await new Promise(resolve => setTimeout(resolve));
throw new Error('test');
}В них стектрейс сохраняется:
> Error: test
at doSomething (repl:4:9)
at <anonymous>2. Функция doSomething у вас не стрелочная.
Изначально в статье был наброс на стрелочные функции в setTimeout и других асинхронных коллбеках:
setTimeout(() => {}, 0);Я показал, как этого избежать, правильно используя фичи языка.
Функция doSomething у вас не стрелочная.
Я придерживаюсь правила: все функции верхнего уровня в модуле — обычные, именованные, вложенные функции — стрелочные.
Что касаемо скрытия и иммутабельности, то в чем проблема? Так часто кто-то на проекте делаем манки патч? Не делаются тесты и код ревью? За 10 лет девелопинга не было ни разу такой проблемы. Теоретически может быть… Но на практике — не было.
И да, наследование. Зачем отказаться от наследования в пользу функционального подхода? Надо уметь пользоваться арсеналом, который предоставляет язык.
Да, статья, если честно, просто однобока.
На прошлой неделе уже публиковался перевод: Элегантные паттерны современного JavaScript: Ice Factory.
В той статье была хорошо рассказана идея, было интересно. А здесь — сплошные набросы на классический подход.
Вопрос к переводчику: а в чем был смысл переводить вторую статью почти с таким же контентом?
Проблема с доступностью свойств абсолютно надумана. Всё равно весь код обычно в модулях/функциях, и получить к нему доступ нельзя. А если разработчик использует глобальные переменные для хранения чего-то хоть сколько-нибудь важного, у него проблемы посерьёзнее, чем доступ к свойствам.
Первая особенность, которую можно заметить, сравнивая классы и фабричные функции, заключается в том, что все члены, поля и методы объектов, создаваемых с помощью ключевого слова class, общедоступны.
Тем временем в TC39 добавили private поля.
github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md
Например, this теряет контекст во вложенных функциях. Это не только усложняет процесс программирования, подобное поведение ещё и является постоянным источником ошибок.
Можно подумать, вложенные функции сами по себе не усложняют процесс программирования и не являются постоянным источником ошибок.
Выносим коллбэки в отдельные методы и байндим, и если есть проблемы, то точно не с этим.
Классы и фабричные функции в JavaScript. Что выбрать?