I have just added redux-persist to my project and I come across redux persist migration which would is a good way of doing database like migration when you change the shape of your persisted state. My question is since I am currently doing my first version of the app when should I write the redux persist migration now or only whenever I make changes in the future version?
Thanks
It really depends on how your teams and processes work.
You can probably erase and create everything from scratch without a problem while your app is on its developing stage. This is because you don't have any users or customers with an "old" version.
Once it's in prod, you now need to consider what the transition is for your customers. Here's where you want to have a migration process. You also want the followings:
If you're in an organization where you have multiple teams and/or multiple environments, you want to start viewing them as your users/customer as well. QA team is your customer, other team that depend on your service is also a customer. Which means that even if your app is on its developing stage, you cannot rely on nuking everything, but need to handle a migration process, with the tests I described before.
It depends, if you have consumers you probably want a migration process
PS: worth mentioning that this analysis is not coupled to redux persistence, but to general database structure migration. You could apply the same principles when migrating a SQL table structure
