Need something more robust to handle React Router params

[benlesh]

According to the documentation on component lifecycle with react-router, users should be making ajax requests and using route params both at componentDidMount and componentDidUpdate. It seems like we might need a decorator (or the decorator) to handle more lifecycle hooks than just dispatchOnMount.

We can either do several decorators for each lifecycle hook we care about, which would incur the overhead of more higher-order components, or, we can have a single HoC to rule them all.

@connect(stuff, stuff)
@dispatchOnMount(stuff)
@dispatchOnUpdate(stuff)
class MyComponent extends React.Component {
  // stuff
}

// or something like 
const MyComponent = compose(
  connect(stuff, stuff),
  dispatchOnMount(stuff),
  dispatchOnUpdate(stuff)
)((props) => (<div>weee</div>));

Or the one lifecycle decorator idea:

@connect(stuff, stuff)
@dispatch({
  onMount: [stuff, stuff],
  onUpdate: [stuff]
})
class MyComponent extends React.Component {
  // stuff
}

// or something like 
const MyComponent = compose(
  connect(stuff, stuff),
  dispatch({
    onMount: [stuff, stuff],
    onUpdate: [stuff]
  })
)((props) => (<div>weee</div>));

[benlesh]

Worth considering: Should the the list of dispatchable things be provided by a factory? Like dispatchOnMount(() => [(props) => getThunkservable(props), (props) => getThunkservable2(props)]) or perhaps dispatchOnMount((props) => [getThunkservable(props), getThunkservable2(props)])?

[benlesh]

Also, dispatch probably isn't a good name for the decorator, because of collisions with other variables names... perhaps dispatchOn

[BerkeleyTrue]

Have y'all taken a look at redux-epic containers https://github.com/BerkeleyTrue/redux-epic/tree/master/docs/api#contain

The idea behind: The presentational component requires a certain piece or pieces of data to be present, this can be taken care of by one action. The actually lifecycle hooks aren't important to the user, they just care that the data is there. We provide helper methods for that container that can determine when not to call the action, for instance if the data is already primed.

It becomes the fetch container, redux's connect provides the data container, and the user provides the presentational component.

A good question: What is the main goal of this HoC?

[BerkeleyTrue]

ping @jayphelps

[jayphelps]

@BerkeleyTrue we're not thrilled on the existing code in here and I personally use some other HoCs I've created that aren't here yet. We're just experimenting at this point. I'll look at redux-epic's when I get a chance. 👍