Add support of fragments

Currently it is not possible to wrap splitter/element into fragment or custom component. This feature I would say highly needed to make composable layout, otherwise we get complex components handling both layout and logic around.

Do you have any plans bringing this feature?

Example

<ReflexContainer orientation="horizontal">
        <ReflexElement>
        </ReflexElement>
        <Bar/>
</ReflexContainer

function Bar() {
  // appearance logic
  return (
    <>
        <ReflexSplitter />
        <ReflexElement>
          <ReflexHandle/>
        </ReflexElement>
    </>
  )
}

[leefsmp]

To me it looks more like a point of view, showing the splitter and other elements of the layout definitely sounds like layout logic so I would rather have that logic at the layout level even if it can get complicated at first rather than having it hidden at some deeper level over multiple sub-components.

Support for fragments might be doableand will allow to better organize the layout into multiple functions that can return a fragment with splitter and element so I will take a look at it, however custom components is not easily achievable I’m afraid.

[growthwp]

@AlaaZorkane I think Phillipe will come back to you with more, but, yea, your implementation is practically what we found as a hotfix. Also, don’t expect a fix to this from any library, because the fix is to re-write the entire thing.

As I detailed here: https://github.com/leefsmp/Re-Flex/issues/139#issuecomment-886970004 the reason for why this “bug” happens is cloneElement and I can tell you that, unfortunately, none of the libraries currently out there actually work without their children being direct descendants.

I found out that this type of approach also has deep and awful performance implications in some cases. Assume your initial flexes were stored somewhere and you need to retrieve them, but also constantly update them. What ends up happening is that you need to create a selector for all of the flexes, in one place. Because you initialize the flex of an item and you need to generate all of the elements in a loop (all in one place), every single time an item’s flex changes, all others re-render to the point where you might end up having thousands of re-renders/s even with only a few dozen components in the tree.

---

As a side note: the reason for why this doesn’t work as we want it to is because, really, it’s not the “cover 80% of use-cases” approach, however, I digress and, as bad as it sounds, it’s just the reality of our world: you implement for the majority, paired with the teachings of an old world. cloneElement used to be a thing in the past, this was a legitimate “before context” strategy for automated prop drilling. However, had the creators thought about the rest of the 20% use-cases, it would immediately be apparent that the cloneElement approach is flawed, but, frankly, I, as well any of the developers I know would’ve implemented it the same. It’s “just good enough”.