Тебя здесь скорее всего никто не понимает, либо пиши как норм люди либо продолжай юзать ангулярд

Я юзаю и то, и то

Основные фичи тайпскрипт как раз относятся к ООП

Не правда! Ну или я плохой разработчик недопонимаю чего

Я юзаю и то, и то

Это не значит что концепции фреймворка А применимы в В

Кроме ООП нет способов решить проблему?

Есть, но это вопрос вкусовщины и устоявшихся практик в компании. У нас ООП код пишут. Вот я и спрашиваю, как правильно писать с точки зрения реакта, но оставаясь в ООП парадигме

Есть, но это вопрос вкусовщины и устоявшихся практик в компании. У нас ООП код пишут. Вот я и спрашиваю, как правильно писать с точки зрения реакта, но оставаясь в ООП парадигме

Отказаться от этой парадигмы

опять срачи за опп и тайпскрипт?

Не правда! Ну или я плохой разработчик недопонимаю чего

Классы, интерфейсы, обобщения - это все про ООП

Отказаться от этой парадигмы

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

Основные фичи тайпскрипт как раз относятся к ООП

ЧТООООО

Классы, интерфейсы, обобщения - это все про ООП

Нет не про ООП

Классы, интерфейсы, обобщения - это все про ООП

Реакт прекрасно работает без классов вообще

Вот ща у меня взорвется

Это не значит что концепции фреймворка А применимы в В

Вот поэтому я и спрашиваю, что применимо в случае реакта

Вот поэтому я и спрашиваю, что применимо в случае реакта

Если есть сср то пускай синглтон через контекст, если нет то импорты

Нет не про ООП

А про что? Эти концепции прямо из мира ООП

Классы, интерфейсы, обобщения - это все про ООП

Интерфейсы и дженерики (параметрический полиморфизм по научному ) вообще никак от ООП не зависят

Интерфейсы в тс имеют мало общего с интерфейсами в ооп джавы\сешорпа

В тайпскрипте это инструмент утиной типизации

По факту это не интерфейсы, а "схемы"

В тайпскрипте это инструмент утиной типизации

молодой человек, эко вас понесло

В TS вообще говоря в основном структурная типизация продвигается как принято в мире Джаваскрипт а не номинальная как в мире ООП

Интерфейсы и дженерики (параметрический полиморфизм по научному ) вообще никак от ООП не зависят

Интерфейс имеет непосредственное отношение к ООП, эта концепция там и возникла

Чтобы сразу вернулся результат

Ты явно не тот Климов, да xD

Интерфейс имеет непосредственное отношение к ООП, эта концепция там и возникла

Ну конечно

По факту это не интерфейсы, а "схемы"

Правильно, так как в рантайме их нет, они только для удобства кодирования

А ооп тут причем тогда?

В TS вообще говоря в основном структурная типизация продвигается как принято в мире Джаваскрипт а не номинальная как в мире ООП

Структурная, верно

Пишем на тс+реакте в чисто функционально стиле

Чувствуем себя отлично

молодой человек, эко вас понесло

это как раз инструмент ее преодоления, статический на этапе описания. И про то что интерфейсы имеют мало общего - тоже такое себе утверждение

Пишем на тс+реакте в чисто функционально стиле

Вот не нравится мне так, хочу в ООП-стиле

Пишем на тс+реакте в чисто функционально стиле

И мы так же и все живы, кроме юниров но они подтягивают знания

И мы так же и все живы, кроме юниров но они подтягивают знания

А что же ты тогда не на Elm пишете? Вот там тру функциональщина

Вот не нравится мне так, хочу в ООП-стиле

Ну ваше право... но у нас тут таких не любят, в смысле что в мире реакта не принято использовать ООП подход, и тому есть объяснение

А что же ты тогда не на Elm пишете? Вот там тру функциональщина

а что же ты на джаве не пишешь))

Ну ваше право... но у нас тут таких не любят, в смысле что в мире реакта не принято использовать ООП подход, и тому есть объяснение

Это как религиозный культ

А что же ты тогда не на Elm пишете? Вот там тру функциональщина

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

Это как религиозный культ

ООП это культ

а что же ты на джаве не пишешь))

На шарпах потому что пишу)

ООП это культ

+

ООП это культ

Для кого-то да, для меня просто инструмент

Для кого-то да, для меня просто инструмент

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

Ну ваше право... но у нас тут таких не любят, в смысле что в мире реакта не принято использовать ООП подход, и тому есть объяснение

Какое объяснение этому?

Для кого-то да, для меня просто инструмент

Ну тогда пишите как вам нравится, тайпскрипт вас не ограничивает, но в реалиях реакта вас ограничит другое...

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

что значит нет проку? Я видел проекты в ООП-стиле на реакте, все работало

что значит нет проку? Я видел проекты в ООП-стиле на реакте, все работало

я про твой изначальный вопрос Так-то если хочется использовать ООП вместе с реактом, то пожалуйста, никто не запрещает. Реакт хоть и продвигает некоторые фп принципы, но не настолько opinionated, чтобы их навязывать

