Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Overloading connect with factory#279

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
gaearon merged 2 commits intoreduxjs:masterfromtgriesser:mapStateToFactory
Feb 4, 2016

Conversation

@tgriesser
Copy link
Contributor

I had actually considered this before doing theconnectFactory approach in#185. The issue was that it felt wrong to overload the arguments and require first calling the function to determine its return type.

That said, this is the cleanest implementation I could come up with. It checks if the argument in question hasfn.length of 0 and also returns a function.

This breaks a few tests, but nothing critical - only on some spies or guarantees an arity-0 function is called a certain amount of times. I can clean those up if this looks alright otherwise.

@gaearon
Copy link
Contributor

Rather than look at arg count, can we determine whether they returned functions instead of objects lazily first time we call them from the constructor?

mauroporras reacted with thumbs up emoji

@tgriesser
Copy link
ContributorAuthor

Took another pass at it, it's a little more verbose / complicated, but does things lazily as you mentioned, all tests are passing and it avoids calling the mapping functions any more times than necessary.

If this looks alright I can add some tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I would leave those checks inline.

@gaearon
Copy link
Contributor

Yes, this looks good. Please do add tests.

@tgriesser
Copy link
ContributorAuthor

Updated, rebased, tests added. Also noticed when writing the tests that a final shallow equality check on the final merged props would save a render if there is a custommergeProps supplied and nothing has changed, so I added that as well.

expect(updatedCount).toBe(0)
expect(memoizedReturnCount).toBe(2)
})

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Nit: mind killing the newline here?

@gaearon
Copy link
Contributor

That’s amazing, thank you so much for your work on this. A few more nits and it’s good to go.

@tgriesser
Copy link
ContributorAuthor

All set with a test and a bit of formatting polish

gaearon added a commit that referenced this pull requestFeb 4, 2016
@gaearongaearon merged commitadc805a intoreduxjs:masterFeb 4, 2016
@gaearon
Copy link
Contributor

Would you be up to contributing a section toComputing Derived Data recipe documenting that? I think a lot of people won’t learn about this useful feature otherwise.

@tgriesser
Copy link
ContributorAuthor

Sure thing, I'll take a look at doing this a little later.

@ellbee
Copy link
Contributor

@tgriesser I have started to update the Reselect docs to reflect this change. If you haven't started on this already, would you like me to carry on and document it?

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@tgriesser@gaearon@ellbee@Andarist

[8]ページ先頭

©2009-2025 Movatter.jp