fix: (MM-59973) emoji count 0 update

[rahimrahman]

• tried to include everything into useMemo was an anti-pattern
• moved back to useMemo + useEffect
• previousNumber and animateToNumber comparison has some flaw when dealing with difference length between the two

Summary

Ticket Link

Checklist

• Added or updated unit tests (required for all new features)
• Has UI changes
• Includes text changes and localization file updates
• Have tested against the 5 core themes to ensure consistency between them.
• Have run E2E tests by adding label E2E iOS tests for PR.

Device Information

This PR was tested on:

Screenshots

Release Note

[rahimrahman]

@Rajat-Dabade I made this PR to not clutter yours and the base branch is yours. I reverted your changes that combined useEffect into useMemo. After talking to @larkox, I agreed that animation effects should stay in useEffect because of

1. separation of concern
2. readability

While I think if we had combined them, it would have been made so much simpler, and less code, and even slightly performant. However, the reasons above are definitely more ideal. Even ChatGPT agrees: https://chatgpt.com/share/66fed195-d0b0-8013-bec5-afb87b680030.

I've also made a bit more changes with the intent to make things "cleaner". I've noticed that when animateToNumber changed to 1000, previousNumber is 999, the original was comparing the wrong digit. You made some change, but I thought the previousNumberString memoized would make the number 0999 so it compares digit by digit (without having to do other type of checking (length comparison)).

999 => 1000, then 999 becomes 0999
1000 => 999, then 1000 becomes 000.
100033 => 21, then 100033 becomes just 33.

In the last example, if the animateToNumber is 21, we only run the loop twice, and index 0 and 1 will match perfectly to 3 and 3 => 2 and 1.

Let me know your thoughts on this and/or the rest of the changes.

[rahimrahman]

Was using index as a key, but changing from 99 => 199, were causing the original two views to be re-rendered when it is not necessary.

By using the reverse index as key, hopefully the first 2 views will stay intact, and React only have to add 1 additional View tree.

Keep in mind, there are may Views (10) within each View, so not causing the parent View to re-render is a good thing.

[Rajat-Dabade]

@rahimrahman, Thanks for the update and for creating the PR! I totally understand the reasoning behind reverting the useMemo to useEffect based on the separation of concerns and readability. I agree that keeping the animation effect in useEffect aligns better with React's principles, especially when handling side effects.

Regarding the changes with the previous number comparison logic, I like the idea of using previousNumberString with padding to compare digit by digit without extra checks. It feels cleaner and handles the edge cases well.

Nice work 🚀 .

[Rajat-Dabade]

@rahimrahman, in which case this code will execute, as we are adding padding to the string with 0, this means the _previousNumberString and anumateToNumberString lengths will always be equal.

[rahimrahman]

@Rajat-Dabade When it goes from 1000 to 999 or something extreme like 100000001 to 1. The AnimateNumber doesn't really know what's being fed into it, so we have to be ready for any scenarios.

Take 1000 to 999 as an example. The padStart() only adds leading 0 to the length of animateToNumberString.length to _previousNumberString (not to animateToNumberString). In this case, it sliced 1000 to match the length of 999 thus becoming 000. Then this component knows to animate from 0 to 9 in all 3 digits.

I actually left a comment. If it wasn't clear, maybe we need to tweak it.

[rahimrahman]

@Rajat-Dabade feel free to merge this into your PR at any time. This should not require 2 approval as it is going to be merged into your PR.