I don't think you could make filter() work with the same approach, because it seems like you'd actually have to do computation on the result.

map() works for cases where you don't need to compute anything in the callback, you just want to pipeline the elements into another RPC, which is actually a common case with map().

If you want to filter server-side, you could still accomplish it by having the server explicitly expose a method that takes an array as input, and performs the desired filter. The server would have to know in advance exactly what filter predicates are needed.

▲

svieira 4 days ago | parent | next [-]

But you might want to compose various methods on the server in order to filter, just like you might want to compose various methods on the server in order to transform. Why is `collection.map(server.lookupByInternalizedId)` a special case that doesn't require `server.lookupCollectionByInternalizedId(collection)`, but `collection.filter(server.isOperationSensibleForATuesday)` is a bridge too far and for that you need `server.areOperationsSensibleForATuesday(collection)`?

	▲	kentonv 4 days ago \| parent [-]
		I agree that, in the abstract, it's inconsistent. But in the concrete: * Looking up some additional data for each array element is a particularly common thing to want to do. * We can support it nicely without having to create a library of operations baked into the protocol. I really don't want to extend the protocol with a library of operations that you're allowed to perform. It seems like that library would just keep growing and add a lot of bloat and possibly security concerns. (But note that apps can actually do so themselves. See: https://news.ycombinator.com/item?id=45339577 )

▲

5Qn8mNbc2FNCiVV 2 days ago | parent | prev [-]

Couldn't this be done in some way when validation exists, that the same validation is used to create a "better" placeholder value that may be able to be used with specific conditional functions? (eq(), includes(), etc.)