recompose withHandlers ... asynchronously?

Question

Is is possible/safe to use withHandlers with promises? Ex.:

withHandlers({
    onChange: props => event => {
      props.callAPI(props.data)
        .then(data => props.updateData(data))
    },
...

Thanks!

score 4 · Answer 1 · answered Jan 17 '17 at 20:18

After some tests I realized that it's working pretty well. Recompose rocks for building with pure components.

This is perfectly valid and working pretty well.

const enhWithHandlers = withHandlers({
  loginUserMutation: props => args => {
    props.updateMutationState(loading: true, error: null });
    props.loginUser(args)
      .then(() =>
        props.updateMutationState({loading: false, error: null }))
      .catch(err =>
        props.updateMutationState({ loading: false, error: err }));
  }
},
...
// then compose like
export default compose(
  reduxConnect,
  gqlConnectLogin,
  gqlConnectRegister,
  enhWithState,
  enhWithHandlers
)(UserLoginRegister);

It helps me to overcome lack of ability to reflect results of graphQl mutation with Apollo client to the wrapped component. This handles it perfectly and without the need of side effects in the component itself.

score 0 · Answer 2 · answered Jul 21 '17 at 06:01

0

But there are some problems when we use it like this:

compose(
  withState('loginStatus', 'setLoginStatus', {loading: false, error:null}),
  withHandlers({
    loginUserMutation: props => async args => {
      try {
        props.setLoginStatus({loading: true, error: null});
        await props.loginUser(args);
      } catch(error) {
        props.setLoginStatus({...props.loginStatus, error});
      } finally {
        props.setLoginStatus({...props.loginStatus, loading: false});
      }
    }
  })
)

Because the props reference is indeed lost after we await props.loginUser(args). Then we use it after that is wrong.

We should notice not to use it like above.

answered Jul 21 '17 at 06:01

xialvjun

1,090
7
10

I do not understand that `props` reference is lost. It is not and you even do not use it. Maybe you mean that the finally is not run. That makes sense if the `loginUser(args)` changes app state so the wrapped component is unmounted. Or can you elaborate little bit more? We use `recompose` extensively and ew have absolute no problem with that. – DavidC Jul 27 '17 at 07:18
I mean the argument `props` is equal to `this.props`, but after you `setLoginStatus and await loginUser` (`setLoginStatus` is like `this.setState`), then the argument `props` have been not equal to `this.props`.... It just like: `const props = this.props; this.setState({xxx}); api().then(_ => console.log(props == this.props));` it will log `false`... – xialvjun Jul 31 '17 at 09:21
I'd recommend not to think about recompose as a stateful component (and not thinking about `this` at all. Your `await props.loginUser(args);` will change props in the higher component and that will trigger the recalculation of the component tree. That's why after this `await` props may be different if the loginUser changes props in the higher component layer (but only if you pass this info down). And that's why usually if you use for example branch (to decide if display login or user data), after the loginUser your component will be unmounted and anything after will become no-op. – DavidC Aug 01 '17 at 11:32

recompose withHandlers ... asynchronously?

2 Answers2