Skip to content
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

Merged
merged 7 commits into from
Jan 15, 2025

Conversation

marijnkampf
Copy link
Contributor

@marijnkampf marijnkampf commented Jan 8, 2025

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

  • Make sure fixtures/test_data.yaml is maintained when updating models
  • Consider the admin site when making changes to models
  • Use select-/prefetch-related field lists in views and search apps, and update them when fields are added
  • Make sure the README is updated e.g. when adding new environment variables

See docs/CONTRIBUTING.md for more guidelines.

Copy link

codecov bot commented Jan 9, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.66%. Comparing base (18244a7) to head (06177b7).
Report is 1 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

@marijnkampf marijnkampf marked this pull request as ready for review January 9, 2025 13:18
@marijnkampf marijnkampf requested a review from a team as a code owner January 9, 2025 13:18
Copy link
Contributor

@baarkerlounger baarkerlounger left a 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?

@oliverjwroberts
Copy link
Contributor

oliverjwroberts commented Jan 9, 2025

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.

@marijnkampf
Copy link
Contributor Author

@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.

@marijnkampf marijnkampf force-pushed the feature/CLS2-1163-eyb-lead-human-readable-numbers branch from 02a9c9d to d6ce789 Compare January 15, 2025 09:19
@marijnkampf marijnkampf merged commit 6bb9df5 into main Jan 15, 2025
7 checks passed
@marijnkampf marijnkampf deleted the feature/CLS2-1163-eyb-lead-human-readable-numbers branch January 15, 2025 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants