Usage discouragement in readme

[rusty-key]

Hi!

Sorry if what I am about to say is complete rubbish. I am new to reason and reason-react and maybe I just didn't grasp some basic concepts yet.

In the intro you are saying:

You might not need this library, especially so in a language which provides good enough construction blocks out of the box. ReasonReact already comes with reducers!

I don't understand this point. You are talking about built-in reducers like it is an alternative to a global state. But we are mainly using redux for managing app state, not a component state. In what way built-in reducers are the replacement for redux?

If I understand Dan's point that you referenced, he is not saying that you don't need redux. He is saying that you maybe don't need redux. But there are a lot of cases when you can benefit from using it.

And then later you are saying:

Hopefully, the above comparisons demonstrated that you might not need an extra-react state management technique at all; passing props down works well in Reason-React, and since props are well-typed, adding/remove them takes seconds. Keep state/props management simple so that you can spend the learning budget elsewhere!

We are using global state when an application starts to grow past the point when passing props down starts to be unhealthy, when you want your components to be agnostic to place and time. Imagine moving component from one part of your app to other. In redux-app you just moving it, that's it. In "classic-react-app" if you don't have single-global-compositor-component which basically have your global state, you have to tune something. Your middleman components have to know something that they don't need to know, just to pass some props down.

Am I missing something? Maybe you can elaborate a little bit more in your docs as to what real alternatives we have to reductive and why using reductive is counter-productive in reason-world?

It is kind of depressing to use a library that asks me not to use it and with bold font :)

[conartist6]

Not complete rubbish! Actually your bug report here is more informative than either the Reason or Reductive documentation as to what the limitations of Reason's reducerComponent are, what an application which opted not to use Reductive would look like, and what some indications for the use of Reductive might be.

[conartist6]

Also the more I think about this the more I disagree with the conclusion that Reductive probably isn't necessary.

If you just create a global compositor/store component, you are indeed stuck passing around global state as props through a chain of components that may not actually depend on them.

One of two things will happen:

• You'll pass the whole global state record around, and since it is immutable every component which uses it as a prop will now be forced to rerender whenever it changes.
• You'll pass parts of the global state record around individually, and while only some components will be forced to rerender needlessly you've now created a need for prop-passing boilerplate which, though typechecked, will only get worse as your app grows.

This wouldn't be particularly important for regular React, since most regular React components (React.Component and stateless functional components) rerender regardless of prop equality, but it is important to ReasonReact, which by design is meant not to have the fundamental problems that have forced regular React to be unable to make those optimizations.

[quicksnap]

This is a great discussion to be had!

I'm a huge fan of Redux. In my work, it has offered me these advantages:

Preventing prop-passing and unnecessary coupling via props

As mentioned, passing a bag of the entire state into a component which needs global state feels unwieldy. It tends to yield a pattern of every component in the app needing access to the global state object, which is unnecessary when we have React context.

Common idioms + Middleware

The redux community sharing ideas, patterns and libraries involving middleware have been a huge productivity boon for me. Examples have been things like redux-pack and homegrown API middlewares that originated from an example project. A new tool I've used recently was redux-first-router, which exposes a reducer/middleware/action-set that you can use in your app. Allowing libraries to take use a slice of your state/reducers has some real benefits.

Reductive could actually enable the same type of patterns. Leveraging Reason's extensible variants and possibly GADTs, there's nothing preventing Reductive from allowing third-party actions into the system while maintaining type safety.

Redux Devtools

This is simply something I cannot imagine living without on the frontend. It has saved me so much time, and made debugging my Redux application so much easier. Unfortunately, Reason+Bucklescript does not have the means for this yet. I've opened rescript-lang/rescript#2556, but there's so much work on Reason/Bucklescript core teams' plate as it is.

---

Redux enables the above patterns successfully. While ReasonReact may be able to prevent unnecessary re-renders while passing down the entire state object as a prop (or even as context), the common idioms and dev-tooling built around those idioms in Redux offer significant value to me.

