Entity: Strengthen typing of getInitialState #4423
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When initializing an
EntityAdapter<T>
and subsequently setting theinitialState
using...adapter.getInitialState({ <additional state here>})
, it is possible, given the current interface, to introduce unknown variables that do not conform to the user's specified state. This could result in bugs related to mistyped variable names, resulting in confusing user error scenarios.Closes #4422
What is the new behavior?
This small change modifies the interface to require that the input state
S
extendsEntityState<T>
, requires that the additionalStatestate
argument conforms to an Omit version of thisS
type, which removes the 'id' and 'entities' properties by way ofkeyof EntityState<T>
, and then finally, since the argument now already extendsEntityState<T>
, we can now simply returnS
.Does this PR introduce a breaking change?
I have answered "Yes", but realistically, if a user of the Entity package has entered in correct code already, there will be no breaking changes. Any breaking changes should be in the form of a user now being aware of incompatible property types in their additional state, or if their State interface does not contain
extends EntityState<T>
.Other information
This change has helped my place of employment from unknown state properties quite nicely, but I must say this is my very first community/open source pull request. I would be happy to take any constructive criticism or guidance on anything that I could do better here. Very excited to be contributing and hope this is of help.
Thank you, -Gavyn Holt