Любая функция, скажем CelsiusToFharenheit сюда подходит стало быть

а в чем проблема?

ООП не единственный и далеко не всегда самый удобный подход к разработке

Подходит. Но я бы объединил такие функции в какой нить ConvertionService и использовал бы его как единую точку входа

Но в терминах объектов удобно думать

Я вас может не понимаю, с утверждением выше я согласен, но я так понимаю вы предлагаете делать этот conversion service классом?

Вы предложили менять реализацию

Да

Да

нет, это ты про замену реализации сказал, а я рассказал как это сделать) А если задача две реализации одновременно иметь, то просто создаётся второй файл 🤷‍♀️

Как я передам компоненту либо тот, либо тот функционал? Не оба сразу, а какой-то один

DI

Подходит. Но я бы объединил такие функции в какой нить ConvertionService и использовал бы его как единую точку входа

А почему не модулем который экспортит эти функции? Ну так же проще банально

Через props

Модуль не реализует интерфейс. Модуль не умеет создавать параметризованные версии себя, а класс умеет

Как можно передать модуль? Можно передать конкретный объект

представляю interface ConversionService { celsiusToFahrenheit() {} htmlToPdf() {} vgaToDVI() {} }

Будешь курс рубля подменять?

Подменять апи доступа к данным

Модуль это объект

Опят же не проблема вроде как, классы тут не нужны

Опят же не проблема вроде как, классы тут не нужны

нооо как бы DI напрашивается

А я не говорил что надо импортировать этот модуль напрямую где исползуешь, как раз его и инжектировать

Они никогда не нужны, если так рассуждать. Но удобны

А я не говорил что надо импортировать этот модуль напрямую где исползуешь, как раз его и инжектировать

Иногда... там где удобны. Но лепить ООП ради ООП глупо

Как инжектировать?

Ну через props скажем или context api

НЕ используя типы? Просто как any?

Почему же, можете (я так и делаю) типизировать

Как типизировать модуль?

Объект тут я имею ввиду не инстанс класса если что, а просто ассоциативный массив

Это утиная типизация какая-то. Структурная, да. Мне больше по нраву явная

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

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

Подменять апи доступа к данным

Явная в смысле номинальная как в шарпе и яве? Но это вопрос принятых в языке норм, в js/ts исторически структурная типизация используется

Это уже другая постановка вопроса )

При использовании классов, она мимикрирует под номинальную.

тут как бы в корне подход другой принят допустим есть компонент <PaymentForm /> Ты хочешь, чтобы этот компонент как-то обратился к сервису Payment, у которого бы последовательно дёргал условные методы типа authenticateUser, confirmPhoneNumber, verifyEmail, sendPayment И конечно тебе хочется иметь возможность этот сервис Payment подменять В более фп подходе с компонентами принято несколько по-другому, что-то вроде такого <Payment onAuth={data => /* handle auth */} onConfirmPhoneNumber={/* handle phone number confimration */} onVerifyEmail={/* handle email verification */} onSendPayment={amount => /* send payment */} {...otherImportantConfigurationProps} /> я наспех набросал, но хоупфулли мысль понятна И в таком случае не составляет труда использовать <Payment /> в разных местах, передавай ему разные хэндлеры бизнес-логики

Эти вопросы уже решены в ООП-подходе. Что мешает его использовать? Идеологическая неприязнь?

Не мимикрирует если я вас понял верно, но ею и является (мы же про тайпскрипт все еще?)

Про Typescript. По сути мимикрирует, так как в рантайме нет никаких интерфейсов, в отличие от языков типа C#

Очень может быть, что эти методы должны быть семантически связаны между собой. А так мы можем один метод передать, взяв его из сервиса A, другой из сервиса B. Получится несогласованность, но на этапе написания кода это не будет видно

В рантайме нигде нет вроде как

В C# в рантайме можно рефлексией доставать интерфейсы явно, в js же нет такого понятия в принципе в рантайме

Это все компайл тайм проверки

С точки зрения CPU так вообще никаких типов нет

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

Нет, рантайм тоже

Не знаком с си шарп, но неужели оно делает какие-то поверки в скомпилированом байткоде?

Можно тупо создать объект по имени строки класса, которая приходит извне. Понятно, что нельзя на этапе компиляции это проверить

C++ просто вот не делает:( я по нему сужу

Интересно как это там реализовано, метаинформаиция о типах стало быть там сохраняется после компиляции?

Спасибо за дискуссию, спать пойду )

или создать workspace из нескольких react приложении?

В общем если подытожить наши споры, в мире фронтенда реактового как-то люди вполне себе делают крутые вещи без протягивания, а порой даже без представления о таком понятии как ООП. Это как минимум повод задуматься, а действительно ли стоит один в один подходы переносить. Не подумаете что хочу тут высказаться в стиле ООП сосет, но вот факт - делают без него крутые фронтенды.