Поэтому проще

Смотрю тут сколько народу и думаю уже пора с ангуляра соскакивать

а кто будет бесконечные тонны легаси кода поддерживать? :)

а кто будет бесконечные тонны легаси кода поддерживать? :)

А я вообще к фронту редко прикасался. Но в последнее время, 80% работы(

Проблема в том, что при добавлении элемента в поле-массив, пропсы внутренней формы (<Form ...> на скриншоте) не обновляются.

Кто-нибудь сталкивался?

А я вообще к фронту редко прикасался. Но в последнее время, 80% работы(

у вас процент сломался

блин один инпут и 50 строк кода что бы с него что-то послать не перебор какой-то

Это ещё вы Redux не тыкали, там ещё строк 50 написать придётся. Хотя если взять MobX, то поменьше писать придётся.

ну вплане нафига вообще использовать тут не createClass подход )

ES6 - будущее, createClass - костыль для тех у кого это будущее ещё не наступило + автобиндинг.

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

В идеале, следуя подходу Реакта, ВСЕ данные, связанные с UI должны храниться в некотором стейте или стейтах отдельно от DOM, хотя React позволяет этого не делать, а использовать refs/event.target. Вообще в идеальном мире, как мне кажется, весь UI представляет собой чистую функцию (stateless компонент) от state и actions, которая возвращает виртуальный DOM, где actions - это набор функций, которые вызывают изменения state и/или взаимодейстуют с сервером. При таком раскладе state полностью определяет UI. Собственно, если использовать Redux или MobX и не использовать state из React, то будет как раз такая штука.

ES6 - будущее, createClass - костыль для тех у кого это будущее ещё не наступило + автобиндинг.

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

я про ES6 class

Сидят такие TC39 и думают: "как бы нам ява разработчикам угодить?"

это не так работает

но сути не меняет

есть тренды и TC39 им следует

Тренд на ООП лет 10 назад закончился

Сейчас по трендам надо стандартную библиотеку на монадах делать

расскажи это ява и c++ программистам

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

Совершенно не согласен. Зависит от точки зрения. Можно считать, что прототипное наследование - это лишь детали реализации классов.

расскажи это ява и c++ программистам

А их уже нет, они на js все пишут

Тренд на ООП лет 10 назад закончился

Не в этой вселенной. Сейчас идёт тренд на совмещение ФП и ООП.

да, и у них получается ява вместо идиоматического жс

вот реально если бы этого class не было может быть хоть что-то бы дошло а то им кажется, что это действительно классы

всем typescript

Сейчас по трендам надо стандартную библиотеку на монадах делать

И много Хаскеля в продакшене? И сколько сайтов на Elm написано?

да это ж явно ирония была )

И много Хаскеля в продакшене? И сколько сайтов на Elm написано?

А когда-то говорили: "И много Смоллтолка в продакшене? Сколько баз данных на Симуле написали?"

ошибочно полагать, что лучшие технологии это самые популярные

А когда-то говорили: "И много Смоллтолка в продакшене? Сколько баз данных на Симуле написали?"

так и сейчас Смоллтолка в продакшене и не найти

когда он появился его дофига в продакшне было

есть чуть-чуть

http://www.wonderzine.com/wonderzine/life/life/214569-welcome-to-the-real-world

Смысл в том, что рыба гниет с головы. Тренды начинаются в околоакадемических кругах, а через десяток лет уже в энтерпрайз просачиваются, в искажённом до неузнаваемости виде. Академики на ООП давно забили.

сорян

не тот буфер обмена

момент

https://montykamath.wordpress.com/smalltalk-companies/

ошибочно полагать, что лучшие технологии это самые популярные

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

о!

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

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

ну и маркетинг не стоит забывать

конечно всегда есть положительные стороны

типа jvm у java

Вообще, я считаю, что на данный момент ничего лучше смеси ООП и ФП не придумали.

Именно смесь, а не чистое ООП или чистое ФП.

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

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

а смеси ООП и ФП несколько десятков лет сейчас конечно в гору эта тема пошла

впрочем ООП с наследованием нафиг не нужен

и инкапсуляция сомнительная штука

ого

впервые вижу, что кто-то называет инкапсуляцию сомнительной штукой

да ладно

нас много :)

ООП критиковали и критикуют, наследование критиковали и критикуют, полиморфизм критиковали и критикуют, ФП критиковали и критикуют, но чтобы инкапсуляцию критиковали - это что-то новое

Очень интересно посмотреть на ООП без наследования и инкапсуляции.

ну здрасте приехали это основная проблема в ООП

это в каком же месте?

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

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

Основа всякого программирования - абстракция и декомпозиция, то есть разбиение на куски кода - функции (чистые или нет - это уже детали). И тогда естественно желание открыть часть этих функций для использования только внутри некоторых других функций, а не всех.

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

в правильном ООП есть такая штука как интерфейс, который НЕ ЗАВИСИТ ОТ РЕАЛИЗАЦИИ

а реализация зависит от интерфейса

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

ERROR: S client not available

интерфейсы никак эти проблемы не решают

просто не имею отношения к этой проблеме

как раз таки решают

если есть интерфейс, то даже не важно мутабельный стейт в этом объекте или нет

это всегда важно

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

интерфейс не гарантирует отсутствие ошибок иммутабельность этого тоже не гарантирует, но сделать их становится намного сложнее

да причём тут иммутабельность и инкапсуляция??? если брать интерфейс как в Java или C# - набор абстрактных методов без реализации, то это и есть некий почти абсолют инкапсуляции, когда принципы реализации скрыты ПОЛНОСТЬЮ

то есть ты веришь в то что тебе на тарелочке кто-то выдаст гарантированно и всегда работающую черную коробку?

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

то есть ты веришь в то что тебе на тарелочке кто-то выдаст гарантированно и всегда работающую черную коробку?

я верю в то, что я сам смогу сделать такую чёрную коробку

сделать и забыть

помня только об её интерфейсе

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

не будет

будет

если мутабельные структуры небольшие

ок

как скажешь

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

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

логику ответа?

поясни

ок

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

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

в компонентах следует писать только UI

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

я про монады ничего не говорил и про то что считаю pure FP решением тоже

я про монады ничего не говорил и про то что считаю pure FP решением тоже

так что же будет решением?

так что же будет решением?

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

логику ответа?

у меня есть хелпер utils/loginHelper.js и есть компонент в котором в функции onSubmitHandler я передаю значения полей в этот хелпер. когда приходит ответ я через promises в onSubmitHandler уже определял там ошибка пришла из хелпера (response status или timeout) или пришел ответ что бы знать что рисовать на экране. это правильно?

так что же будет решением?

но кстати для кого-то монады решение я туповат наверное для этого

у меня есть хелпер utils/loginHelper.js и есть компонент в котором в функции onSubmitHandler я передаю значения полей в этот хелпер. когда приходит ответ я через promises в onSubmitHandler уже определял там ошибка пришла из хелпера (response status или timeout) или пришел ответ что бы знать что рисовать на экране. это правильно?

теоретически не совсем, но практически скорее всего правильно