А JS впринципе работает на паттерне прототип

норм, только еще для NaN и null так не проверишь

NaN можно, null и undef нельзя

NaN можно, null и undef нельзя

с NaN подвох

https://refactoring.guru/ru/design-patterns/decorator

Ты когда говорил про создавать новые декораторы, ты имел ввиду паттерн?

с NaN подвох

Какой?

Ты когда говорил про создавать новые декораторы, ты имел ввиду паттерн?

да) Все готовое что видишь в языках например в питоне - это просто встроенная реализация паттерна)

да) Все готовое что видишь в языках например в питоне - это просто встроенная реализация паттерна)

Покажи пример нового декоратора, который создают новые на проекте люди

Покажи пример нового декоратора, который создают новые на проекте люди

ну если найду с прошлого проекта код, покажу На текущем благо таких индивидов нет

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

Не понял какой декоратор, я про функции-гарды

https://refactoring.guru/ru/design-patterns/decorator

Как этот паттерн относится к проверке типов?

Как этот паттерн относится к проверке типов?

-_- Делают декоратор, который добавляет проверку типов хоть даже как сверху гардов Ладно, я понял, проще пример написать

Как этот паттерн относится к проверке типов?

https://codesandbox.io/s/js-playground-forked-1rzkuo?file=/src/index.js

Вот такую фигню писали некоторые, вместо того чтобы нормальную либу взять)

https://codesandbox.io/s/js-playground-forked-1rzkuo?file=/src/index.js

Так это не декоратор, а прокси

Декоратор сначала выполняет действие, а к результату добавляет что-то своё

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

Не класс Proxy, а паттерн

У тебя как миддлварь почти работает

На самом деле, если делать чисто на классах прилку, то типизации конструктора достаточно. Даже и она не нужна нафиг, если честно. Комменты по JSDoc пиши и фсё

Так это не декоратор, а прокси

ок, спускаемся в детали. Что есть прокси а что есть декоратор? Если примитивным языком, то прокси нужен для контроля состояния без изменения в интерфейсе объекта, а декоратор добавляет новый функционал к объекту. В данном случае это декоратор. Он не контролирует состояние, а добавляет функционал для указанной в параметре функции

Делает обертку над функцией

Блин работа так прокачивает. Не понимаю, как можно было так долго сидеть и пилить простые пет проекты

На самом деле, если делать чисто на классах прилку, то типизации конструктора достаточно. Даже и она не нужна нафиг, если честно. Комменты по JSDoc пиши и фсё

Подходов тьма тьмущая) Почему-то на рынке преобладает именно typescript)

Подходов тьма тьмущая) Почему-то на рынке преобладает именно typescript)

Это не обёртка, а остановка, доп проверка и возможная остановка работы. Разве декораторы могут останавливать работу?

Я на него тоже в свое время плевался, но в итоге сейчас даже свои пет-проекты с ним пилю

Декораторы работают с результатом выполнения

Это не обёртка, а остановка, доп проверка и возможная остановка работы. Разве декораторы могут останавливать работу?

декоратор добавляет логику ДО исполнения функции. Еще до того, как она вообще вызвана будет. А прокси делает проверку во время исполнения. Можно сделать как через декоратор, так и через прокси, они принципиально не сильно отличаются.

А не с входными данными

декоратор добавляет логику ДО исполнения функции. Еще до того, как она вообще вызвана будет. А прокси делает проверку во время исполнения. Можно сделать как через декоратор, так и через прокси, они принципиально не сильно отличаются.

ПОСЛЕ

НЕ ДО

НЕ ДО

после инициализации функции, но до ее выполнения

Инициализации? Это как?

const someFunc = ()=>{} - проинициализировали someFunc decorate(somFunc) - добавили кода поверх someFunc proxy(someFunc) - подписались на какие-либо изменения someFunc И decorate и proxy, если прям грубо, добавляют код поверх функции. Вот только делают они это по разному.