Ок, изначальный вопрос, как правильно писать сервисы?

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

Без классов, тупо набор функций в файле?

Без классов, тупо набор функций в файле?

идеально

Какое объяснение этому?

Надеюсь не потеряется среди срача ответ. Объяснение довольно простое, ООП это один из способов инкапсуляции поведения и состояния...в объекты (не говорю про классы, потому что это исторически более позднее изобретение не являющее необходимым атрибутом ООП). Так вот, в реакте единица собирающая в себе поведение и состояние - компонент реакта, и от этого пляшут и строят архитектуру.

Компонент реакта нормально делать в виде класса

Без классов, тупо набор функций в файле?

А функция обязательно в классе должна быть? Даже такая как parseInt скажем? Вот это уже ООП головного мозга, без обид, простите

А функция обязательно в классе должна быть? Даже такая как parseInt скажем? Вот это уже ООП головного мозга, без обид, простите

В классе должны быть методы, соответствующие контракту сервиса

Компонент реакта нормально делать в виде класса

Делайте, но развитие реакта идёт по другой ветке, в сторону функциональных компонентов и хуков

В классе должны быть методы, соответствующие контракту сервиса

А теперь по-русски можно?

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

А теперь по-русски можно?

Контракт=интерфейс

В классе должны быть методы, соответствующие контракту сервиса

Простите ещё раз, имхо у вас паттерны Энтерпрайз приложений в голове

Контракт=интерфейс

Что если нет сервиса, просто функция — принимает строку и отдает отформатированную строку?

Простите ещё раз, имхо у вас паттерны Энтерпрайз приложений в голове

Как что-то плохое)

Класс форматтер ебашить?

Контракт=интерфейс

В чем разница можете пояснить? Чисто для того чтобы на одно языке общаться

Что если нет сервиса, просто функция — принимает строку и отдает отформатированную строку?

Тогда это не сервис, а просто утилитный метод

Это не метод а функция, давно пора привыкнуть что во всех адекватных современных языках функция это first class citizen

Тогда это не сервис, а просто утилитный метод

хаха "метод" :)

Тогда это не сервис, а просто утилитный метод

А что такое сервис тогда? Я без подьеба спрашиваю, просто интересна ваша позиция тут

В чем разница можете пояснить? Чисто для того чтобы на одно языке общаться

Я использовал слово контракт, чтобы подчеркнуть, что клиент класса ожидает от класса некоторой функциональности, и такое соглашение закрепляется как раз в виде интерфейса

Привет, подскажите, есть ли аналог for in в рендере реакта? Ко мне с сервера приходят данные в виде объекта с вложенными в него объектами, и мне нужно отрендерить данные в этих вложенных объектах. На for in реакт огрызается, получается надо перегнать этот объект в массив с объектами? Или как?

Ну вот в TS type описывает интерфейс или контракт?

Это не метод а функция, давно пора привыкнуть что во всех адекватных современных языках функция это first class citizen

Да, в данном контексте слово функция более уместно, признаю

Привет, подскажите, есть ли аналог for in в рендере реакта? Ко мне с сервера приходят данные в виде объекта с вложенными в него объектами, и мне нужно отрендерить данные в этих вложенных объектах. На for in реакт огрызается, получается надо перегнать этот объект в массив с объектами? Или как?

Array.prototype.map извиняюсь не прав, у вас объект значит что-то типа Object.entries

А что такое сервис тогда? Я без подьеба спрашиваю, просто интересна ваша позиция тут

Повторно используемая логическая единица, содержащая функционал, не связанный напрямую с рендерингом и UI.

Ну вот в TS type описывает интерфейс или контракт?

Type это тип)

Привет, подскажите, есть ли аналог for in в рендере реакта? Ко мне с сервера приходят данные в виде объекта с вложенными в него объектами, и мне нужно отрендерить данные в этих вложенных объектах. На for in реакт огрызается, получается надо перегнать этот объект в массив с объектами? Или как?

for in это конструкция языка, а не библиотеки или фреймворка

Я использовал слово контракт, чтобы подчеркнуть, что клиент класса ожидает от класса некоторой функциональности, и такое соглашение закрепляется как раз в виде интерфейса

в контексте опять же твоего вопроса — когда у тебя набор функций, то ничто не мешает поменять их реализацию, не тронув сигнатуру В том как бы и прелесть функций

Повторно используемая логическая единица, содержащая функционал, не связанный напрямую с рендерингом и UI.

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

в контексте опять же твоего вопроса — когда у тебя набор функций, то ничто не мешает поменять их реализацию, не тронув сигнатуру В том как бы и прелесть функций

Прелесть иметь разные реализации одновременно, а не менять постоянно

Прелесть иметь разные реализации одновременно, а не менять постоянно

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

Прелесть иметь разные реализации одновременно, а не менять постоянно

Все это достигается внезапно и без классов