Reactivesearch: RFC: Better specs for render props for result components

[metagrover]

Issue Type:
RFC

Platform:
All

Description:
With our current spec, we have introduced a set of unintended opinions into the component rendering control. Given how loader prop works, it is hard for a user to take control of loader rendering. For instance, some users may want to hide the results when the results are loading, or some may not. Again, the loader behavior is very ambiguous when it comes to pagination and infinite loading setup.

I strongly feel that we should improve our spec to merge error, loading and result in one render prop. We can keep separate event callbacks via onErrors, onData, etc, but for render props, it would make a lot more sense if these things are passed to one single entity to take control of the rendering and providing developers with more flexibility and no rendering opinions from the library:

renderAllData={({ loading, error, data }) => (...)}

We will need to think of a way to enable this spec (or) an equivalent behavior with renderData which runs for individual items in the results set.

[lakhansamani]

Along, with the above specs, we can also add stats and make pagination and infinite loading optional props, this can help developers to implement their own pagination component or scroll logic, thus allowing them to customize ui completely

[metagrover]

Absolutely, that sounds good. This will further improve the rendering control.

[lakhansamani]

Also, we should consider using Render Prop that way developer can use this data inside ReactiveList children

<ReactiveList ... >
  { ({ loading, error, data }) => (
    <div> ... </div>
  )}
</ReactiveList>

[bietkul]

Similar to the Query component from Apollo Client
https://www.apollographql.com/docs/react/essentials/queries.html#basic

[metagrover]

Thoughts on this:

<ReactiveList>
    {({ data, error, loading, ... }) => (
        <ResultsWrapper>
            {
                data.map(item => (
                    <ResultCard>
                        <ResultCard.Image></ResultCard.Image>
                        <ResultCard.Title></ResultCard.Title>
                        <ResultCard.Description></ResultCard.Description>
                        <p>hello im a paragraph</p>
                        <span>hello</span>
                    </ResultCard>
                ))
            }
        </ResultsWrapper>
    )}
</ReactiveList>

[metagrover]

DataSearch suggestions rendering API:

<DataSearch>
    {({ data, error, loading, ... }) => (
        <DataSearch.Suggestions>
            {
                data.map(item => (
                    <div className="suggestion">{item.label}</div>
                ))
            }
        </DataSearch.Suggestions>
    )}
</DataSearch>

[lakhansamani]

Soon the render props will be replaced by hooks, as it can reduce lot DOM hierarchy

[metagrover]

I agree, we will discuss that abstraction after the v3 stable release - since it will be non-breaking. But for now, I strongly feel this API is very flexible and puts the developer in control of what and how things get rendered.

Above all, this is very commonly used and requires very less intrusion from library docs/guidelines.

[lakhansamani]

Yes, this change is great, and it will improve the developer experience 👍