Fire Beast

Avoid using boolean fields in Firestore!

One of the challenges of working with Firestore is the complexity of data migrations, so when you model your data, you always should anticipate future changes. But, it's often impossible to predict how your application and hence the database will involve.

One of the rules of thumb that could save you time is "try to avoid boolean fields when you model your data."

The problem with boolean fields is that they limited to only two values: true of false. Even if at the moment you sure that there are only two possible states, that might change in the future.

Imagine you're working on an online journaling application, and you add an ability to share selected entries with invited friends. So you add the public field. After a while, by popular users demand you decide to allow sharing entries with everyone on the Internet, but unfortunately, your public field allows only two states. Another issue is that the field name, public, now confusing as it suits more for entries shared with everyone than the ones shared only with friends.

The better solution would be to use an enumerated type, essentially a string with a defined set of values.

In our example, at the start, we would add the sharing field with two values private and friends. Later, when we would decide to add the ability to share with everyone, we would add another possible value — everyone. Also, this way, the names of the values are more precise and better convey the business logic.

Another example would be the deleted field used for soft deletion. Even if you never add another state to it, you might want to add the date when the document was deleted. Why not join them and instead add deletedAt of the timestamp type. You can use that as the indication that the document is deleted and also know when it happened. In the case if you would want to add another released state, i.e., suspended, activated, etc., you still can do it by adding another enumerated field state and keep using deletedAt as the date when the document got into this state.

So whenever you want to add a field, think twice before making it boolean. A safer choice might be to use enumerated or timestamp types instead.