feat(ngList): support whitespace control through ngTrim

[petebacondarwin]

This PR sits on top of #4344 to make ngList consistent with standard use of ngTrim and useful in scenarios where you want to split on whitespace strings.

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#8216)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[petebacondarwin]

@IgorMinar, @purcell, @tedjp, @hnordt - can you take a look at this ngTrim feature?

[caitp]

okay, having read this, I think we're saying that ngTrim now affects the way ngList separators work, by making whitespace before/after the separator optional (or not)?

The feature seems okay, but reading the markup in the tests, it's not totally communicating the intent of this behaviour to me. Either way, I guess that makes sense.

[petebacondarwin]

Yes that's the idea. I'm not sure how to make the tests clearer. @caitp any ideas?

[purcell]

@petebacondarwin Looks sound to me.

[caitp]

@petebacondarwin I don't think the tests are the problem, to me I just think that using the feature declaratively is not really self-documenting. It's not clear that ng-trim="false" means "don't trim the whitespace separator". ng-trim-separator would be clearer, but we don't want to add a new attribute, so it's fine

[IgorMinar]

this looks good to me.

@caitp from the user perspective ngTrim is applied onto the individual parts in the list and not on the separator, so ng-trim-separator doesn't make things any better.

[caitp]

@IgorMinar not if you read the tests, that's not actually what's happening. I mean, in practice, it is what's happening, but it's not how you'd describe the end result --- so the end result doesn't seem to make sense based on the input. I think a new attribute would make more sense, but I don't think we want to add a new attribute, so it looks good to me. (It's just, confusing, I think this will result in code which is actually more confusing than it should be --- but maybe that's better than adding yet another API to make it clearer)

[petebacondarwin]

@IgorMinar

Yes, I was trying to minimize changes to the API. One of the goals of this PR was to fix up ngList without trying to add too much complexity to the directive [https://github.com//pull/2561#issuecomment-20843976].

Much of this has been discussed before in #2561 and #4008.

The standard meaning of ngTrim is to trim (or not) whitespace from the model value. In this case I have implemented ngTrim in ngList so that it trims each list item, as you say. But in addition, we want to be able support a couple of scenarios easily:

1. trim the separator but not the joiner: e.g. split on "," but join on ", ".
2. split on a separator that is only white space: e.g. "\n"

To accomplish this I have deputized the ngTrim attribute, in such a way that (to me) seems intuitive. In simple terms, if you specify ngTrim="false" then no trimming of anything (separators nor values) will occur. I outline this in the update to the docs:

The behaviour of the directive is affected by the use of the ngTrim attribute.

• If ngTrim is set to "false" then whitespace around both the separator and each
  list item is respected. This implies that the user of the directive is responsible for
  dealing with whitespace but also allows you to use whitespace as a delimiter, such as a
  tab or newline character.
• Otherwise whitespace around the delimiter is ignored when splitting (although it is respected
  when joining the list items back together) and whitespace around each list item is stripped
  before it is added to the model.

Does this seem reasonable too? I think @caitp is not 100% happy but is being pragmatic and thinks it is a fair compromise.

[petebacondarwin]

Landed as 8d18d20