I'm eager to improve this library, but I view it futile until there are dev-time printing mechanisms available in Bucklescript.

To the point of the bold warning that "you may not need this library", I feel it's meant to bring about critical thought like this as to what is state in this language and ecosystem, and how can we leverage these tools to come up with something better. I feel Reductive could evolve to take the best of both worlds (Redux and ReasonML), but there could be something even simpler and better that we think up.

[jeremyjh]

To the point of the bold warning that "you may not need this library", I feel it's meant to bring about critical thought like this as to what is state in this language and ecosystem

Well, this is a good warning that should be at the top of the Redux repository as well frankly. Small apps are better off with component state and newcomers to React should definitely start there.

What I get from the README, on the other hand, is "you don't need a state manager because Reason". This is confusing and frankly, just wrong. Nothing about Reason/OCaml changes any of the very excellent reasons articulated so well in this issue.

In fact, it makes the project look a bit out-of-touch with the purpose of a state management framework and makes me wonder if it is implemented correctly. For example are components only re-rendered when the part of the state graph they care about is changed? Since there is mention of no higher-order connect, and no acknowledgement that such a feature is desirable, I have to assume that no, this project doesn't understand why that feature would even exist, and I move on to the next language/framework.

[conartist6]

Oh jeez, I made a mistake, mostly because I'm looking at Reason from the perspective of thinking about using it, rather than as an experienced user already.

I thought Reason components would not adopt the React pattern of always rerendering no matter what. Unfortunately, they do. See https://github.com/reasonml/reason-react/blob/9e344b8a059ca82e88ca575bebc60abb9deac0d8/ReactMini/src/React.re#L134 and its usage just below.

So not using Redux/Reductive is just a performance bomb waiting to go off, for both React and ReasonReact. I'd put the warning on React instead (this library is just a child's toy without a state management utility!). A solid piece of JS infrastructure should be simple when used the recommended way: i.e. when you follow best practices it should shield you from the nastiest complexities of lower layers and you should get a performant app which you won't need to rewrite (as in the transition from setState to Redux) when your needs become more complex.

[jeremyjh]

@conartist6 From a quick read of reductive source I do not think it is going to do that for us either. It renders as long as the State is populated. react-redux accomplishes this render on changed state behavior through the higher-order connect component - this is why we have the mapStateToProps ceremony. Without that or something like it I don't see how the framework can know what data is actually being used in the component.

[conartist6]

I now agree @jeremyjh.

So the usage discouragement is actually a great point. There isn't any purpose or intent to what this code does.

Edit: aside from allowing Reason code access to state already stored in Redux, presumably by code not written in Reason, and to enable dev tools.

[JasoonS]

I haven't started using ReasonReact or Reductive (disclaimer), but I'm super glad I read this.

But it is true, writing mapStateToProps is a 'ceremony' that makes us conscious of what state we want in our components. Similarly working with this Reductive and making the app run efficiently would require people making a 'ceremony' of shouldUpdate method. Although it must me said that the ceremony for react-redux is to be favoured since it is explicit, whereas currently in Reductive such an optimisation is hidden and non-obvious.

So that seems it a bit of an extreme conclusion there, @conartist6 ?

There isn't any purpose or intent to what this code does.

[conartist6]

Well, you create the rather unpleasant issue that if you forget to adjust shouldComponentUpdate when you use a new piece of state data you'll get stale data.

However this does make clear to me one thing that Reductive does in this situation, which is to allow a child component to receive updates on a piece of state that their parent elected not to update on. If you were just passing your global state object around through props, that would not be the case.

[jeremyjh]

That's right. mapStateToProps doesn't ONLY let react-redux determine what has changed, it also enables your component to access the data it needs. While it could contain data you don't use, it is not possible for you to use data that react-redux doesn't know about. This isn't true for reductive.

[bonham000]

I agree with a lot of ideas presented here. ReasonReact looks very promising to me but the main limitation that I don't see clear answers for is how to manage large apps with complex state trees. Redux provides a strong answer for this in the traditional React world, which to me is not matched by managing app state in reducer components in ReasonReact.

