Inconsistency in README and reversed order about react-composer HOT 6 CLOSED

Thanks for the issue! The README is correct. I responded over here ( gnapse/render-props-compose#8 (comment) ) with the details:

The README accurately describes how the library currently behaves. The render order is last-to-first, which is to match the behavior of common functional utilities. However, the argument order respects the array that you pass in. This may seem weird, but until a prop like functional is added, the component is really only usable with components where the render order doesn't matter (like the new Context API).

Either way, this doesn't matter too much, I suppose, given that the order will be changing soon.

The last sentence refers to the change described in #7 to support #19

from react-composer.

I'm sorry but I still don't get it. In the screenshot above I see that the innermost component in the un-composed example is the one that receives {...configThree} as props. Then that component is also the last in the array list of the example that uses the Composer component. So it suggest to me that the last in the array is the innermost, and the first in the array is the outermost.

But then later on in that same README you see this:

Here it is clearly stated that the last in the array (<C />) is the outermost in the nesting order, and that the first one in the array (<A />) is the innermost. This contradicts the example at the beginning.

from react-composer.

So it suggest to me that the last in the array is the innermost, and the first in the array is the outermost.

The reasoning here is where the misunderstanding is, I think. The render order can be anything at all, and it doesn't necessarily have to have anything to do with the order of the components that you pass in, nor the order of the render prop argument.

Does that line of reasoning make sense to you? I think once that part makes sense, then the rest follows from it.

When it comes to the argument order in the render prop, I think nobody would argue that the order there should differ from the order of components. Which is why this lib lines those two up.

However, the rendering order isn't as clear cut in my opinion. It shouldn't just be random, because, well, that would be weird, and probably a lot of code for no reason. So the two options on the table are that it either matches what you pass in, or that it is the reverse order.

I understand that some developers, like you, expect the render order to match the order that is passed in, but due to the rise in popularity of functional programming in JavaScript I can also see how someone would expect the exact opposite ( see #7 (comment) )!

This is because compose(a, b, c) most often runs the functions in this order: c -> b -> a. And because I think of "rendering a component" as being analogous to executing a function, the render order matches up with the most common implementation of the functional compose.

Unfortunately, I do not think that there is a "correct" render order for a component like this. My expectation is that most developers would prefer the current behavior, which is why I implemented it this way (I may have been wrong with that assumption 🤷‍♂️ )

Either way, I think supporting a functional prop ( #19 ) is the most useful feature that could be added to this lib, and in that situation, the "same-order" rendering approach makes the API a lot simpler for consumers to use, which is why I plan to reverse the render order ( #7 )

Does that help clear things up, @gnapse ?

from react-composer.

At this point I'm inclined to think there's something wrong with me, but I still see an inconsistency between that first example and the note about the reversed order. Perhaps the fact that in that first example all components are named the same is what makes my point a bit fussier. If you were to write that first example but using three different components, how would it be?

However, if you're planning to un-reverse the order, this discussion might be futile in the end anyway.

from react-composer.

components=A,B,C
render prop argument order=A,B,C
render order=C,B,A

from react-composer.

Exactly, and I keep seeing the problem. I'll try to be more explicit. The example shown in the README composing components is this one:

import Composer from 'react-composer';

<Composer components={[
    <RenderPropComponent {...configOne} />,
    <RenderPropComponent {...configTwo} />,
    <RenderPropComponent {...configThree} />
  ]}>
  {([resultOne, resultTwo, resultThree]) => (
    <MyComponent results={{resultOne, resultTwo, resultThree}} />
  )}
</Composer>

The order in which those will be rendered is this one:

<RenderPropComponent {...configThree}>
  {resultOne => (
    <RenderPropComponent {...configTwo}>
      {resultTwo => (
        <RenderPropComponent {...configOne}>
          {resultThree => (
            <MyComponent results={{resultOne, resultTwo, resultThree}} />
          )}
        </RenderPropComponent>
      )}
    </RenderPropComponent>
  )}
</RenderPropComponent>

The component that receives configThree as props is C in your notation. It's the last in the render prop arguments and in the components list, but it's the outermost.

However, in the un-composed supposedly equivalent code that the README shows, the component receiving configThree as props is depicted as the innermost in the nesting. Here's a copy of that example verbatim from the README:

<RenderPropComponent {...config}>
  {resultOne => (
    <RenderPropComponent {...configTwo}>
      {resultTwo => (
        <RenderPropComponent {...configThree}>
          {resultThree => (
            <MyComponent results={{resultOne, resultTwo, resultThree}} />
          )}
        </RenderPropComponent>
      )}
    </RenderPropComponent>
  )}
</RenderPropComponent>

At this point I am more and more convinced that there's something wrong with me: either I'm missing something and you're right, or I am very bad at explaining myself.

from react-composer.