[lsadam0]

There very well could be something I'm not understanding. What you are describing still sounds like standard React.JS behavior. Unless you use a PureComponent, or explicitly implement your own `shouldComponentUpdate` method, then `shouldComponentUpdate` will always resolve `true`.

[skosch]

You're not wrong; it's stateless components I'm talking about.

I should have been clearer: it'd be okay if `true` were simply the default, but the crux of the issue is that you can't even implement your own `shouldUpdate` as the function doesn't provide the previous props (like it does in React), so you have nothing to compare against – unless you laboriously store them yourself as state.

[lsadam0]

I'm going to blame any communication breakdown on the fact that I know nothing about ReasonML or React-Reason. However, the point of having to store state so you have something to compare against strikes me as a really odd choice for the React-Reason library to introduce, since it deviates from the functionality of React itself.

I was curious enough to glance at the React-Reason doc's and they say that `shouldUpdate` is passed a record called `oldAndNewSelf: {oldSelf: self, newSelf: self}`. Does that not have what is needed to implement the method without extra storage? For example, in standard React `shouldComponentUpdate` is passed `nextProps` & `nextState`, and since the method is in context of the previous render, we have everything we need to make the comparison without explicitly taking extra steps to store previous/next.

Maybe we are saying the same thing in different ways, I seem to be pretty good at that :).

[skosch]

No, you're absolutely correct. Coming from two years of React-ing myself, I went down the exact same thought path as you.

The documentation is outdated, and the {oldSelf, newSelf} doesn't exist anymore. You had to use the `withRetainedProps` component for this to work, but that now results in an error message on compilation, telling you to use a reducerComponent instead.

I think it's something they intend to figure out a better solution for, but it's been put on the back-burner and meanwhile we're stuck with a non-solution. (Unless this is all wrong and I've been lied to and there's a better way, in which case, please enlighten me!)

[lsadam0]

Ah, +1 for your point about the poor documentation.

Thanks for taking the time to clarify, and thanks for the original pros/cons post. I'm currently working on a mid-sized MVP project that is standard ES6 + Flow. I've recently been exploring our options for migrating to TypeScript or something like ReasonML. I've worked extensively with TypeScript, but am only starting to dip my toes into other options. You've been more helpful than just reading the documentation :)