Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add withExtraArgument() #70

Merged
merged 1 commit into from May 10, 2016
Merged

Add withExtraArgument() #70

merged 1 commit into from May 10, 2016

Conversation

gaearon
Copy link
Collaborator

@gaearon gaearon commented May 10, 2016

People often request the ability to inject a custom argument into thunks. While we don’t plan to do this by default so that we don’t have to change the signature of redux-thunk, we are adding thunk.withExtraArgument(arg) as a way to inject an arbitrary argument into every thunk action creator. This argument will be available as the third argument in the action creators, right after getState().

Example:

const store = createStore(
  reducer,
  applyMiddleware(thunk.withExtraArgument(api))
)

// later
function fetchUser(id) {
  return (dispatch, getState, api) => {
    // you can use api here
  }
}

I chose withExtraArgument over something more compact like inject to make it clear we’re not mutating redux-thunk itself, and that this argument will be passed as an extra argument (rather than, for example, instead of, the two usual arguments).

@gaearon gaearon merged commit 2f405ee into master May 10, 2016
@gaearon gaearon deleted the with-extra-argument branch May 10, 2016 15:11
@markerikson
Copy link
Contributor

Semi-stupid question: if you're going to add the ability to augment with one extra argument, why not make it multiple extra arguments?

@gaearon
Copy link
Collaborator Author

gaearon commented May 10, 2016

I don’t see much of a point to that. You can always destructure if you need them:

const store = createStore(
  reducer,
  applyMiddleware(thunk.withExtraArgument({ api, whatever }))
)

// later
function fetchUser(id) {
  return (dispatch, getState, { api, whatever }) => {
    // you can use api here
  }
}

Just one argument seems conceptually simpler than having to explain that the first two arguments are from Redux, and any number of next arguments are your custom ones.

@markerikson
Copy link
Contributor

Okay, yeah, that seems pretty viable. Nice.

@villesau
Copy link

villesau commented Jun 7, 2016

Could someone open up why this was implemented? I can't come up with any valid reason/use case why to use this over es6 modules.

@gaearon
Copy link
Collaborator Author

gaearon commented Jun 7, 2016

@villesau Useful for mocking an API client in tests, for example.

@villesau
Copy link

villesau commented Jun 7, 2016

thanks @gaearon! Is testing the main reason for this or is there some other use cases as well? I'm just curious. We are using rewire to mock the modules in tests so i didn't even think about that.

@gaearon
Copy link
Collaborator Author

gaearon commented Jun 7, 2016

Testing and being able to provide a separate pre-initialized API client instance for every request in server rendering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants