refactor: Update StaticStatesTable to be more flexible #418
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.
Summary
Based on the feedback in #372, it was decided to make the
StaticStatesTable
more flexible and generic. This includes the following changes:ComponentStatesTable
StaticStates
by default, so you could use it for any components with variable props. You should now wrap the entire table in aStaticStates
componentstates
is nowcolumnProps
and is treated the same way asrowProps
permutateProps
instead of within the table itself. This should be the standard way you would use the table. TheshouldRenderRow
function has changed to afilter
function (the second argument ofpermutateProps
)ComponentStatesTable
now uses the child as a render function rather than an explicitrenderComponent
prop.This should go in ASAP as it's blocking #386, #381, #412, #394, #390, and #407
Checklist
yarn test
passesAdditional References
Example usage:
As you can see, the list of props can be more simple for some cases. However, caution should be taken as it's easy to forget permutations. I would suggest only using it for pseudostates/classnames in the
columnProps
and not for component props.