А что, если дефолтные параметры для разных фабрик изменятся?

не знаю, как по мне юзание this в реакт компонентах выглядит не очень красиво

не знаю, как по мне юзание this в реакт компонентах выглядит не очень красиво

Я не юзаю реакт

А что, если дефолтные параметры для разных фабрик изменятся?

можешь что угодно передеать, это ведь функции

разницы между классами в этом кейсе нету

разницы между классами в этом кейсе нету

https://www.npmjs.com/package/constructor-decorator

Классы - это и есть функции

можешь что угодно передеать, это ведь функции

Я понял. Я в принципе работаю с тем же подходом (функции-конструкторы), только у меня функции используют destructuring входных параметров, и после объема внутренней логики возвращают public API. В принципе то же наследование и без классов тут доступно.

Конечно доступно. Но как мы видим из примеров - код короче

На мой взгляд, это очень специфический и сжатый пример)

Скажи Никита, а если их 50, ты тоже их в одном файле будешь писать?

На мой взгляд, это очень специфический и сжатый пример)

Пример не я придумал

Но типизация конструктора - рабочая

Код на полноценном толстом классе будет пожирнее. Я не к тому, что меня особо волнует классы или не классы. Для меня вообще принципиальной разницы нет. Просто функции-конструкторы я начал использовать чаще классов за последнее время, и выглядит это довольно естественно и беспроблемно: та же заглавно названная функция, минус конструктор, минус this

Код на полноценном толстом классе будет пожирнее. Я не к тому, что меня особо волнует классы или не классы. Для меня вообще принципиальной разницы нет. Просто функции-конструкторы я начал использовать чаще классов за последнее время, и выглядит это довольно естественно и беспроблемно: та же заглавно названная функция, минус конструктор, минус this

Они поддерживают приватные свойства

Кстати, в rxjs7, который еще не вышел, отказались от них с целью минимизации веса бандла. В версии 6 ушли в сторону pipe(...operators) вместо .operator().operator()... из-за проблем с декомпозицией функционала в контексте классов и худшего тришэйкинга (автор библиотеки об этом рассказывал на выступлении)

В 7й версии теперь Observable/Subject будут создаваться без new (хотя техничечки с new вернется все тот же непримитив - plain API object :) )

https://www.npmjs.com/package/constructor-decorator

с тайпскриптом это не нужно

с тайпскриптом это не нужно

Это работает в рантайме в отличие от TS

А кстати почему нельзя все входные параметры просто засунуть в словарь

Это работает в рантайме в отличие от TS

этим это и плохо

тут какая-то рантайм валидация для бедных

Мне нужна рантайм

Пользователь будет создавать классы

это не будет типизироваться

Будет

Уже типизируется

это не будет типизироваться

Я имею в виду, тс/флоу тайпинги для своей либы ты не сможешь написать.

Я и не собираюсь

Эх, как же всякие популярные библиотеки обходятся без рантайм чекинга типов аргументов конструктора, вот дураки

Эх, как же всякие популярные библиотеки обходятся без рантайм чекинга типов аргументов конструктора, вот дураки

Ограниченные

Не говори

Я в целом думаю, что статическими типами можно покрыть внутреннюю кодовую базу проекта и быть уверенным в соответствии всех входных/выходных типов данных (у классов, методов, функций). Вот на внешние api динамические проверки уже как раз совершенно востребованы

Ну это в целом лишь мои наблюдения

для внешних можно взять нормальные либы для валидации

Да

Я о том же

А внутри если используется ts/flow, tdd, то проблем не должно быть

У меня больше половины внешних данных. Тонкий же клиент

Я не понимаю, почему все так парятся с клонированием?

Ведь javascript clone = (obj) => { const newObj = {} for (val in obj) { newObj[val] = obj[val] } return newObj }

Ведь javascript clone = (obj) => { const newObj = {} for (val in obj) { newObj[val] = obj[val] } return newObj }

https://www.npmjs.com/package/constructor-decorator

Ты придумал свой prop-types и ducktype? Зачем?

Ведь javascript clone = (obj) => { const newObj = {} for (val in obj) { newObj[val] = obj[val] } return newObj }

это очнь корявый shallow clone

ничем не лучше { ...obj } или Object.assign. Я бы даже сказал хуже, так как не учитывает Symbols

Ведь javascript clone = (obj) => { const newObj = {} for (val in obj) { newObj[val] = obj[val] } return newObj }

- обычно парятся с deep clone - тут нет проверки hasOwnProperty

Ну это на коленке сходу

- обычно парятся с deep clone - тут нет проверки hasOwnProperty

И комирование символов

ничем не лучше { ...obj } или Object.assign. Я бы даже сказал хуже, так как не учитывает Symbols

Окей

Знал что есть подвох))

Я смотрю ты любишь велосипедирование

Ну это на коленке сходу

твой код выдаст {} из new Date()

твой код выдаст {} из new Date()

+ регулярки он тоже не склонирует

Я смотрю ты любишь велосипедирование

Даже зимой катался ))

Ведь javascript clone = (obj) => { const newObj = {} for (val in obj) { newObj[val] = obj[val] } return newObj }

https://stackoverflow.com/a/728694

Но самая жеть конечно, когда пишут JSON.parse(JSON.stringify(a));

https://stackoverflow.com/a/728694

Функции это держит?

А вот за такое бъют долго и больно)

https://stackoverflow.com/posts/9772788/revisions

А вот за такое бъют долго и больно)

Ога жесть )))

Ты придумал свой prop-types и ducktype? Зачем?

Там же в ридмихе написано зачем.

Там же в ридмихе написано зачем.

Чем второе лучше, чем первое?

Чем второе лучше, чем первое?

Оно короче и будет выдавать ошибку при несовпадении типа

Оно короче и будет выдавать ошибку при несовпадении типа

Оно нихрена не короче. 2 символа погоды не делает. А насчёт ошибок - сомнительная выгода, имхо. Но ладно. Каждый дрочит как он хочет.

Оно нихрена не короче. 2 символа погоды не делает. А насчёт ошибок - сомнительная выгода, имхо. Но ладно. Каждый дрочит как он хочет.

Но если дописать в первое проверку на типы, оно будет длинее намного

Но если дописать в первое проверку на типы, оно будет длинее намного

Рантайм проверка типов нужна мало где. И уж точно не в конструкторе классов.

Рантайм проверка типов нужна мало где. И уж точно не в конструкторе классов.

Но я буду создавать классы в рантайме

Но я буду создавать классы в рантайме

А для чего, если не секрет?

Но я буду создавать классы в рантайме

Почему ты не можешь взять нормальную либу для рантайм валидации?

А для чего, если не секрет?

Для того, чтобы добавлять новые звенья системы на лету.

Почему ты не можешь взять нормальную либу для рантайм валидации?

А чем то что есть не нормально?

Для того, чтобы добавлять новые звенья системы на лету.

Аддоны в систему?

Новые инстансы классов

В чем проблема то?

Нельзя уже new делать?

Проблема в том, что когда ты делаешь: class TypedEntity extends BaseClass { get args () { ... } } ты уже не можешь наследоваться от другого класса. К тому же я не могу понять зачем геттер экземпляра используется? В prop-types ты хотя бы можешь сделать так: class TypedEntity extends Component { static props = { ... } } тоже не ахти, но хотя бы более идеоматично и удобно, потому что ты можешь props вынести за пределы класса

У меня classProperties нету.

У меня classProperties нету.

У тебя нету бабеля, а пишешь ты для IE11?