Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

string - leftpad, rightpad would be usefull #43

Open
maku opened this issue Oct 19, 2014 · 16 comments
Open

string - leftpad, rightpad would be usefull #43

maku opened this issue Oct 19, 2014 · 16 comments

Comments

@maku
Copy link

maku commented Oct 19, 2014

I would need additional string filter for padding (leftpad, rightpad)

What do you think?

@a8m
Copy link
Owner

a8m commented Oct 19, 2014

@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...

@mallowigi
Copy link
Contributor

Why in the world would we need something like that?

@maku
Copy link
Author

maku commented Oct 19, 2014

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

@a8m
Copy link
Owner

a8m commented Oct 19, 2014

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...

@codeedog
Copy link

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.

@mallowigi
Copy link
Contributor

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.

@mallowigi
Copy link
Contributor

I think for all esoteric filters we should open another project (same as lodash-contrib or sugar-contrib) and keep this one clean.

@codeedog
Copy link

@mallowigi nice suggestion, best of both worlds. I wonder if there are any current filters that could be migrated into the secondary library?

@mallowigi
Copy link
Contributor

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!

@a8m
Copy link
Owner

a8m commented Oct 19, 2014

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..

@maku
Copy link
Author

maku commented Oct 20, 2014

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)

@a8m
Copy link
Owner

a8m commented Oct 20, 2014

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

@maku
Copy link
Author

maku commented Oct 20, 2014

@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 ...

@richardm
Copy link

I'm with @maku on this one - if we have it, it should pad to a certain length.

@danrevah
Copy link

I think a padding would be a good idea. and I can certainly could find it useful in my projects.

@Adriien-M
Copy link
Contributor

+1 for the feature, padleft is very useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants