Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upchore(table): fix types for table transforms #3203
Conversation
This comment has been minimized.
This comment has been minimized.
|
PatternFly-React preview: https://patternfly-react-pr-3203.surge.sh |
This comment has been minimized.
This comment has been minimized.
codecov-io
commented
Oct 24, 2019
•
Codecov Report
@@ Coverage Diff @@
## master #3203 +/- ##
==========================================
+ Coverage 67.43% 67.44% +0.01%
==========================================
Files 892 892
Lines 24870 24866 -4
Branches 2141 2140 -1
==========================================
Hits 16771 16771
+ Misses 7094 7091 -3
+ Partials 1005 1004 -1
Continue to review full report at Codecov.
|
This comment has been minimized.
This comment has been minimized.
|
Just realized we probably don't actually want to swap IExtra for IRowData in the places I've done currently in this PR, but I do think that's at least the right place to be making the adjustment. Flipping the strictFunctionTypes switch really brings the issues to light. Will keep hacking away! |
seanforyou23
force-pushed the
seanforyou23:transform-type-improvements
branch
from
28d0393
to
8ccd0c6
This comment has been minimized.
This comment has been minimized.
|
I've pushed some updates that improve the approach. It seems to be working well and I've only had to modify the tests slightly. I'm not sure why the Beyond that, the main thing I'd like to get some opinion on is breaking out a shared return type for transformers and formatters. It seems like this may have been the original intention, but I'm partly guessing. Are transforms and formatters considered "subclass" of "decorators" or maybe "renderers"? I see references to both in the code and it isn't clear what the relationship is. The system will work in a variety of ways, just trying to match the correct terminology used to how the public api parts are named. It seems to run fine in OpenShift on a quick test, and solves the type errors mentioned in the issues attached. I need to give it all another once over tomorrow and see if I can wrap these last bits up, would love any feedback in the meantime. |
seanforyou23
force-pushed the
seanforyou23:transform-type-improvements
branch
2 times, most recently
from
ab789ce
to
7c08adf
|
This is great addition! We are not using types anywhere, but I know that folks will definetely be happy with new types checking! Just a question about one unused variable and we are good to go! |
...ternfly-4/react-table/src/components/Table/utils/decorators/sortable.tsx
Outdated
Show resolved
Hide resolved
|
LGTM |
...egration/demo-app-ts/src/components/demos/TableDemo/TableActionsDemo.tsx
Show resolved
Hide resolved
…FunctionTypes tsconfig setting apply types to demos for table update tests
seanforyou23
force-pushed the
seanforyou23:transform-type-improvements
branch
from
7c08adf
to
63efb84
seanforyou23
force-pushed the
seanforyou23:transform-type-improvements
branch
from
63efb84
to
e1b5c3b
|
LGTM |
This comment has been minimized.
This comment has been minimized.
|
Your changes have been released in:
Thanks for your contribution! |
seanforyou23 commentedOct 24, 2019
•
edited
What: This PR updates the types used around the existing table decorators (transforms & formatters) so that consumers can specify the standard
(ICell | string)[]type for table column definitions in TypeScript based apps. It also makes use of the existing types throughout a lot of the table related code, and modifies a few types slightly for consistency.It should also help clear the
strictFunctionTypeserrors for Table.Additional issues: #3148 and #3172 and #3224