-
Notifications
You must be signed in to change notification settings - Fork 34
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
Add option to provide custom labels to tooltip and use legend labels for the tooltip value; COUNTRY=rbd #1286
Conversation
…o-display-labels-instead-of-values-in-the-tooltip
Build succeeded and deployed at https://prism-1286.surge.sh |
@@ -129,5 +129,6 @@ | |||
"Phase classification": "Classification de la phase", | |||
"Population in phase 3 to 5": "Population en phase 3 à 5", | |||
"Days since last rain": "Les jours depuis la dernière pluie", | |||
"Admin Level": "Niveau Administratif" | |||
"Admin Level": "Niveau Administratif", | |||
"Classification": "Classification" |
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.
I acknowledge this is incredibly unnecessary, it's just coverage for coverage's sake — but it demonstrates that there's coverage to everyone who doesn't already know that "Classification" = "Classification"
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.
Yup I think it's the right approach
@gislawill quick ask, in general I prefer to keep the titles shorter and explicit (ready to be merged). The link to issue is handled separately already: I went ahead and updated the title for this PR |
…o-display-labels-instead-of-values-in-the-tooltip
@@ -168,6 +168,10 @@ const PopupContent = ({ | |||
return true; | |||
}) | |||
.map(([key, value]) => { | |||
// If the data is undefined, null, or an empty string, we don't want to show the key/value pair |
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.
Can you explicit the use-case for this? Note that we already have the reverse case where we hide the key
using the do_not_display
prefix
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 allows us to pass a single string to PopupContent to display rather then always displaying a label: data. That's necessary to render the layer name on it's own line without following with : {data}
. I'll update the comment to make that clearer — "we don't want to show the key/value pair" doesn't mean much 😅
...(!useCustomLabel ? possibleAdminLevelData : {}), | ||
...featureInfoPropsData, | ||
...(useCustomLabel ? possibleAdminLevelData : {}), |
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.
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.
Good catch, I wouldn't consider this expected. I'm not certain that I know where we'd prefer "Admin Level" to go in the tooltip order.
@wadhwamatic, for tooltips showing the "IFPRI / ACLED Conflict Analysis - 2023" layer, do you have a preference for where the Admin Level is displayed?
Mali, Tombouctou, Tombouctou
IFPRI / ACLED Conflict Analysis - 2023
Admin Level: 2 (this is where it was rendered prior to this change)
Classification: High
Deadliness score: 84
Deadliness rank: 47
Danger score: 34
Danger rank: 16
Diffusion score: 2
Diffusion rank: 65
Fragmentation score: 4
Fragmentation rank: 6
Admin Level: 2 (this is where it's currently rendered with this change)
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.
@gislawill - we can keep admin level at the bottom. In the issue I'll write up today, we should also address the need for this. It's not always necessary to display it.
The code changes look good overall. I am a bit worried however that the tooltip logic is getting a bit complicated and might get hard to maintain / use properly (from a product standpoint) cc @wadhwamatic |
@ericboucher - yes, agreed. We've got a lot of configuration options happening. As I worked with it, it's pretty straightforward to use, but for someone new to it, there's a learning curve. Documentation is needed (I can contribute to that from the user perspective), but I also think renaming / simplifying things is key. @gislawill and I touched on this yesterday. We'll create a separate issue for it |
…o-display-labels-instead-of-values-in-the-tooltip
@ericboucher and @gislawill - here's a new issue to start getting ideas together on the next iteration of the tooltip: #1292 |
Description
This address Feature Request #1280 with 3 updates:
<PopupContent />
(the body of the tooltip) to print one simple string rather than always{label}: {data}
{label}
data_label
field in the layer definition that proceeds the layer's data value on the tooltipdisplay_source
field in the layer definition that uses the matching legend's label view on the tooltipHow to test the feature:
Test your changes with
REACT_APP_COUNTRY=rbd yarn start
REACT_APP_COUNTRY=cambodia yarn start
REACT_APP_COUNTRY=mozambique yarn start
Screenshot/video of feature: