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 missing select prop type on State #11

Merged
merged 4 commits into from
Sep 29, 2017
Merged

Add missing select prop type on State #11

merged 4 commits into from
Sep 29, 2017

Conversation

eXon
Copy link
Contributor

@eXon eXon commented Sep 28, 2017

While reading the code, I noticed there is a missing prop type. On the State component, the select prop types was missing.

While reading the code, I noticed there is a missing prop type. On the `State` component, the `select` prop types was missing.
@codecov
Copy link

codecov bot commented Sep 28, 2017

Codecov Report

Merging #11 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff          @@
##           master    #11   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           2      2           
  Lines          30     30           
  Branches        7      7           
=====================================
  Hits           30     30
Impacted Files Coverage Δ
src/state.js 100% <ø> (ø) ⬆️
src/provider.js 100% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d0c77c...ff0dd73. Read the comment docs.

Copy link
Owner

@vesparny vesparny left a comment

Choose a reason for hiding this comment

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

Since you are working on this may I ask you to please change the <Provider> propTypes as well?

state is required there

Provider.propTypes = {
  inspect: PropTypes.func,
  state: PropTypes.object.isRequired
}

Thanks a lot for your first contribution.
I really appreciated 🎉🎉

src/state.js Outdated
@@ -57,7 +57,8 @@ State.contextTypes = {
State.propTypes = {
update: PropTypes.func,
Copy link
Owner

Choose a reason for hiding this comment

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

Could you please remove this?
It's a mistake because update is not supposed to be a <State> prop

Copy link
Owner

Choose a reason for hiding this comment

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

Just to make it clear...it was my fault 😬

@eXon
Copy link
Contributor Author

eXon commented Sep 29, 2017

Thanks for creating this library, I love the idea and how much simpler the code is to read and understand the data flow.

Changed both. May I ask why the state is required? Would it not make sense to default to an empty object so that if you don't have an initial state you don't need to specify?

src/provider.js Outdated
@@ -29,7 +29,8 @@ Provider.childContextTypes = {

Provider.propTypes = {
inspect: PropTypes.func,
state: PropTypes.object
state: PropTypes.object.isRequired,
children: PropTypes.node
Copy link
Owner

Choose a reason for hiding this comment

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

children should not be in prop types as we use a render prop instead.
I like it better because it's more explicit than children. It tells exactly what it does

Copy link
Owner

Choose a reason for hiding this comment

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

Ouch I am sorry I thought it was the State component.

Thanks for adding the children here, do you mind adding isRequired for it as well

@vesparny
Copy link
Owner

vesparny commented Sep 29, 2017

@eXon Thanks a lot. Simplicity and readability were the main points that made me want to share the library.

May I ask why the state is required? Would it not make sense to default to an empty object so that if you don't have an initial state you don't need to specify?

Technically you are right, but I'd prefer to be more explicit and always encourage the user to use a state prop, to make sure it's clear where to start from and avoid subtle bugs because of data not correctly initialised.
Let's keep it like that for the moment. If we see a use case where making it optional makes sense, we can probably change it in the future.

What do you think?

@vesparny vesparny closed this Sep 29, 2017
@vesparny
Copy link
Owner

sorry misclick

@vesparny vesparny reopened this Sep 29, 2017
@vesparny
Copy link
Owner

Thanks a lot 🙏

@vesparny vesparny merged commit e61e0a1 into vesparny:master Sep 29, 2017
@eXon eXon deleted the patch-1 branch September 29, 2017 21: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.

2 participants