FRP более высокого порядка с React - почему этого не происходит?

Redux - это своего рода FRP первого порядка, например, как Elm.

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

Почему FRP первого порядка, полезный с React и более высоким порядком, не так полезен?

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

Другими словами:

React - это функция, которая принимает состояние и возвращает представление.

FRP - это способ объявить и выполнить конечный автомат.

Это ортогональные проблемы, поэтому почему бы не объединить их?

EDIT:

Если я сравню этот https://github.com/ochrons/diode/tree/master/examples/todomvc/src/main/scala/example

с этим https://github.com/lihaoyi/workbench-example-app/blob/todomvc/src/main/scala/example/ScalaJSExample.scala

Тогда кажется, что одно и то же приложение, использующее scala.rx, в два раза меньше строк кода... чем у Diode (Redux, как однонаправленная библиотека потока данных).

ИЗМЕНИТЬ 2:

Мое предположение - почему этого не происходит - то, что большинство людей из ФРП более высокого порядка (которые хотят использовать FRP более высокого порядка в веб-разработке) используют reflex-frp, и вместо этого они реагируют на рефлекс-dom. Вероятно, рефлекс-дом делает ненужным.

Ответ 1

EDIT: На мой взгляд, я считаю, что большая проблема с концепциями FRP React и высшего порядка заключается в том, что , взаимодействующий с компонентами Inside внутри React, предоставляет пользователям понятий языка, которые не являются тем, что касается HO FRP, в моем мнение, я считаю, что это также более широкая проблема ES6 JS. Я не эксперт по этому вопросу, но я делюсь своими мыслями и опытом с моим путешествием по FRP.

Множество функциональных возможностей и состава компонента React зависит от синтаксиса JS class. Для меня это вызов, потому что вы смешиваете терминологию и концепции. Для многих разработчиков интерфейса (включая меня) React был их первым знакомством с парадигмой FRP. Трудно понять важность функционального состава, когда вы постоянно изучаете терминологию наследования ООП с помощью classes и constructors. Я думаю, это объясняет, почему мы видели этот взрыв с библиотекой React и не столько базовыми парадигмами, сколько цельной смесью контрастной терминологии. Это стало больше о компонентах и DOM-ориентированном представлении, в отличие от FRP Прочтите этот аккуратный небольшой пост.

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

В моем сознании, когда речь идет о состоянии, Реакт должен по существу быть только для чтения. Рассматриваемые как таковые, React и Redux становятся ортогональными. Redux гораздо более искажен в отношении концепций FRP и фактически при использовании таким образом становится гораздо более декларативным.

const mapStateToProps = (state, ownProps) => {
  return {
    id: ownProps.id,
    someData: state.projects.someData,
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onSubmitForm(data) { //our callback
      dispatch( //redux dispatch function
        someAction(data) //our Redux Action Creator
      )
    }
  }
}

export default connect(mapStateToProps,mapDispatchToProps)(PresentationComponent)

и в нашем презентационном компоненте

const PresentationComponent = ({onSubmitForm, id}) => {
    return <form id="someForm" onSubmit={(e) => {
        e.preventDefault()
        onSubmitForm(getFormData(id))
    }}>
}

С помощью функции Redux HO connect(), mapStateToProps() и mapDispatchToProps() она позволяет использовать чисто функциональные компоненты, которые просто принимают состояние и методы в качестве аргументов. Эти методы могут существенно вернуть что-либо. Это, безусловно, связывает гораздо более чистую концепцию высшего/первого порядка и FRP.

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

В Dan Abramov прагматичный сообщение о Redux он напоминает нам, что нам не всегда нужно просто придерживаться одного инструмента и зависнуть по одной парадигме, это не то, что я против ООП. Я регулярно использую фабрики и объектно-ориентированные концепции, я просто думаю, что это немного запутывает использование терминологии из ООП, а затем начинает говорить о FRP на одном дыхании.

Что-то посмотреть

Как упоминалось в комментариях, cycle.js определенно стоит посмотреть. Это хороший баланс между декларативной и многоразовой конструкцией React, смешанной с преимуществами таких понятий, как потоки данных и наблюдаемые в RxJS.

Это мои два цента, мне бы хотелось услышать, есть ли у кого-нибудь другой вход?

Ответ 2

Так как машина redux + twitter + medium = hype, которая продвигает не архитектурные шаблоны, которые заставляют людей думать, что fp - дерьмо