Декоратор имеет альтернативное название — обёртка. Оно более точно описывает суть паттерна: вы помещаете целевой объект в другой объект-обёртку, который запускает базовое поведение объекта, а затем добавляет к результату что-то своё. Оба объекта имеют общий интерфейс, поэтому для пользователя нет никакой разницы, с каким объектом работать — чистым или обёрнутым. Вы можете использовать несколько разных обёрток одновременно — результат будет иметь объединённое поведение всех обёрток сразу.

proxy используют для объектов, а декораторы чаще для функций

Функция это и есть объект

в js да

мы вообще про теорию

Ну я покрайней мере

А в теории это паттерны ООП и применимы только к функциям (классам)

А в теории это паттерны ООП и применимы только к функциям (классам)

ох, ладно Кому нужно сами почитают, я устал писать на эту тему

А в теории это паттерны ООП и применимы только к функциям (классам)

к слову для ооп классы вообще не обязательны

к слову для ооп классы вообще не обязательны

Классов просто не существует

Это частный случай функции

А в теории это паттерны ООП и применимы только к функциям (классам)

в теории говорится про объекты, а не функции, особенно если говорить про прокси

object oriented и паттерны для работы с объектами

Хотя реализация идет через функции, классы и другие структуры языков

в теории говорится про объекты, а не функции, особенно если говорить про прокси

Чтобы создать объект тебе нужно вызвать функцию

Просто так объектов не бывает в ООП

Только в виде инстансов класса (функции-конструктора)

Чтобы создать объект тебе нужно вызвать функцию

и? это противоречи чему-то что я сказал?

и? это противоречи чему-то что я сказал?

Да

Да

чему?

Тому что паттерны для работы только с объектами. С созданием объектов (то есть функциями) тоже идёт работа. Возьми хотя бы композицию. Не бывает композиции объектов, это про функции

А в теории это паттерны ООП и применимы только к функциям (классам)

вообще-то к ФП паттерны тоже применимы

Немного другие

Немного другие

какие же?

ну вот часть тех же самых в статье например https://dev.to/patferraggi/do-you-need-design-patterns-in-functional-programming-370c

Кидаю статьи, тк самому долго и нудно писать

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

Я бы назвал это техниками. Они более низкоуровневые и участвуют в создании паттернов. Каррирование, композиция и тд

ну вот часть тех же самых в статье например https://dev.to/patferraggi/do-you-need-design-patterns-in-functional-programming-370c

Статьи я могу почитать в гордом одиночестве. Думаешь я не умею гуглить?

К тому же сайт этот говно. Большинство статей написано индусами с двумя репо на гх

За испанца ничего не скажу

Ладно, понятно, докапывайся дальше) Главное чтобы результат был)

Даже если мы выясним, что в той реализации это был прокси, а не декоратор, то ситуации это не измениит, тк обсуждали мы вообще другое. Я вижу что тебе просто докопаться охота и скучно. Так что я отваливаю, нет больше желания поддерживать пустой треп по теории

https://codesandbox.io/s/cold-firefly-d77ieh?file=/src/store/index.ts строка 10 метод на строке 24 Можешь описать их предназначение?

Даже если мы выясним, что в той реализации это был прокси, а не декоратор, то ситуации это не измениит, тк обсуждали мы вообще другое. Я вижу что тебе просто докопаться охота и скучно. Так что я отваливаю, нет больше желания поддерживать пустой треп по теории

.

Точнее смысл типизировать там

Кстати, я там часть типизации пропустил, ибо не работало

https://codesandbox.io/s/cold-firefly-d77ieh?file=/src/store/index.ts строка 10 метод на строке 24 Можешь описать их предназначение?

блин, vue и ts... Ну ок, щас гляну

Строка 10 что делает вообще?

блин, vue и ts... Ну ок, щас гляну

Такое тестовое

Я бы на JS лучше накатал

Часа три бы сэкономил. Мистер кстати мне помогал с этим

Ещё бесит что d.ts файлы попадают в глобальную область. В целом ТС — это кладезь хуёвых практик

блин, vue и ts... Ну ок, щас гляну

А ты видел я для телеги тайпинги спарсил со страницы апи?

Строка 10 что делает вообще?

генерируется уникальное значение имени для provide/inject, вот только смысла нет, тк не используется

генерируется уникальное значение имени для provide/inject, вот только смысла нет, тк не используется

А без него не работало