Fix niceNum implementation

[danmooney2]

Description

Previous state hardcoded the thousands separators. I'm not sure which locale uses an apostrophe (') as a thousands separator but for the majority of the world that is not correct. Number.prototype.toLocaleString will format numbers based on user's locale.

Source: https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html

Related Issue

Motivation and Context

Readability

How Has This Been Tested?

Locally

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[anuragoyar]

Potential Risks and Suggestions:

File: js/script.js
Code Snippet: return parseInt(num, 10).toLocaleString();
Comment: The new implementation uses parseInt() which will truncate decimal values. If the original function was meant to handle decimal numbers, this could lead to data loss. Consider using parseFloat() or Number() instead to preserve decimal values.

File: js/script.js
Code Snippet: if (isNaN(num)) { throw new Error("Input is not a number"); }
Comment: Throwing an error might cause unexpected behavior in the UI if the filter receives non-numeric input. Consider returning a default value (like "0" or "N/A") or handling the error gracefully instead of throwing an exception.

File: js/script.js
Code Snippet: return parseInt(num, 10).toLocaleString();
Comment: The toLocaleString() method might produce different formatting based on the user's locale settings. The original implementation had a consistent format with single quotes as thousand separators. Ensure this change in formatting is acceptable for all users and doesn't break any UI expectations.

Summary:

This PR changes the implementation of a number formatting filter in what appears to be an AngularJS application. The change replaces a custom number formatting algorithm with JavaScript's built-in toLocaleString() method.

The new implementation is more concise and leverages browser standards, which is generally a good practice. However, there are potential risks with how decimal values are handled, error handling, and locale-specific formatting differences.

Before deploying to production, I recommend:

1. Testing with various inputs including decimal numbers, very large numbers, and edge cases
2. Verifying the new formatting meets business requirements across different locales
3. Ensuring the UI gracefully handles any errors that might be thrown
4. Adding a comment explaining the formatting expectations for future maintainers

This change appears to be a refactoring for improved code quality rather than a functional change, but the formatting differences could impact how numbers are displayed to users.