function getMonthName(monthNumber) {
const date = new Date();
date.setMonth(monthNumber - 1);
return date.toLocaleString([], { month: 'long' });
}
function getMonthName(monthNumber) {
const date = new Date();
date.setMonth(monthNumber - 1);
return date.toLocaleString([], { month: 'long' });
}
The idea is to get the current data that will have the current year, month, day in it, and then to query this date for the previous month. A sane API would just throw an error when the date is out of range. A Js API will quitely give you nonsense instead. Again, side effects have absolutely nothing to do with anything here.
You’ve replied while I was editing, so see that regarding what I mean by side effects.
As far as throwing an error when you try to create “31st February”, this wouldn’t actually help much, since the error would still only occur on some days of the year, because your original code doesn’t account for the range of outputs from
Date()when called without arguments.To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.
Side effects are when your function has a reference to some state outside its scope and modifies that state. A function that produces different outputs when it’s called, such as getting a current time is not an example of a side effect. Again, the issue here is that Js tries to infer what to do with a bad input, a number outside acceptable range, instead of simply rejecting it.
My point isn’t that you can’t write a better function that’s less error prone, but the fact that Js allows such things to happen in the first place. It’s a very easily avoidable problem at the API level.