Skip to content

Latest commit

 

History

History
58 lines (36 loc) · 3.03 KB

0015-remove-filters.md

File metadata and controls

58 lines (36 loc) · 3.03 KB
Raw
  • Start Date: 2019-11-12
  • Target Major Version: 3.x
  • Reference Issues: N/A
  • Implementation PR: N/A

Summary

Remove support for filters.

Basic example

<!-- before -->
{{ msg | format }}

<!-- after -->
{{ format(msg) }}

Motivation

  • Filters' functionality can be easily replicated with method calls or computed properties so it provides primarily syntactical rather than practical value.

  • Filters requires a custom micro syntax that breaks the assumption of expressions being "just JavaScript" - which adds to both learning and implementation costs. In fact, it conflicts with JavaScript's own bitwise or operator (|) and makes expression parsing more complicated.

  • Filters also create extra complexity in template IDE support (again due to them not being really JavaScript).

Drawbacks

  • Filters read a bit nicer when chaining multiple filters vs. calling multiple functions:

    msg | uppercase | reverse | pluralize
// vs
pluralize(reverse(uppercase(msg)))

    However in practice we find chaining with a count beyond two to be fairly rare, so the readability loss seems acceptable.

  • Individually importing or defining methods can be a bit more boilerplate-y than globally registered filters. However, global filters are not fundamentally different from registering specially named global helpers on Vue.prototype. Such global registration comes with trade-offs: they make the code dependency relationships less explicit, and also makes them difficult to provide type inference for.

Alternatives

There is currently a stage 1 proposal for adding the Pipeline Operator to JavaScript, which provides largely similar syntactical convenience:

let transformedMsg = msg |> uppercase |> reverse |> pluralize

Considering there is a possibility of this proposal eventually landing, it is best for a framework like Vue to not provide a similar alternative (especially with syntax that conflicts with existing JavaScript).

That said, the proposal is still at stage 1 and hasn't received updates for quite a while, so it is not entirely clear whether it will end up landing, or whether it will land as it is designed right now. It is risky for Vue to adopt it as part of the official API, since we would be forced to introduce breaking changes if the spec ends up changing.

In Vue 3, template expression parsing uses @babel/parser, and support for the pipeline operator syntax in templates can be enabled via the expressionPlugins compiler option (which is passed on to @babel/parser as its plugins option). Note that the Vue template compiler option only enables the parsing of the syntax - the generated render function needs to be further transpiled by Babel (which is done by default in the new webpack-based setup).

Adoption strategy

Filters can be supported in a 2.x compatibility build, with warnings to guide progressive migration.