-
Notifications
You must be signed in to change notification settings - Fork 10
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
User friendly numbers for EYB Leads #5890
User friendly numbers for EYB Leads #5890
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5890 +/- ##
=======================================
Coverage 96.66% 96.66%
=======================================
Files 1064 1064
Lines 25311 25360 +49
Branches 1672 1683 +11
=======================================
+ Hits 24466 24515 +49
Misses 689 689
Partials 156 156 ☔ View full report in Codecov by Sentry. |
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.
Given this is purely about presentation(?) and the backend doesn't do any presentation(?) shouldn't this happen on the react side really?
You do make a good point. For additional context, similar functionality was previously implemented, but removed in #5852. A potential argument for keeping this in the API is then the Data Workspace datasets would also be formatted this way... However, I'd be interested to hear others' thoughts on this. I know Santosh currently has a PR for similar functionality in the Frontend. |
@baarkerlounger it's basically picking your design principle to stick to; either keeping it DRY or arguable having formatting/presentation in the API. As @oliverjwroberts mentioned this formatting will need to be done for the Data Workspace API regardless. One thing we could consider is formatting this when ingesting the data, but the downside of that would be we would loose the format of the original data. I think having this in the API here is an acceptable solution as it avoids having to do the calculations in both the API and the front end. Which would use different technologies and the changes of different non consistent results would increase. |
02a9c9d
to
d6ce789
Compare
Description of change
Return user friendly currency and number ranges for EYB Lead data (spend and hiring).
Guidance is taken from the GOV UK style guide
For any ranges, use ‘to’ rather than '-'
E.g. 1-5 should be 1 to 5
For numbers over 999 a comma should be used e.g. 1,000
For numbers over 1,000,000, they should be displayed as 1 million for better readability
Currency symbols should be used
E.g. £0 to £499,999
Some possible options include text as UPPER_SNAKE_CASE, where as a fallback this is formatted as Sentence case instead.
Checklist
Has this branch been rebased on top of the current
main
branch?Explanation
The branch should not be stale or have conflicts at the time reviews are requested.
Is the CircleCI build passing?
General points
Other things to check
fixtures/test_data.yaml
is maintained when updating modelsSee docs/CONTRIBUTING.md for more guidelines.