Spleen does not trim off whitespace `%20`

[hannbarton]

If you send a filter to spleen that has an extra white space at the end of the filter, spleen does not trim it off.

The result from our API returns all records
filter=/data/contactId eq "184348ca-60db-4d86-9e99-40cc8245c0db"%20 <- Extra space

[dsfields]

Hello, @hannbarton. Thank you for your feedback. Indeed trailing space will cause a parser error. If invalid input was provided, the output of spleen.parse() will look something like this:

{
  "success": false,
  "value": null,
  "error": ParserError ...
  }
}

For API development, be sure to check the success value, and if it is false, I recommend returning a 400 error back to the client with information about what was incorrect (contained in the ParserError).

There was a conscious design decision to not trim trailing white space before parsing. The thinking was that extra white space is a sign of a corrupt filter, and a hard error is more desirable than unexpected behavior. If there's a need to trim white space on behalf of a client, JavaScript's built-in String.prototype.trim() can be called prior to invoking spleen.parse().

I'm open to adding a new feature to spleen to support ignoring hanging white space. However, I would not want to do so at the cost of taking away flexibility from implementers. I recommend we create an options argument to spleen.parse() that accepts a value that looks like this:

{
  "trimWhiteSpace": true
}

We can then teach the parser a new trick to just ignore white space at the beginning or end of a filter expression.

[hannbarton]

hello! @dsfields Thank you for taking the time to respond. This was from a little while ago and I ended up realizing that the following was returning
{ "success": false, "value": null, "error": ParserError ... }

(like you mentioned above!). But the Polis team was inadvertently silencing the error in our @PolisPolitics/endpoints-node package. I ended up expressing that error

[hannbarton]

Would you like me to close this issue?

[dsfields]

Let's keep it open for now. I think there's an opportunity to add a trimWhiteSpace directive to the parser.