Any ideas on subspacing components with render props? about redux-subspace HOT 7 CLOSED

Are you ever truely on holiday in this world?

My feeling is that you hit the nail on the head, this doesn't fit the design goals perfectly.

But those design goals are utopia, and the real world calls for exceptions). In the same vein as global actions, sometimes the child needs to be subspace aware. In these scenarios, it is better is the child is not aware of any specifics to where in the structure it lives, just that subspaces might exist.

I think the ParentSubspaceProvider achieves this escape hatch nicely, assuming it works sensibly when there is no parent (providing the root store), the child is still unaware of specifics.

from redux-subspace.

I am aware that the obvious answer is that if the parent component itself does the rendering the components will be in its subspace, which is by far the cleanest thing from subspace's perspective. There are however plenty of good reasons to use render props, and in this case it's indispensable to the table patterning.

from redux-subspace.

Seems like it should be easy enough to copy the rootStoreEnhancer patterning to create something like a parentStoreEnhancer, and then offer some sort of container that grabbed parentStore and used it for everything (i.e. getState and dispatch)

from redux-subspace.

Hey @conartist6,

As you are aware, this is not something that is currently supported.

This sounds a bit similar to the desired outcome of #83. In that proposal, you could mark a SubspacProvider with a transparent={true} prop and any children subspaces would skip it and use its parent as the parent store. This feature would be ideal for components that need a bit of state for their own purposes but doesn't make sense to introduce a whole extra layer to the state tree.

The main difference that I can see between the scenario in the #83 and your is that the children you are passing as render props aren't necessarily wrapped in SubspaceProviders themselves. You could fake it with something like:

<SubspaceProvider mapState={state => state.myTable} namespace="MY_TABLE" transparent={true}>
  <Table
    rows={[...]}
    renderRow={data => {
      return (
        <SubspaceProvider mapState={state => state}>  // because it's parent is `transparent` the state would be the the state you want
          <TableRow>
            <FooCell foo={data.foo}>
            <BarCell bar={data.bar}>
          </TableRow>
        </SubspaceProvider>
      );
    }}
  />
</SubspaceProvider>

I'm not a big fan of this as faking the subspace structure is what led to the #83 proposal in the first place.

Your suggestion of adding a parentStoreEnhancer and effectively a reverse subspace is interesting. The parentStoreEnhancer is something that has existed in many branches before as it's almost been required a few times during development, so I'm more than happy for something like that to exist. The reverse subspace container (ParentSpaceProvider?) is not something I've considered before, but on the surface, it sounds like an ok escape hatch in these situations. I'm imagining something like:

<SubspaceProvider mapState={state => state.myTable} namespace="MY_TABLE">
  <Table
    rows={[...]}
    renderRow={data => {
      return (
        <ParentSpaceProvider>
          <TableRow>
            <FooCell foo={data.foo}>
            <BarCell bar={data.bar}>
          </TableRow>
        </ParentSpaceProvider>
      );
    }}
  />
</SubspaceProvider>

Or perhaps Table would use it internally when calling the render prop?

As you suggested, parentStoreEnhancer would be more or less the rootStoreEnhancer but just sticking the store into a parentStore key. The ParentSpaceProvider component would also be very similar to the SubspaceProvider component, but instead of creating a subspace to pass down the context, it would just grab the parentStore off the store and pass that down (probably falling back to the original store if there is not parentStore value).

Feel free to think up a better name for ParentSpaceProvider.

I guess my only concern is whether or not this actually fits with design goals of the library. This introduces some knowledge into the child component that it exists within a subspace. In the case of render props, this is less of a concern as the parent is specifying which of its children belong to the subspace and which don't but the existence of the component means that it will be abused by people wanting to just traverse up and down the tree at will to find the exact piece of state they're after. One could argue that this is already possible with the rootStore parameter of the mapState function (to traverse down at least), so maybe this is not a big issue.

I'd be interested to get @jpeyper's take on it. He's usually pretty good at whether something feels right in these situations. He's on holiday at the moment and may not get to this soon though, so if you want to take a run at it in the meantime and get a PR up, I think it should be fine.

from redux-subspace.

I wrote the PR and I should have time to polish it up and submit it today. The second example in your response above is almost exactly what I wrote in the documentation for what I called ParentSubspaceProvider. I agree that in the example Table shouldn't know that it's in a subspace, which means that the render prop would definitely have the parent provider at its top level.

from redux-subspace.

Sorry, accidental close. My phone and holiday brain are a bit clunky.

from redux-subspace.

Thanks @jpeyper, that reflects my thoughts quite nicely as well. @conartist6, consider this the green light on the feature. Can't wait to see a PR 😄

from redux-subspace.