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

Heterogeneous selectors typings #67

Merged
merged 3 commits into from
Jan 31, 2019

Conversation

toomuchdesign
Copy link
Owner

@toomuchdesign toomuchdesign commented Jan 22, 2019

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

feature

What is the current behaviour? (You can also link to an open issue here)

Heterogeneous selectors and any number of uniform selectors not implemented.

What is the new behaviour?

dependencies property added in typing, supported heterogeneous selectors and any number of uniform selectors.

We mainly replicate what happened in reselect typing here and here.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

I think so, because the reselect for similar changes made it.

Other information:

see conversation in #60

Please check if the PR fulfills these requirements:

  • Tests for the changes have been added
  • Docs have been added / updated

@toomuchdesign toomuchdesign force-pushed the heterogeneous-selectors-typings branch 2 times, most recently from d46a861 to 30baeed Compare January 23, 2019 10:58
@coveralls
Copy link

coveralls commented Jan 23, 2019

Coverage Status

Coverage remained the same at 100.0% when pulling c89f348 on heterogeneous-selectors-typings into aaf3561 on master.

@xsburg xsburg self-assigned this Jan 28, 2019
@xsburg
Copy link
Collaborator

xsburg commented Jan 28, 2019

Hi @toomuchdesign!
Sorry for not participating in the original discussion.
The changes seem perfectly valid to me, we are basically following the typings in reselect and even go a bit forward by adding support to the dependencies property.
A few notes about the maintainability of the typings and breaking changes.

Maintainability

The typings are of course getting bigger with this PR, but it seems to be the only way to keep backward compatibility with the previous version. As mentioned in the original discussion in reselect, otherwise we break code that used type parameters. There are also use cases where the original typings are just easier to use, so looks like we have to keep both. The maintainability will of course suffer, but it seems the only way forward.

Breaking changes

In general, I cannot see any breaking changes, given that we keep both typings (the way it is in this PR). But to play it safe, I would rather follow reselect example and bump the version.

All in all, I'm glad that we keep up to date with reselect typings and look forward to try it in work! 👌

@sgrishchenko
Copy link
Contributor

sgrishchenko commented Jan 28, 2019

@xsburg hello, what you think about #65 PR (this is an attempt to generate types automatically)? This should improve maintainability.
And you says, that there are also use cases where the original typings are just easier to use. Whitch original typings you mean? Homogeneous selectors? If yes, can you give an example, please? It just seems to me that heterogeneous selectors are a more general version of homogeneous selectors?

@toomuchdesign toomuchdesign merged commit a13d01e into master Jan 31, 2019
@toomuchdesign toomuchdesign deleted the heterogeneous-selectors-typings branch January 31, 2019 08:28
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

4 participants