4 ms·
I see two limitations with your version above: 1) consts in JS aren't deeply immutable, so technically these could be mutated. This is a relatively small issue
by brundolf 5y ago
I see two limitations with your version above:
1) consts in JS aren't deeply immutable, so technically these could be mutated. This is a relatively small issue, but also...
2) More and more stuff happens in expression-contexts these days, including (most prominently) JSX. And JS doesn't let you define intermediary consts in expression-contexts (or even in lambdas, unless you build out the full curly-braces and add a return statement). So for many situations the consts version is arduous or even impossible.
- zodiakzz 5y ago1. Pipe proposal doesn't make anything deeply immutable either. In JS you can even use a curly braces block to avoid leaking your let/const variables. 2. I am dreading even thinking about how the pipe thing is supposed to operate on JSX. There's the do-expression proposal to achieve what you want in a sane way: https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions
- brundolf 5y ago1. It doesn't, but mutation is generally less likely to happen in an expression context than in a statement context (partly by convention, but also it's common to eg. lint against assignments in expression contexts) 2. Personally I think it will be quite elegant. JSX itself is an expression, not a function, so it would only ever be the last stage in a pipe (or the context in which a pipe expression is embedded). Note that it would be useful even for just (for example) string transformations that happen to be deeply embedded in some JSX, not exclusively contexts where JSX is directly involved 2b. I didn't know about do-expressions; those look potentially exciting