Hi folks! I'd like to hear your feedback on a proposal idea I have and that I
couldn't find anything on. Here is what I have so far.
With the rising popularity of functional programming patterns in JavaScript,
functions that take an object and return the value of a property are
ubiquitous. These are some popular examples:
```js
// filtering by a boolean property
const activeProducts = products.filter(product => product.active);
// mapping
const productNames = products.map(product => product.name);
// sorting, grouping, etc
const sortedProducts = _.sortBy(products, product => product.name);
const { true: activeProducts, false: inactiveProducts } = _.groupBy(
products,
product => product.active
);
```
This pattern is so common in fact that libraries like `lodash` (and frameworks)
often also accept passing the name of the property as a string:
```js
const sortedProducts = _.sortBy(products, "name");
```
However, this technique has various problems:
1. It requires extra code from the library authors. With its typical
disadvantages.
2. It has a potential negative impact on performance.
3. It is not easily statically analyzable, which makes it hard to type-check,
infer, and for tooling to catch typos.
Several languages have solved these problems by introducing some syntactic
sugar that simplifies the definition of these functions. My favorite example is
Elm's: `.property` shorthand [1]. If JavaScript supported this syntax, we could
write the previous examples as:
```js
const activeProducts = products.filter(.active);
const productNames = products.map(.name);
const sortedProducts = _.sortBy(products, .name);
const { true: activeProducts, false: inactiveProducts } = _.groupBy(products,
.active);
```
This is, in my opinion, nice to read and write. Besides, since this expression
simply yields a function, it would not have any of the problems the string
approach has.
Combined with the pipeline operator proposal, it would allow code like the
following:
```js
orders
|> filter(.active)
|> flatMap(.products)
|> .length
```
Lastly, engines might be able to optimize this further (or more easily) than
normal functions since functions defined this way would be restricted to
returning a constant property of the object that is passed to them. They would
not be able to have any other expressions or statements in them. Unfortunately,
they would not be considered automatically pure because users can implement
side effects in property getters or Proxies.
I could not think of any syntax ambiguity this could cause, but I would
appreciate your thoughts in this regard. It does look similar to the RHS of a
Member Expression, but it would not be ambiguous because the two would not be
allowed under the same contexts. The F# community has had an interesting
ongoing conversation [2] about the topic, but it is my understanding we would
not have these problems in JavaScript since Call Expressions require
parenthesis.
[1] https://elm-lang.org/docs/syntax#records
[2] https://github.com/fsharp/fslang-suggestions/issues/506
I am looking forward to hearing your feedback!
Agustín Zubiaga
Head of Engineering @ PINATA
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