The following are some of the main considerations I have which currently prevent me from considering ReasonReact for a complex app:

• Redux provides a pattern for managing global application state which is totally decoupled from the component/view layer of React. It is also very scalable for large applications because of composition. To me, this is a prerequisite for building a complex frontend application.
• Redux middleware allows developers to manage complex side effects and other logic in an isolated, decoupled layer. For example, redux-observable is very powerful for managing side effects in a way that is totally decoupled from the view and state app layers.
• Complex apps often have components which need specific derived state. In the Redux community there are libraries such as reselect which allow developers to write a "state derivation layer" which provides store state to components. This is very valuable.
• React-Redux allows components to be connected on an individual basis to the global application state, and allows developers to flexibly control how much or little state a component has access to.
• Redux currently has strong developer tooling, which makes development easier and faster.

I think in the React ecosystem there was a timeline where initially React did not endorse a clear implementation for managing global state, instead suggesting a pattern (Flux). As developers saw the limitations in managing application state in React components, they innovated to create solutions and this has produced everything we have now: Redux, React-Redux, various middlewares, devtooling, and so on, which provide great choices for building a complex JavaScript application.

I think ReasonReact will need a similar progression for the community to begin adopting it as the foundation for their applications. Maybe the solutions will look different, but I think the main principles of decoupling state and side effect management from the component/view layer and providing composition so the these layers are scalable, are very important.

An example application where I think these considerations start to make sense are say an app with several hundred components, 50-100 Redux stores, and maybe 50-100 different HTTP methods that send and receive data from various APIs.

[ariagaming]

This is a great discussion. I've been using React and Redux for years now, both in production and for fun. I understand why we use the flux pattern in React through Redux, but what I can't understand is why, with Reason, we don't use proven FP patterns instead of leaning on the old way of doing things...

We should be using:

1. State Monad, lift your render functions into a stateful realm. Instead of connect or reducerComponent use boundComponent which just fmaps your render function with the state monad...
2. Lenses, lenses are a very nice way to inform the code which part of the state you are using, giving you a solid base for choosing to rerender your component.
3. Put 1 more layer between your component and your reducer; I call it the "Action Monad", here you compose actions which you can call from your views which can "prepare your models for update" (read: lot's the .then's on a Promise) and after the Action completes; send the result to reducer, reduce it, rerender when needed.

With the extra layer for manipulation (point 3), data fetching, randomness, ffi and the Blizz Gods only know what else; combined with real world FP ideas you can have an amazing experience and very powerful type safe framework. While still being very easy to learn. Easier than Elm, much easier than PureScript, might even be easier than normal React and Redux 'cause of that whole "don't pass lambdas as event handlers" business. That stuff is silly hard!

Conclusion: I really think the community is searching for an alternative to JavaScript. I totally agree that OCaml is way better than Haskell inspired languages for beginner, intermediates and maybe even experienced programmers. Elm takes another route and just doesn't give you the power you really need to express yourself in your applications. ReasonReact should be a home run, the language is great, react is great, FP is awesome...I smell a winner!

I apologise in advance for intruding on this thread. I hope I haven't offended anyone. In any case, just my two cents.

(Extra cents:
4) Get rid of the Component syntax. Just lift your functions and de-sugar at compile time. No reason for that boiler plate it is distracting and not effective.
5) Remove the lifecycle methods, I mean all of them. We can lift and shove and bind and fmap if we need to, but 99% of our code should be covered with the state monad and lenses.
)

[nlfiedler]

@ariagaming

1. Is this boundComponent/fmap idea similar to render props?
2. Yes, agree that lenses are a splendid approach. The Rationale Lens.re looks promising.
3. The additional layer sounds like redux-saga/redux-observable, am I right? Absolutely agree that something of this sort will be needed.

[nlfiedler]

In case anyone is interested, I attempted to address the render issue in pull request #35. Please let me know your thoughts.