The scenerio is this: During signing up, Users will be given ‘x’ amount of coins. This is a resource that is finite but will refresh every month.
For example, A user may have 50 coins on the first of january. Each time the user clicks a ‘submit’ button, they can reduce the amount of coins they have by any amount they choose. They can continue to click this button and reduce their monthly coin amount as much as they want up until their coin balance is 0.
Say this user reduces his coin balance by 15 the first time, 25 the second, and finally 10 the third (these numbers are chosen by the user so can be retrieved from an input), how could I show the remaining coins before they were to press the submit button.
Right rigght, and to build the ‘this instance’ logic, would an API endpoint be the most suitable solution? As in schedule it to run every 30 days so every 30 days is a new instance. If that were the case eventually it would misalign with the months, as not every month will have 30 days.
I thought the ‘this instance’ was being set via a user input? In which case just use the input’s value.
If it’s being set some other way (such as from a database entry) then use that instead.
If you’re asking how to ‘Refresh’ the user’s coins each month then, yes, a backend workflow is the way to do it.
You can run it every 30 days if you like, but it would seem more logical to run it on the first day of each month (or any other day), that way you won’t have the issue of it being out of since with the months.
So for your scheduling you can use something like: current date/time: +months(1): rounded to month or current date/time: + months (1): change date to 1
Ah perfect, thats exactly what i was getting confused with; the logic on how to set a Refresh on the first of each month. Thanks Adam! There really is always a way haha
