The padding methods work by just simply giving a string or number that I want to pad with some kind of string pattern, typically a zero or space. The only other issue of concern is where the padding should be done. Should the padding be done at the beginning, or end of a string, or split between the begging and end? Some padding solutions allow for a third option to set this, but with lodash there are three separate padding methods for each of these.
Say you have unformatted account numbers that must be formatted in a way that if the number is less then ten, then zeros must be appended to the beginning of the number to make it ten numbers. For this I would want to use the _.padStart method compared to the others.
Another common use of padding is to format a value that has to do with money. Say I have a variable that represents a sum of money, and I want to display this sum of money in a way in which it is always a certain standard string size. This could be for some kind of game, or something to that effect where the sum of money can be between $0000.00, and $9999.99.
these seem to work just the same as the lodash equivalents.
When I look at my site stats it would appear that there is not much concern with my browser stats at least. However if I am in a situation in which I am getting a fair amount of traffic from people that are using older browsers this is a method where a polly fill may be needed. I often start out my making or finding a stand alone method that can be used with call. By making it the kind of method that can be used with call on a String that helps to make it so it is ready to be monkey patched into the string prototype if need be.
This is a polly fill that I came up with but there are many others out there as well, as long as the method does what it needs to do without any major issues. In here I am using a crude yet effective vanilla js solution for _.fill as well, if interested you might want to check out my post on _.fill as well.
This is why it is nice to work inside the context of a framework where all these things have been figured out before hand so I can just get going with a project, and not get caught up in these rabbit holes. Because My solution make use of Array.map, I might want to also provide a pollyfill for that as well, depending of course on how far back I want to go with backward comparability.
So to assure that both Array.map, and Array.padStart are in the Array, and String prototypes I would want to feature test for both of them, using the native solution if there, and if not monkey patch them in.
This is why devs like lodash, you just need to know how far backward compatibility goes with the version of lodash that you are using, and if what it supports works fine for you, then you can just get going with development, and be done with this. Here I am using the pollyfill for map that can be found on the Mozilla page of Array.map, and you might also want to check out my post on the lodash
A nice concise solution that will work okay on most platforms might involve just the use of the String slice prototype method called off of a string that is the concatenation of a string of chars that consists of the padding char that is also the max length of a resulting string. Just give the slice method a negative index value that is also the max number of chars in the resulting string. In the event that the value is just one char, then it will take two of the padding chars along with that one char when slicing from the right of the concatenated string.
So the lodash pad methods _.pad, _.padStart, and _.padEnd are great methods for padding a string or number value into a nicely formated string. there are native solutions for this as well, but in any case always be aware of browser supper as always. If you liked this post you might want to check out my many other posts on lodash, and if you would like to add something feel free to let me know in the comments. Thank you for reading.