| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
PatternFly-React preview: https://patternfly-react-pr-3203.surge.sh |
Sorry, something went wrong.
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.
|
Sorry, something went wrong.
|
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! |
Sorry, something went wrong.
|
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 children property type isn't inferred as something acceptable, will look into this more. 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. |
Sorry, something went wrong.
There was a problem hiding this comment.
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!
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
…FunctionTypes tsconfig setting apply types to demos for table update tests
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
Your changes have been released in:
Thanks for your contribution! 🎉 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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 strictFunctionTypes errors for Table.
Additional issues: #3148 and #3172 and #3224