-
Notifications
You must be signed in to change notification settings - Fork 53
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
Transitive styles #366
Transitive styles #366
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #366 +/- ##
========================================
- Coverage 9.78% 8.14% -1.64%
========================================
Files 115 195 +80
Lines 4078 7340 +3262
Branches 1077 1843 +766
========================================
+ Hits 399 598 +199
- Misses 3191 5805 +2614
- Partials 488 937 +449
Continue to review full report at Codecov.
|
!isEqual(nextProps.activeSearchVisibleItinerary, this.props.activeSearchVisibleItinerary) || | ||
!isEqual(nextProps.activeSearchResponseOtp, this.props.activeSearchResponseOtp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could end up being quite an expensive operation because of the deep comparisons done to look at each of these items. It'd be much better to have a simple equality check or at least not check so many items.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems there are two overall goals of this PR
- Use the
getTransitiveRouteLabel
function from theComponentContext
- Avoid as many rerenders as possible
However, as noted in the comments, this PR kind of has stuff all over the place and the method in which the shouldComponentUpdate
is calculated could actually be a very expensive operation if every part of two objects need to be analyzed. Therefore, I propose an alternate way of doing things that consolidates the code and uses selectors to avoid recomputations. See #370.
Use selector to compute transitive data
Ready for review again... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few recs in the comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contingent upon addressing @landonreed's comments and also on merging in #379.
Avoid unnecessary rerenders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one little recommended improvement.
Co-authored-by: Evan Siroky <[email protected]>
🎉 This PR is included in version 3.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This PR modifies code to use new styling props introduced in
@opentripplanner/core-utils/transitive-overlays
v 1.0.7 (see opentripplanner/otp-ui#246):example-config.yml#map
.getTransitiveRouteLabel
function to render a route label is introduced in theComponentContext
,TransitiveCanvasOverlay
is updated accordingly.EDIT: Example configuration for testing: see https://github.com/ibi-group/configurations/pull/141.
EDIT: This PR should fix #374.