How I started my journey into React Native

I had my first experience with React Native as a Quality Assurance Engineer at Shopee. To give you folks some context, Shopee is the leading e-commerce firm in Southeast Asia and Taiwan. You can compare it to Temu here in the US, and the user interface of both platforms is deceptively similar.

Since I was in the Test Automation department, I didn't have to touch the React Native code itself. However, I had to familiarize myself with React Native, because the devs were migrating the app from the pre existing Kotlin codebase to React Native, to ensure a consistent codebase across the iOS and Android applications without having to work with two separate technology stacks (Swift and Kotlin/Java).

As any engineer who has worked on a major enterprise system would know, migration from another platform or technology to another is a painful and long process. It can take anywhere from a couple of months to years, depending on how complex the codebase is, how much resources your team can allocate and how business critical the code is. While developers often make breaking changes in the process, the engineers on the testing side have to play catchup.

I had joined the team as this migration was still about half way through, and one of the first things I had to figure out where the IDs associated with the elements being tested were Android or React Native IDs. This helped determine where the tests had genuinely caught some bugs in the application or had yet to be updated to reflect code changes due to the React Native migration.

After leaving Shopee, I had not worked on any mobile app project for a while. Earlier this month however, I was roped in to lead the development of a mobile app called Recyclepedia that Florida Community Innovation, a non profit organization in the civic tech space aiming to empower the citizens of Florida with trusted resources and critical social service, is building in partnership with another non profit, Dream in Green, for the residents of the Miami Dade County.

In the last couple of days, I have been working on a feature rich home page, which includes a calendar showcasing recycling and sustainability events organized by community partners in Miami.

Why am I writing this post?

Now that I have gone into a lot of detail about my background, let me cut to the chase. The reason I am writing this post: I found myself hitting roadblocks a couple of times while handling dates and I'm hoping that any devs facing similar issues would find the journalling of my experience helpful.

As I was implementing a feature for users to select the range of dates for any event they could submit to be included in the calendar, I found myself struggling to get the right dates highlighted.

The hiccups I ran into

At first, I suspected this was due to an implementation error, a rookie "off-by-one" bug. As I dove in deeper, however, I found that I was storing the dates correctly.

As it turns out, the utility functions within the date-fns library, addDays and subDays, don’t always give the expected output.

You run into a similar problem when you try to format a date value.

import {format} from "date-fns";

format(new Date("2025-04-26"), "yyyy-MM-dd")) 
# Expected: "2025-04-26", Output: "2025-04-25"

Furthermore, native Date objects are processed slightly differently on the V8 JavaScript engine, used by browsers like Chrome and by Node.js, as compared to mobile platforms like Android or iOS using React Native. As the ECMA262 specification is not compatible with the ISO8601 spec for some situations, we have to be very careful when parsing dates using the Date() constructor.

How do we resolve these issues?

That's why it is recommended to work with Unix timestamps instead of string representations which are parsed differently for different engines.
The main issue with this though, is that Unix timestamps are not easily understood by humans.

To be consistent with date parsing, it’s better to use a utility library to format and manipulate Date objects consistently across your codebase rather than rely on the native Date object.

My own take

Even after using date-fns’s utility functions, I still found working with those dates across different React Native components to be more tedious than I expected. I mean, what’s with all these different tokens for formatting date strings?

That’s why I decided to give dayjs a shot. So far it seems like a cleaner solution, where you can wrap date strings and date-like objects within a dayjs object before you manipulate them using object methods, but I’ll have greater clarity once everything has been implemented.

Final thoughts

Whatever it is, make sure that you stick to a library that manipulates dates in a consistent way - whether it's moment, date-fns or dayjs. Don’t mix-and-match different Date methods and representations. This will save you a lot of pain as you go working with dates across different platforms.