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.