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

Последнее время я прихожу к мнению, что люди, копающиеся в технологиях, типа сайкл и подобных, и тусующиеся в их чатах - это просто ПРОКРАСТИНАТОРЫ.

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

типы значит кривые

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

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

Такой магии тоже в популярных функциональных либах хватает. У того же recompose так ведет себя один из самых частоиспользуемых методов - “withState”.

Такой магии тоже в популярных функциональных либах хватает. У того же recompose так ведет себя один из самых частоиспользуемых методов - “withState”.

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

Это последствия влияния языка — тут такие вещи делать удобно, помноженное на отсутствие типизации: даже самые популярные либы редко когда делались сразу с расчётом на неё

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

а что не так)

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

чо они там творят в своем flow? https://github.com/facebook/flow/commit/ab9bf44c725efd2ed6d7e1e957c5566b6eb6f688

то есть теперь есть специальный тип $Compose ?

ну да

в тс до сих пор спред типы не впилили(

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

юзаю Ramda

R.ap([f1, f2], ['a', b'])

но функции от двух аргументов, какие красивые идеи есть на этот счёт кроме временного каррирования ?

converge/useWith?

R.converge(R.concat, [R.toUpper, R.toLower]) - спасибо )

Хочу написать форму с апдейтером, с типа локальмым редюсером/апдейтером

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

типа formUpdater = compose(validator, touchedProps, updater)

принятый в редюсерах подход - не позволяет добиться композиции

редюсеров

из-за не каррируемого типа State Action -> State

помещать экшон в ридер и использовать chain (composeK в твоем случае), лол

насколько адекватно заменить редюсер моноидом {State, Action} => {NewState, Action}

не понял...

Глянь redux observable

мне категорически не нужен redux

только апдейтер )

ну так возьми просто rx

или most

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

На мелкие стримы разбито

мне нужно форкать состояние в формах от редакс стора

Минусов не нахожу

и там много всякого происходит. Замусоривать стор touched/ focused - не вижу смысла

Да да вот глянь там все это есть в rx

вот например https://github.com/xgrommx/most-reactive-flux

хм.... ушёл думать

Вы юзали xreact который react-most ранее? Или говорили о самом most?

я юзал чистый мост

Для решения проблемы разделения обработки локального стейта от рендеринга. Вынесения логики в hoc. Не понимаю профита от RFP над простым апдейтером . Например тут https://medium.com/javascript-inside/elm-architecture-for-react-part-2-73e73d9a6a89

Какие профиты неочевидны нубу в FRP?

RFP?

FRP most/rx

FRP нет в js

просто RP

Минусов не нахожу

Заведомо асинхронные апдейты могут оказаться очень некстати)

То есть между двумя биндами у тебя например гарантированно успеет пролететь апдейт всего redux стора

Этот кейс уже словил, специально)

Но можно форкнуть стрим, и прибить весть HOC вместе с ним по апдейту

то есть теперь есть специальный тип $Compose ?

Даа) Просто это неплохо так поможет им выводить тип реакт-хоков

вот это задержка)

Ага

Но можно форкнуть стрим, и прибить весть HOC вместе с ним по апдейту

У меня короч в итоге получился сложный кейс когда желательно бы успеть более чем один chain без перехода к асинхронному исполнению кода И тут я со стримами влип ?

И что ты бы выбрал сейчас?

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

И что ты бы выбрал сейчас?

Ну я от них и не отказываюсь так то

Просто добавил себе такие же чейнящиеся структуры, но синхронные

Maybe, Either, Reader

Окей, и юзаешь редакс-мост? А что если всё-таки нужен локальный стейт компоненту?

вот

Окей, и юзаешь редакс-мост? А что если всё-таки нужен локальный стейт компоненту?

Делай локальный стейт)

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

ERROR: S client not available

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

глобальный стор - архитектурная ошибка

Для решения проблемы разделения обработки локального стейта от рендеринга. Вынесения логики в hoc. Не понимаю профита от RFP над простым апдейтером . Например тут https://medium.com/javascript-inside/elm-architecture-for-react-part-2-73e73d9a6a89

честно: не понимаю вообще твоей фразы, мб у неё контекст какой то был. Вообще прими как данность то что фрп это баззворд (не знаю как в пейперах, но в джс 100%) неприятно то что статью я тоже не понимаю. чел в джс переводит неоднозначно, да и постоянно желание потыкать на типы, посмотреть как объявлены

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

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

глобальный стор - архитектурная ошибка

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

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

вот тут как раз subjects/frp networks и решат

Неа

При реально большом объёме перекрестных ссылок это будет лапша

а какая проблема? перфоманс?

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

честно: не понимаю вообще твоей фразы, мб у неё контекст какой то был. Вообще прими как данность то что фрп это баззворд (не знаю как в пейперах, но в джс 100%) неприятно то что статью я тоже не понимаю. чел в джс переводит неоднозначно, да и постоянно желание потыкать на типы, посмотреть как объявлены

Вынести работу со стейтом компонента в хок

Ну например форма, форкает кусок стейта и пока не нажали сабмит, она в своём локальном стейте варится. Как нажали сабмит - отправила экшен в стор

а есть какая-нибудь хорошая книга или набор лекций по type theory?

а есть какая-нибудь хорошая книга или набор лекций по type theory?

TTFP, классика же

кто украинский тут знает?

TTFP, классика же

выглядит хорошо, спасибо

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

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

Бахнули компонент и все)

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

От какого глобального стора? Я отвечал на сообщение которое подразумевает, что его нет

http://eugenen.github.io/?ui=html#!blog/5431761c6544b261be05

советую почитать кто понимает украинский

и я сейчас на таком мини проекте пишу на хаскелль именно по такой архитектуре

там вро редакс и сайкл написано, и это не простой чувак написал

Ну я просто по своему опыту рассказываю

Вносить правки, менять направления веток и всё такое прочее в подобных масштабных схемах — эт ппц

уж лучше юзать много типа сторов и combineLatest где надо подмердживать их и все

зато монолитность уйдет

зато монолитность уйдет

Не должно быть монолитности, должен быть single point of truth

хотя там и так понятно