Open maku opened 10 years ago
@maku I think it would be a useful filters.
We can go this way...
string | rpad: string: length[optional]
rpad:
<p>{{ 'foo' | rpad: 'bar' }}</p>
<p>{{ 'foo' | rpad: 'bar': 2 }}</p>
<!--
barfoo
barbarfoo
lpad: same behaviour like rpad
pad:
<p>{{ 'foo' | pad: 'bar' }}</p>
<p>{{ 'foo' | pad: 'bar': 2 }}</p>
<!--
barfoobar
barbarfoobarbar
let me know what do you think...
Why in the world would we need something like that?
I would have thought the following variant (like in the following java lib)
https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#leftPad(java.lang.String, int, java.lang.String)
e.g. {{2 | leftPad:3:'0'}} --> 002 {{'abc' | leftPad:10:''}} --> ******abc and so on
@mallowigi - I hope the reason why someone could need this func. is obvious
I can understand what @mallowigi means.. It's not a common situation, and we always could go this way... for example: rpad:
<p>{{ ('foo'|repeat:3) + 'bar' }}</p>
<!--result:
foofoofoobar
lpad:
<p>{{ 'bar' + ('foo'|repeat:3) }}</p>
<!--result:
barfoofoofoo
pad:
<p>{{ 'bar' | wrap: ('foo'|repeat:3) }}</p>
<!--result:
foofoofoobarfoofoofoo
It is just a matter of what we're prefer, keep angular-filter
thin and robust, or more huge with syntactic sugar etc..
It will be nice to hear more opinions...
I'd vote for thin and robust with a jaundiced eye towards including new things. Is there another way to solve the padding problem? It seems like the filter library is for handling groups (arrays) of objects, not single instance items. This example is single instance. How about a real-world group example? Also, in this case we are dealing with string transformation. Why not use .map on arrays and run it through a function to pad or wrap? Again, edge case vs. common plus bang for the buck.
I agree, this library shouldn't be a pot-pourri of what we can do with angular filters, but rather a collection of useful and common functions that everyone can encounter on a daily basis, such as map, omit, first, capitalize or join. Agreed, some of them are rarely used (such as fuzzy or striptags) and some of them could be easily replaced by other filters (startsWith, wrap...) but this was probably a result of a proof of concept during the early phases of development.
I think for all esoteric filters we should open another project (same as lodash-contrib or sugar-contrib) and keep this one clean.
@mallowigi nice suggestion, best of both worlds. I wonder if there are any current filters that could be migrated into the secondary library?
I don't think it will be possible, a lot of people are using "ngpipe" filters right now, just move them to another repository could be disastrous!
I agree with both of you guys, and appreciate your contributions here. I think @codeedog right, and maybe we could deprecate unused filters.. we can open a new issue and discuss about that, asking people what they are thinking etc etc..
Sorry guys,
I thought when a filter like "wrap" is in the library then left/rightpad is not such a bad idea (btw, I can imagine how I work around wrap but not around the padding filter without providing a scope function)
Don't be sorry @maku, that's the point of discussion. see above the 'work around' examples e.g:
<p>{{ ('*'|repeat:10) + 'foo' }}</p>
<!--result:
**********foo
@a8m sorry thats not the point -> as I wrote:
{{2 | leftPad:3:'0'}} --> 002 {{'abc' | leftPad:10:''}} --> ******abc and so on
which means that padding depends on the length of the input ...
I'm with @maku on this one - if we have it, it should pad to a certain length.
I think a padding would be a good idea. and I can certainly could find it useful in my projects.
+1 for the feature, padleft is very useful
I would need additional string filter for padding (leftpad, rightpad)
What do you think?