Vue: [제안] Vue 2.0 - 필터를 다시 가져와주세요

원래 Gitter 채팅에서 나온 요점을 명확히 하자면: debounce 는 필터가 아니며 사람들이 지는 것에 대해 기뻐하지 않은 2.0 변경 사항 중 하나일 뿐입니다.

@JosephSilber 의 수정 제공: debounce 는 필터이자 v-model 매개변수입니다.

@agc93님 감사합니다. 나는 그 점을 제거했다.

스콧

최악의 경우 우리는 이것을 처리하기 위해 작은 플러그인을 만들 것입니다. 필터에 대해서는 https://www.npmjs.com/package/babel-plugin-pipe-operator 가 있습니다.
문제는 이것이 babel 컴파일 없이는 작동하지 않는다는 것입니다.

나도 일부 변경 사항에 대해 너무 흥분하지 않습니다. 필터의 경우 전역 믹스인 을 등록하는 쉬운 대안이 있는 것 같습니다. 그러나 나는 pluralize 등과 같은 매우 간단한 작업을 위해 모든 구성 요소의 메서드 범위를 오염시키는 아이디어를 좋아하지 않습니다. 그러나 양방향 필터를 사용한 적이 없습니다.

필터는 편리하고 아름다웠습니다. vue가 항상 올바르게 수행한 두 가지(지금까지).

vue 2.0에 대한 게시물을 읽었을 때 모든 새로운 가능성(특히 가상 돔 및 서버 렌더링)에 대해 흥분했지만 필터가 사라진 것에 놀랐고 조금 슬펐습니다.

그것들은 내가 vue에서 가장 좋아하는 부분 중 하나였습니다. 쉽게 사용할 수 있고 연결할 수 있기 때문일 뿐만 아니라 주로 쉽게 확장할 수 있고 템플릿에서 직접 사용할 수 있는 아름다운 구문을 가지고 있기 때문입니다. 특히 v-for 루프와 함께 사용하면 완벽하게 일치합니다.

내가 원하는 모든 소품에 대한 필터링을 대체하기 위해 계산된 속성을 사용해야 한다고 생각하면서 앞으로 많은 상용구를 작성하게 될까봐 걱정됩니다. 믹스인이 문제의 일부를 완화할 수는 있지만 여전히 vue 사용의 우아함과 용이함의 일부가 누락될 것 같습니다.

동의하는 모든 분들, 설명 아래에 있는 좋아요를 눌러주시겠습니까? +1 17,000명에게 스팸을 보내는 것보다 낫습니다. 더 좋은 것은 의미 있는 사용 사례를 생각해내는 것입니다.

양방향 필터를 사용한 적이 없지만 필터가 정말 그리울 것입니다! 계산된 속성을 사용할 수 있지만(때로는 사용합니다), 일부 간단한 경우에는 워크플로의 속도를 높이는 편리함이 있습니다.

이 매우 간단한 예를 고려하십시오.

<input type="text" v-model="filter">

<ul>
    <li v-for="item in items | filterBy filter">{{ item }}</li>
</ul>

위의 내용은 더 복잡한 필터링이 필요하지 않은 경우 작성하기가 훨씬 쉽습니다.

이제 다음과 비교하십시오.

<input type="text" v-model="filter">

<ul>
    <li v-for="item in filteredItems">{{ item }}</li>
</ul>

new Vue({
    el: 'body',

    data: {
        items: [],
        filter: ''
    },

    computed: {
        filteredItems() {
            var self = this
            return this.items.filter(function(item) {
                return item.indexOf(self.filter) > -1
            })
        }
    }
})

두 번째 것이 쓰기 어렵다는 말은 아니지만 여러 곳에서 사용하다 보면 스스로 반복하기 시작하고 다른 유용한 기능에 사용할 수 있는 추가 시간이 필요할 뿐입니다!

어느 쪽이든 나는 행복한 Vue 사용자로 남을 것이며 더 이상 사용되지 않는 필터에 대한 내 의견을 공유합니다!

필터는 재사용이 가능합니다. 내 데이터를 한 번 형식화하는 함수를 만들고 필터로 등록하고 모든 인스턴스에서 사용할 수 있습니다. 2.0에서는 어떻게 하나요?

2.0에서는 어떻게 하나요?

• 믹신
• 메소드로 모듈 분리
• 계산된 prop 함수가 있는 별도의 모듈

방금 공지 스레드에 댓글을 남겼으므로 여기에 모두 복사하는 대신 간단히 링크하겠습니다.

http://archive.forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/8

아주 편리한 무언가가 당신에게서 빼앗기는 기분을 충분히 이해합니다. 하지만 먼저 위의 포럼 스레드에서 @chrisvfritz 의 의견을 잠시 읽어보십시오. 토론을 쉽게 하기 위해 복사하여 여기에 붙여넣습니다.

@therzach Vue에 대한 열정에 감사드립니다! 지원 중단에 대해 좀 더 잘 설명하고 싶지만 먼저 저를 소개해야 합니다. 저는 Vue 핵심 팀의 구성원이며 프리랜서 UI 및 데이터 시각화 작업에 항상 Vue를 사용하며 사람들에게 다른 웹 기술 중에서 Vue와 Rails를 사용하는 방법을 가르치는 교육자이기도 합니다. 저는 코드 스쿨을 운영하기 때문에 사람들이 거의 _매일_ 이 도구를 사용하는 방법을 배우고 함께 사용하도록 돕습니다.

나는 또한 Vue 2.0에서 필터 제거에 대한 큰 지지자 중 하나였습니다.

Vue 초보자를 위한 필터 문제

필터 사용 중단에 찬성한 가장 큰 이유는 사실 _for_ 초보자였습니다. 학생들과 작업할 때 다음과 같은 대화가 두 번 이상 나옵니다.

• 학생: "그래서 필터는 기본적으로 함수입니까?"
• 멘토: "네!"
• 학생: "좋아요, 그럼 함수 괄호와 함께 정상적으로 사용할 수 있나요?"
• 멘토: "음, 아니요. 특별한 종류의 기능입니다."
• 학생: "다른 곳에서 사용할 수 있나요? 계산된 값처럼?"
• 멘토: "아니요, 템플릿에서만 사용할 수 있으며 특수한 파이프 구문에서만 사용할 수 있습니다."
• 학생: "...왜?"

초보자를 곤경에 빠뜨리는 가장 큰 것 중 하나는 _예외_입니다. 필터는 기능일 뿐이며 _제외_ 특별한 구문이 필요하며 모든 곳에서 사용할 수는 없습니다. 그리고 그들은 ES7에 통합될 수 있는 파이프 구문과 다른 파이프 구문을 사용합니다. 즉, 사람들이 매우 유사한 작업을 수행하는 두 명의 매우 유사한 연산자가 있을 때까지는 오래 걸리지 않지만 _아주_ 똑같지는 않습니다. 그리고 그 중 하나만이 실제로 JavaScript입니다.

Util 라이브러리는 _are_ 유용하지만 Vue는 그렇지 않습니다.

filterBy , 문자열 및 숫자 변환 및 기타 특정 필터의 경우 예, 해당 필터가 나타나는 응용 프로그램에서 유용합니다. 일반적으로 Util 라이브러리가 유용합니다. 그리고 선택할 수 있는 수십 개의 훌륭한 유틸리티 라이브러리가 있지만 Vue는 유틸리티 라이브러리가 아닙니다. 솔직히 말해서, 우리가 제공한 유틸리티 중 어느 것도 동급 최강의 것이 아닙니다.

통화, 날짜 또는 필터링 배열을 처리하는 것은 우리의 초점이 아닙니다. 많은 앱은 이를 필요로 하지 않으며 내가 작업한 대부분의 앱은 이러한 문제에 직면 _do_ 현재 Vue가 제공하는 것보다 더 강력한 솔루션을 필요로 합니다(또는 상당한 팽창 및 바퀴 재창조 없이 제공 _할 수 있음).

내 앱에서 Accounting.js는 통화를 훌륭하게 처리했고 Moment.js(당신이 언급했듯이)는 날짜와 시간을 처리하고 pluralize 는 많은 복수화를 잘 처리하지 않으므로 사용자 정의 계산 값이 더 바람직하고 json 는 JSON.stringify 보다 약간 더 많습니다.

계산된 속성의 장점

필터 대신 계산된 속성을 사용하면 처리된 값을 구성 요소의 _어디서든_ DRY 방식으로 쉽게 재사용할 수 있다는 이점도 있습니다. 내 앱에서 항상 이 작업을 수행해야 합니다. 계산된 속성은 또한 템플릿에서 더 많은 구현 세부 정보를 이동하여 구성 요소가 수행하는 작업에 대한 명확한 설명만 남깁니다. 전역적으로 정의된 필터에 비해 이점은 해당 컴퓨터 값에 대한 기능만 보고 정확히 작동 방식을 조정하면 된다는 것입니다. 배열에서 JavaScript의 map 및 filter 메서드를 연결하면 파이프가 수행하는 것과 동일한 선형 처리 목록을 제공하지만 훨씬 더 선언적이고 쉽게 조작할 수 있습니다.

전역적으로 정의된 것의 유용성

모든 구성 요소에서 액세스할 수 있는 기능이나 다른 것을 정의해야 하는 경우 Vue.prototype.whateverIWant = mySuperCoolFunction 가 좋은 방법입니다. 개인적으로 나는 한 번도 하고 싶지 않았습니다. 저는 항상 도우미 메서드를 모듈에 넣고 필요한 곳에 해당 모듈을 가져오는 것을 선호했습니다. 그러나 모든 종류의 전역 등록이 더 어려워지지 않는다는 점에 유의하는 것이 여전히 중요합니다.

debounce 지시어의 경우

나는 이 일에 대해 실제로 당신과 함께 있다고 말해야 합니다! 나는 최근에 모든 Vue 프로젝트를 살펴보았고 input 어딘가에 debounce 가 있는 모든 단일 프로젝트도 사용했습니다. 사실, 제 과거 응용 프로그램 중 단 하나만이 디바운스를 _사용하지 않았습니다_. 기술적으로 유틸리티인 lodash 및 기타 여러 강력한 프로젝트가 디바운스 솔루션을 제공하지만 이 문제는 _모든_ 종류의 앱에 대해 UI 개발에 매우 ​​보편적입니다. 자신의 디바운스 기능을 작성하는 것 또한 거의 모든 프로젝트에 lodash의 구현을 사용하고 싶을 만큼 간단하지 않습니다.

이에 대한 내부 토론이 남아 있으므로 어디로 가는지 살펴보겠습니다. 그러나 예, 개인적으로 그리고 일부 다른 사람들에게도 보이는 것처럼 디바운스를 제거하면 v-model 에서 제공하는 대부분의 편의가 제거됩니다.

다시 한번, 당신의 열정에 감사드립니다!

진심으로, 우리는 당신이 Vue를 얼마나 사랑하는지 사랑하고 당신이 당신의 우려를 표명하는 것을 정말로 기쁘게 생각합니다. 특히 친절하고 정중한 방식으로 말입니다! 우리는 당신을 듣고 있습니다. 핵심 팀은 모두 디자이너, 프런트 엔드 개발자 및 데이터 시각화 전문가입니다. 우리 모두는 꽤 다양한 작업에 Vue를 사용합니다. 그래서 우리는 우리가 먹고 싶은 dogfood를 밀어내기 위해 확실히 전념하고 있습니다. :-)

Talk는 저렴합니다. 필터가 없는지 코드를 작성하여 filterBy를 적용하고 반대로 합시다.

코드 재사용을 위해 별도의 파일에 전역 순수 필터 기능 작성

//
// filters.js
//
function filterBy(list, value) {
  return list.filter(function(item) {
    return item.indexOf(value) > -1;
  });
}

function findBy(list, value) {
  return list.filter(function(item) {
    return item == value
  });
}

function reverse(value) {
  return value.split('').reverse().join('');
}

export {filterBy, reverse, findBy}

App.vue 템플릿에서 필터 사용

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ reverse(msg) }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in filterBy(words, userInput)">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in findBy(words, userInput)">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
import {reverse, filterBy, findBy} from './filters.js'
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
  methods : {
    reverse,
    filterBy,
    findBy,
  },
}
</script>

http://raywill.github.io/vuefilter/ 에서 결과를 참조하십시오.

필터를 사용하는 경우 다음 vue 코드도 동일하게 수행됩니다.

<template>
  <div id="app">
    <h1> Reverse Demo </h1>
    <p> {{ msg | reverse }}</p>

    <hr />

    <h1> Filter Demo </h1>
    <input v-model="userInput" />
    <h2> Prefix Matched Words: </h2>
    <ul v-for="word in words | filterBy userInput">
      <li>{{word}}</li>
    </ul>

    <h2> Exact Matched Words: </h2>
    <ul v-for="word in words | findBy userInput">
      <li>{{word}}</li>
    </ul>
  </div>

</template>

<script>
export default {
  data() {
    return {
      userInput: '',
      msg: 'Hello Vue!',
      words: ['Black', 'Block', 'Blue', 'Alpha'],
    }
  },
}

분명히 지원되는 필터를 사용하면 덜 간단한 코드를 작성할 수 있습니다.
개인적으로 코딩을 더 즐겁게 만드는 vue 1.0 방식을 선호합니다.

상용구 문제에 관해서는 여러 가지 방법으로 처리할 수 있습니다.

1. 명시적으로 가져오기/내보내기

위에서 설명한 @raywill 처럼. 좀 더 장황하지만 이점은 다음과 같습니다.

1. 작동 방식을 이해하기 위해 Vue의 필터 문서를 조회할 필요가 없습니다. 기능의 출처와 구현 방법은 매우 명시적입니다.
2. 함수 자체는 JavaScript일 뿐입니다. 만질 수 없는 내장 필터와 달리 특별한 사용 사례에 맞게 변경/구성할 수 있습니다.
3. 메서드, 계산 속성 및 JavaScript를 작성하는 모든 곳에서 이러한 함수를 가져와 프로그래밍 방식으로 재사용할 수 있습니다.

2. Vue.prototype

Vue.prototype.filters = {
  filterBy: ...,
  orderBy: ...
}

<ul v-for="word in filters.filterBy(words, userInput)">
    <li>{{word}}</li>
 </ul>

3. 기능 전환(고급 사용자용)

computed: {
  filteredThings () {
    return this.things
       .filter(contains(this.foo))
       .sort(by(thing => thing.bar))
       .slice(0, 10)
  }
}

도우미 기능은 다음과 같습니다.

// a function that returns a predicate function for array.filter()
function contains (value) {
  return thing => thing.indexOf(value) > -1
}

function by (getValue) {
  return (a, b) => {
    return getValue(a) > getValue(b) ? 1 : -1
  }
}

다시 말하지만, 매우 중요한 설계 고려 사항은 내장 필터가 유용할 수 있지만 순수한 JavaScript의 유연성이 부족하다는 것 입니다. 내장 함수가 필요에 맞지 않으면 비슷한 것을 다시 구현하거나(그리고 둘 다 최종 코드에 포함되어 내장 기능이 쓸모 없게 되는 데드 코드가 됨) Vue가 다음을 수행할 때까지 기다려야 합니다. 업데이트하고 새 버전을 출시하십시오.

@yyx990803 프로토타입 방식이 마음에 드는데 여러 필터가 필요한 경우는?

filterBy orderBy 를 사용하는 것은 매우 일반적입니다.

<ul v-for="word in filters.orderBy(filters.filterBy(words, userInput), column, -1)">
    <li>{{word}}</li>
 </ul>

limitBy 도 추가하는 경우는 어떻습니까?

<ul v-for="word in filters.limitBy(filters.orderBy(filters.filterBy(words, userInput), column, -1), limit)">
    <li>{{word}}</li>
 </ul>

이 접근 방식을 사용하면 코드를 덜 읽을 수 있습니까?

예, 적어도 제 생각에는.

filterAndOrderBy 와 같은 필터를 결합할 수 있지만 그것도 옳지 않다고 생각합니다.

저는 변경 사항에 대해 개방적이며 거의 쉽게 처리할 수 있는 방법을 찾고 싶습니다!

또한 필터를 어디서나 사용할 수 있다는 장점도 정말 좋은 포인트입니다.

참고로 @vuejs/collaborators는 현재 통합 필터의 유틸리티 패키지를 제공하는 옵션에 대해 논의하고 있습니다. 코드 기반을 위한 유틸리티 도구를 제공할 리소스가 많이 있습니다.

핵심 필터를 제거할 때 한 가지 좋은 점은 이제 직접 사용자 정의/구현할 수 있다는 것입니다. 훨씬 더 많은 유연성을 제공합니다.

@rigor789 템플릿 표현식은 최대한 단순해야 합니다. 이상적으로는 <div v-for="filteredData"> </div> 와 같습니다. 이것은 필터링된 데이터를 생성하기 위한 논리를 보유할 수 있는 계산된 소품일 수 있습니다. 이것은 훨씬 읽기 쉽고 다음과 같은 것보다 낫습니다.

<div v-for="item in filters.orderBy(filters.filterBy(words, userInput), column, -1)"> </div>
또는
div v-for="item in data | filterBy | orderBy " 요법

계산된 속성으로 할당하는 것이 훨씬 더 재사용 가능하며 자식 구성 요소로 전달될 수도 있습니다. 필터링된 데이터를 두 곳에서 사용하려면 어떻게 해야 할까요? 표현식에 연결된 필터가 있는 것과 비교하여 템플릿에 단순한 표현식이 있는 것이 더 쉽고, 간단하고, 안정적이고 가독성이 높습니다.

팔로우하는 사람을 위해 저는 @chrisvfritz에 답변 http://forum.vuejs.org/topic/3891/announcing-vue-js-2-0-public-preview/17

다음은 전 세계적으로 사용 가능한 _매우_ 소수의 순수 보기 도우미 함수의 사용 사례를 해결합니다. 필터 제거 문제를 철회합니다. 불태워라! 🔥 인터넷에서 누군가의 마음을 바꿔준 @chrisvfritz 와 @yyx990803 을 축하합니다!

Vue.prototype.filters = {
  filterBy: ...,
  orderBy: ...
}

<ul v-for="word in filters.filterBy(words, userInput)">
    <li>{{word}}</li>
 </ul>

@yyx990803 에 전적으로 동의하고 필터를 제거하고 일반 JS 기능을 고수합니다.

@blake-newman 아주 좋은 지적입니다. 저는 이 시점에서 대부분 확신하고 있으며 가독성에 대해 생각하면 이와 같은 것을 달성할 수 있다고 생각합니다.

computed: {
    filteredItems() {
        return f(this.items).filterBy(this.filter /* string or function*/)
                            .orderBy(this.field, -1)
                            .limitBy(10)
                            .apply()
    }
}

다음은 개념의 빠른 jsfiddle입니다.

핵심 필터를 제거할 때 한 가지 좋은 점은 이제 직접 사용자 정의/구현할 수 있다는 것입니다. 훨씬 더 많은 유연성을 제공합니다.

항상 직접 사용자 정의/구현할 수 있었습니다.

Vue는 유틸리티 라이브러리가 아닙니다. 솔직히 말해서, 우리가 제공한 유틸리티 중 어느 것도 동급 최강의 것이 아닙니다.

우리가 우려하는 것은 템플릿에서 필터 기능을 제거하는 것입니다. 내장 필터를 제거하는 것은 의미가 있습니다. 밑줄/기타 유틸리티 라이브러리에 프록시를 사용하여 쉽게 다시 만들 수 있습니다. 그런 다음 누군가는 현재 내장된 모든 필터를 재생성하는 단일 플러그인을 출시할 수도 있습니다.

필터 대신 계산된 속성을 사용하면 처리된 값을 구성 요소의 어느 곳에서나 DRY 방식으로 쉽게 재사용할 수 있다는 이점도 있습니다.

물론 다른 곳에서 재사용해야 하는 경우 계산된 속성을 사용할 수 있습니다. 그러나 그렇지 않은 경우 필터가 훨씬 더 편리합니다.

위에 공유한 해당 링크 에 게시한 다른 요점이 있습니다.

ES7 제안 구문처럼 작동하는 필터 구문을 지원하지 않는 이유는 무엇입니까? 그렇게 하면 사람들이 사랑하는 필터를 계속 사용하고 미래의 상황에 맞춰 필터를 사용할 수 있습니다. 결국 ES7 파이프가 있으면 API를 변경하지 않고 내부 구현을 전환할 수 있습니다.

ES7 파이프가 승인되었거나 변경 사항이 많습니까?

이론적으로 변경될 수 있지만... 안정적인 것 같습니까?
상태: mindeavor/es-pipeline-operator#33

@JosephSilber @young-steveo @thelinuxlich 일반적으로 파이프의 가치에 대해 같은 생각을 하고 있다고 생각합니다. 😃 2.0의 새로운 컴파일러의 한 가지 장점은 생성된 렌더 함수 코드를 Babel을 통해 파이프할 수 있다는 것입니다. 이것은 여전히 ​​더 탐구해야하지만 |> 가 더 많은 추진력을 얻고 이에 대한 Babel 플러그인이 개발되면 앱에서 _모든 곳에서_ 파이프로 메소드를 다시 행복하게 연결할 수 있다는 것은 상상할 수 없습니다. LiveScript 및 기타 기능 언어의 열렬한 팬으로서 저는 그 가치를 확실히 인식하고 있습니다 !

이 파이프라인 연산자는 0단계에 있지도 않습니다.

@thelinuxlich 예, 저는 그들이 여전히 TC39에서 챔피언을 기다리고 있다고 믿습니다. 😞

@rigor789 그것도 제가 언급하고 싶은 대안 중 하나입니다! JavaScript의 힘으로 원하는 표현을 할 수 있으며 템플릿 내부에 필터링 논리를 넣는 것보다 훨씬 좋습니다.

@yyx990803 다음과 같은 경우 한 사용자의 이름이 업데이트되면 Vue가 어떻게 작동합니까?

<div v-for="user in users">
  <p>{{ user.name |> capitalize }}</p>
</div>

Vue.extend({
  computed: {
    displayableUsers() {
      for (user of this.users)
        user.name = capitalize(user.name);
    },
  },
});

전자는 하나의 객체만 다시 렌더링하고 후자는 전체 목록을 다시 계산하는 것처럼 보입니까?

@rpkilby 는 동등하지 않은 것 같습니다. 다음과 같이 될 것입니다.

Vue.extend({
  methods: {
    capitalize () { ... }
  }
})

<div v-for="user in users">
  <p>{{ capitalize(user.name) }}</p>
</div>

여전히 메서드를 필터로 사용하는 아이디어가 마음에 들지 않습니다(직감적으로는 잘못된 것처럼 보이지만 실제로 설명할 수는 없습니다). 어느 쪽이든 필터를 사용 가능하게 만드는 다른 방법에 대해 논의했으므로 +1.

이 스레드에서 제안된 어떤 것도 필터의 표현력과 간결함에 가깝지 않습니다. 그것은 단지하지 않습니다.

그리고 그게 저를 정말 슬프게 만듭니다. 포럼 스레드에서 말했듯이, 이것은 Vue Vue를 만드는 많은 부분을 제거합니다.

저를 찾고 계시다면 구석에서 크게 흐느끼는 저를 찾으실 수 있어요 😟

안 돼요, 이 변화는 좋은 자바스크립트 코딩을 장려합니다. 처리하세요 :)

그래서 저는 @yyx990803 과 긴 토론을 했습니다. 여기서 저는 사용자의 관점에서 _syntax_ 지원을 유지하자고 제안했습니다. 우아하고 자연스럽기 때문입니다. 내 상상은 이랬다.

<li v-for="item in items | filterBy 'name' | orderBy 'title' 1">{{ item.name }}</li>
...
<script>
  ...
  methods: {
    filterBy (items, field) { return filtered; },
    orderBy (items, field, order) { return filtered; }
  }
  ...
</script>

나는 이것이 두 세계의 장점에 접근할 것이라는 인상을 받았습니다.

그래도 결국에는 필터를 전체적으로 제거하는 것이 실제로 더 나은 것이라고 확신합니다. @linuxlich 가 방금 말한 것처럼 JavaScript와 논리 사고를 더 잘 장려합니다. 우리는 Laravel의 Blade나 다른 프레임워크의 뷰 레이어에 로직을 도입하지 않으며 Vue의 템플릿에도 도입해서는 안 됩니다.

즉, @JosephSilber 다른 구석을 보면 저를 찾을 수 있습니다.

나에게 필터는 매우 아름답다고 느끼며 구문은 필터 구문이 어떻게 생겼는지 정확히 알 수 있습니다.

또한 Vue에 대한 한 가지 매력적인 점은 (일부) 배터리가 포함되어 있다는 것입니다. 내 생각에 Vue를 돋보이게 만드는 이 두 가지 중 하나를 잃는다면 정말 슬플 것입니다.

스레드를 읽어보면 필터에 대한 대부분의 우려는 Vue에 기본 필터가 있고 실제로는 기능 자체가 아니라는 사실인 것 같습니다.

@blake-newman의 필터 플러그인 생각이 마음에 들고 미리 빌드된 예제가 있어야 합니다. 다른 사람들이 다른 필터를 생각해 낸다면 플러그 앤 플레이를 해야 합니다. 정말 좋을 것입니다. 필터를 만드는 것은 사용자 영역의 책임이라는 데 절대적으로 동의합니다.

여전히 원하는 것은 파이프 및 연결 기능과 원래 필터 기능의 전역성입니다. 글로벌성에 대한 우려는 @yyx990803에서 다루었습니다. 파이프로 연결하는 것은 어떻습니까? 템플릿을 읽고 출력으로 예상되는 내용을 이해하는 데 많은 도움이 됩니다. 파이프와 체인은 위에서 논의했습니다. 여전히 할 수 있습니까? 왜 나쁜 일입니까? 디자이너에게는 금입니다! 필터는 JS 프로그래머가 아닌 디자이너의 도구입니다. 따라서 내 책에서 더 나은 JS를 작성해야 한다는 주장은 논외로 나왔지만 왜 그것이 필요한지 이해할 수 있습니다. 그러나 디자이너로서 나도 더 나은 코드를 작성하고 싶고 필터를 사용하면 아름답게 할 수 있습니다. :웃다:

스콧

다음은 연결에 관한 사항입니다. 필터는 주로 두 가지 목적으로 사용됩니다.

1. 서식 텍스트;
2. 배열 처리.

텍스트 서식의 경우 90% 이상 단일 유틸리티 방법만 사용됩니다. 이 경우 연결은 그다지 문제가 되지 않습니다.

배열의 경우: 배열 처리는 사실 논리이며 JavaScript에 더 적합하다는 점을 이미 지적했습니다. 여러 개의 연결된 배열 필터를 사용하는 것이 간단할 때는 괜찮아 보이지만 각각에 대해 둘 이상의 인수를 사용하면 보기 흉해질 수 있습니다. 또한 템플릿에 너무 많은 논리를 넣지 말아야 할 때 너무 많은 논리를 넣도록 권장합니다. 또한 유연성이 없습니다(처리된 값을 쉽게 검색할 수 없음). 이에 비해 ES2015의 원래 예는

<div v-for="thing in things | filterBy 'foo' | orderBy 'bar' | limitBy 5">

다음과 같이 쓸 수 있습니다.

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

그것은 단지 JavaScript일 뿐이며, 배울 마법, 대체 구문 및 필터별 API가 없습니다. 그리고 처리된 값(지능적으로 캐시됨)에 액세스할 수 있습니다. 이전 의견에서 볼 수 있듯이 이 위에 설탕을 자유롭게 추가할 수도 있습니다. 또한 템플릿이 더 깔끔해 보입니다.

<div v-for="filteredThings">

나는 이것이 유용한 물건을 없애는 것과 같다는 것을 알고 있지만 솔직히 말해서 지금 당장의 필터에 대한 인수는 구문을 위해 구문을 유지하려는 것처럼 들립니다. 제 생각에는 기능을 정당화하기 위해 "우아하기 때문에" 그 이상이 필요합니다. 객관적인 가치를 제공해야 합니다. 이것은 inline-templates 경우이지만 필터에는 표시되지 않습니다.

@yyx990803 - 귀하의 예는 문제를 잘 보여줍니다. 다시 말하지만, 저는 최고의 JS 프로그래머는 아니지만 filteredThings 가 실제로 하는 일에 대해 아무 말도 하지 않는다는 것을 알기 위해 JS 프로그래머가 될 필요는 없습니다. 나에게 그것은 나쁜 습관입니다. :smile: 필터링 방법이 전역적이라는 사실은 또한 방법이 무엇을 하는지 알아내기 위해 문서, 코드 또는 출력을 해독해야 한다는 것을 의미합니다. 정말 우아하지 않습니다. 오른쪽?

그래서 확인. 우리는 `filterByOrderByAndLimit'과 같은 메소드 이름을 가질 수 있습니다. 주장은 어떻습니까?

<div v-for="filterByOrderByAndLimit(things,thing,'foo','bar',5)">

그게 맞을까요?

그렇다면 실현 가능성이 있습니다. 그래도 잘 안보입니다.

이제 filterBy와 OrderBy만 원합니다. 그렇게하려면 별도의 방법이 필요합니까? 그런 다음 통화 형식을 추가하고 싶습니다. 다른 방법? 템플릿의 필터 체인을 사용하면 프레젠테이션을 유연하고 표현력 있게 조작할 수 있습니다. 이 문제는 아직 메서드로 적절하게 해결되지 않았습니다(그리고 지식이 부족하여 메서드를 더 잘 이해할 수 없습니다).

이것이 가능할까요?

<div v-for="filterBy(things, thing, 'foo').OrderBy('bar').Limit(5)">

템플릿에서 너무 많은 논리를 수행하는 것은 피해야 한다는 데 동의합니다. 그러나 필터 연결과 앱의 구성 요소/템플릿의 아무 곳이나 간단히 필터를 삽입할 수 있는 기능은 환상적인 개념이며 처음부터 추가한 이유가 있습니다. 그 이유는 무엇이었습니까? 당신이 그들에게 이름을 붙일 수 있다면, 나는 그들이 "그러나 그것은 나쁜 관행을 조장하는" 돈보다 1마일이나 더 많은 돈을 걸 것입니다.

Vue 자체와 마찬가지로 유연성을 허용하는 모든 것이 부적절하게 사용될 수 있습니다. inline-template 의 주요 주장은 유연하고 Vue를 다양한 방식으로 사용할 수 있다는 것이었습니다. 필터는 Vue 내부이고 Vue가 외부에서 사용되는 방식에 영향을 미치지 않는다는 점을 제외하고 크게 다르지 않습니다. 그럼에도 불구하고 그 중요성을 평가절하하지 않습니다. 많은 사람들이 이것이 업그레이드할 필요가 없다고 말했습니다. 그것이 중요합니다! :웃다:

새로운 방식에는 이전 방식과 동일한 속성이 필요합니다.

• 연결 가능한
• 글로벌
• 템플릿에 추가하여 템플릿의 데이터가 조작되는 방식을 멋지게 표현

(내가 잊은 게 있니?)

이 모든 것을 할 수 있다면 모두가 꽤 만족할 것이라고 확신합니다. 나는 개인적으로 그것이 (아직) 방법으로 일어나는 것을 볼 수 없습니다.

스콧

@smolinari

1. 템플릿에 논리를 덜 넣어야 한다고 분명히 말했습니다. 이것은 당신이 좋든 싫든 내 의견입니다. 분명히 동의하지 않을 수 있지만 권장되는 모범 사례에 반대하여 작업하고 싶다면 나는 당신을 도울 수 없습니다.
2. 주어진 (1) - 복잡한 논리는 JavaScript에서 수행되어야 하기 때문에 연결이 문제가 되지 않는 이유를 설명했습니다.
3. 또한 전역적으로 사용 가능한 메서드를 추가하는 방법에 대한 예도 제공했습니다.
4. 원하는 것과 유사한 사용자 지정 연결 구문에 대한 @rigor789 의 예 를 참조하세요.
5. 프레임워크의 목표는 _I_ 믿는 모든 사람을 기쁘게 하는 것이 아니라 프론트 엔드 애플리케이션을 개발하는 가장 좋은 방법을 제공하는 것입니다. 따라서 "이 기능을 다시 제공하지 않으면 업그레이드하지 않겠습니다"를 사용하지 마십시오. 작동하지 않습니다.

일주일 동안 이 새로운 알파 릴리스를 사용해 본 후 (실습을 기반으로 한) 정말 가치 있는 의견을 남겨보는 것은 어떻습니까? 기존 앱을 리팩토링하고 불가능했던 점, 개선된 점, 악화된 점을 알려주시면 더 잘 논의할 수 있습니다. 그것은 내가 생각하는 모든 사람에게 유용할 것입니다.

@yyx990803 - 나는 1에 동의했습니다. 그래서 우리는 동의합니다. :스마일: 나는 그것이 너무 많은 사랑을 얻은 무언가를 빼는 것이 합당한 이유라는 데 동의하지 않습니다.

그래서 시간이 지남에 따라 실용적인 JS가 실용적인 HTML보다 낫다고 결정한 것 같습니까?

업그레이드하지 않는다는 주장은 다른 사람들이 말한 것과 같습니다. 나는 단지 의사 소통하고 그것을 완화하려고합니다.

나 자신의 마지막 주장입니다. 사용자의 사용자의 눈으로 이것을 보십시오. 내가 Laravel이나 Vue를 통합하는 다른 MVC 또는 MVVM 시스템과 같은 시스템이 있다고 가정해 보겠습니다. 이 시스템을 사용하면 해당 시스템의 사용자가 자신의 구성 요소를 빌드할 수도 있습니다. 필터는 말 그대로 학습 곡선을 단순화하고 해당 시스템의 사용자가 JS를 건드리지 않고도 많은 작업을 수행할 수 있도록 합니다. 저는 Vue의 팬입니다. JS가 아닌 프로그래머도 여전히 많은 작업을 수행할 수 있기 때문입니다. 이것이 내가 React와 JSX를 좋아하지 않는 것과 같은 이유입니다. 이 조합은 시간이 지남에 따라 Vue보다 훨씬 적은 사용자 기반을 갖게 됩니다. 나는 그것에 돈을 걸 것이다.

나는 또한 진정한 유연성이 JS에 있다는 것을 이해합니다. 그래도 Vue의 유연성을 JS에만 의존하지 마십시오. 모든 사람이 킬러 JS 프로그래머는 아니라는 점을 명심하십시오. 사실, 대부분의 사람들은 그렇지 않습니다. 필터는 그런 사람들을 위해 많은 일을 할 수 있는 좋은 방법이었고 더 많은 JS 조작을 위한 좋은 디딤돌이었습니다. 필터는 할 수 없습니까? JS 메소드에 대해 자세히 알아보십시오.

확인. 나로 충분하다 ..... 나는 끝났어. 그리고 여하튼 들어주셔서 감사합니다. Vue는 여전히 굉장합니다! :웃다:

@azamat-sharapov - 좋은 지적입니다.

스콧

사람들이 JS 내부의 나쁜 관행을 정당화하는 것을 보면 안타깝습니다. 사실 프로가 될 필요는 없고 기본 숙제만 하면 된다(아니면 요즘은 기본아닌가요?)

필터 내부 메서드에 대한 문제는 의미론에 있습니다.

죄송합니다. 필터는 정적 함수와 비슷하지만 메서드는 비정적 기능입니다.

필터는 메서드와 매우 다른 의미를 전달합니다. 가장 큰 차이점은 필터는 this 를 사용할 수 없지만 메서드는 사용할 수 있다는 것입니다.

@yyx990803 Vue.prototype.filters 을 사용하는 동안 작동할 수 있지만 Vue 를 변경하는 것은 나에게 좋은 습관처럼 보이지 않습니다. 차라리 모든 필터를 포함할 별도의(전역) 개체를 만드는 것이 좋습니다.

전역은 좋은 습관이 아니기 때문에 좋은 습관처럼 보이지 않습니다. 권장되는 접근 방식은 명시적으로 도우미 메서드를 가져오는 것입니다. 프로토타입에 연결하는 것은 메서드를 명시적으로 가져오기를 원하지 않는 사람들을 위한 해결 방법입니다.

의미론에 관해서는 - 필터는 어쨌든 만들어진 개념입니다. JavaScript에서는 문자열을 대문자로 표시하기 위해 다른 의미를 만들지 않습니다. 함수를 호출합니다. 그리고 그것이 바로 JavaScript 기능입니다.

주로 "JS 내부의 나쁜 관행을 정당화하려는" 주석 때문에 제 개인적인 요점을 더 명확하게 하기 위해 한 번 더 설명을 하려고 합니다. 나는 확실히 그렇게 하려고 하지 않는다.

Vue가 단순한 템플릿 시스템 그 이상이라는 것을 알고 있지만 템플릿 시스템이기도 합니다. 그러면 안 된다고 생각하는 그 역할에서 멀어지려고 합니다. 따라서 템플릿 엔진/시스템으로서 Twig 템플릿 엔진을 템플릿 시스템에서 기대할 수 있는 것에 대한 매우 성공적인 사례로 생각하십시오. 문서에는 " 템플릿 디자이너를 위한 " 섹션과 " 개발자를 위한 " 섹션이 있습니다. 템플릿 시스템으로서 Twig는 템플릿 디자이너에게도 강력합니다. 필터를 포함한 기본 동작으로 가득 차 있기 때문입니다 . 개발자가 아닌 사람들도 PHP를 직접적으로 알지 못해도 템플릿 시스템으로 많은 작업을 수행할 수 있습니다. 그들은 Twig가 제공하는 것과 그것을 사용하는 방법을 배우기만 하면 됩니다. Vue에서도 이것을 찾고 있습니다. 문서에서 "템플릿 디자이너를 위한 Vue" 섹션도 보고 싶습니다. :웃다:

또한 Twig의 확장성이 매우 중요합니다. 재고 버전에서 사용할 수 없는 것이 있으면 추가할 수 있습니다. 그 때 개발자가 개입합니다. 좋은 점은 확장 프로그램을 공유할 수 있다는 것입니다. 즉, 한 번만 수행하면 됩니다.

이 두 수준의 디자이너/개발자에 대한 또 다른 좋은 점은 훨씬 더 광범위한 사용자 기반을 확보할 수 있다는 것입니다. 훨씬 더 광범위하고 이것은 와 동일합니다. 그리고 기본 동작이 충분하지 않을 때, 즉 기본 언어를 자발적으로 배우기 시작할 때입니다. 그리고 그 때 모범 사례와 나머지를 배우게 됩니다.

Vue는 JS를 배우지 않고는 템플릿 엔진이 될 수 없다고 한다면 시장 가치를 상당히 낮추고 있다고 말하고 싶습니다. 만약 당신이 말한다면, 당신은 다른 사람들이 템플릿 엔진용 도구를 플러그인으로 만들 수 있도록 문을 열어 둘 것입니다. 그러나 모든 사람들은 템플릿 시스템에 있어야 할 것을 위해 싸울 것입니다. 그것은 또한 비생산적인 IMHO입니다.

필터 예제 Evan에 대해 이야기하는 학생에서 JS를 배우는 사람입니까 아니면 템플릿 엔진을 배우는 사람입니까? 후자였다면 이야기가 달라졌을 것 같아요.

여하튼. 나는 여전히 Vue가 이기는 시스템이라고 생각합니다. 내 생각이 다른 사람들이 Vue의 역할에 대해 어떻게든 다르게 생각하도록 만들 수 있기를 바랍니다. :웃다:

스콧

@yyx990803 필터가 신조어 개념이라면 애초에 왜 만든거야?

<template> 내부에서 $ $data 또는 abc 와 같은 모든 외부 변수가 this.$data 및 this.abc 로 변환되고 따라서 일반 js 함수가 정의되기 때문에 믿습니다. 구성 요소 외부는 참조할 수 없습니다. 이러한 한계를 극복하기 위해 필터가 도입되었습니다.

그 제한은 여전히 ​​존재합니다 ---제가 옳다고 가정합니다--- 제한을 제거하려면 개발자가 this.abc this.abc 를 명시적으로 코딩하고 참조되는 js 기능에 액세스해야 합니다. js.

그러나 그것은 너무 강력한 기능이 될 것이며 남용하기 쉽고 오래된 코드를 마이그레이션하는 것은 고통스러울 것입니다. 현재 구문이 그보다 훨씬 좋아 보입니다.

필터는 기본적으로 js 함수이며 구성 요소로 가져와야 한다는 데 동의합니다. 나는 그들이 메소드와 같은 장소에 정의되어 있다는 것을 좋아하지 않습니다.

안녕하세요 여러분. 나는 전체 스레드를 읽고 이것이 내 생각입니다.

• orderBy filterBy 및 기타와 같은 내장 필터를 놓치는 사람 은
• 모든 사람들이 여전히 갖고 싶어하는 것은 템플릿의 파이프 연산자입니다.
• 핵심 팀은 파이프 연산자와 함께 오는 es7 기능 외에 로직이 템플릿이 아닌 자바스크립트로 유지되어야 한다고 말합니다.

js가 네이티브 파이프 연산자를 구현할 때까지 좋은 솔루션이

Vue.use(require('vue-pipe'))

새로운 기능 구현을 기다리는 동안 지원 중단 또는 기타 사항에 대한 경고와 함께 포함될 수 있습니다. 누구나 그 플러그인을 구현할 수 있다는 것을 알고 있지만 Vue 팀에서 제공하고 유지한다면 그게 더 나을 것 같은데 그게 가능할까요?

내가 틀릴 수 있지만 Vue가 플러그인을 컴파일러와 엉망으로 만드는 것을 허용하지 않는다고 생각합니다.

@azamat-sharapov 물론 아닙니다. 나는 그것이 Vue 컴파일러와 엉망이 될 것이라고 생각하지 않았습니다 :open_mouth:

@YerkoPalma 저는 파이프 오퍼레이터를 절대적으로 _사랑_합니다. 나는 그것을 기능적 언어에서 강박적으로 사용하고 JavaScript에서 그것을 갖고 싶어 너무 기대됩니다! __하지만_, Vue에 필터가 없었다고 상상해 보세요. 프론트엔드 프레임워크가 JavaScript의 구문을 확장하도록 요청하시겠습니까? 이것은 UI 프레임워크가 아니라 Babel 또는 compile-to-JS 언어의 영역입니다. 내가 자주 하는 것처럼 LiveScript와 같은 언어를 사용하는 것을 선호한다면 그렇게 할 수 있습니다. 그러나 여기서 문제는 Vue가 아닙니다. 그것은 JavaScript 자체에 있으며 우리는 그것을 고치기 위해 여기 있는 것이 아닙니다.

또한 우리가 바라는 대로 Babel을 통해 2.0의 렌더링 결과를 파이프할 수 있다면 원하는 경우 비 TC39 추적 플러그인을 사용할 수도 있습니다. 그냥 템플릿에서. 따라서 파이프만 원하면 가질 수 있을 것입니다. 그리고 당신은 오늘 1.x에서 그것을 _할 수 있습니다_ - 템플릿에서 사용할 파이프가 Babel의 파이프와 다른 우선 순위와 동작을 가질 가능성이 있다는 점에 주의하십시오.

@smolinari 및 기타. 내가 계속 듣는 두 가지 문구(및 그 변형)가 있습니다.

• "개발자/사용자의 입장을 생각합니다"
• "초보자를 생각하라"

둘 다 가정을 함축하고 있습니다. 우리는 이 그룹을 생각하지 _않습니다_.

전에도 언급했지만 다시 한 번 말씀드려야 할 것 같습니다. 핵심 팀의 _모두_는 디자이너, 프론트엔드 개발자 또는 이 둘의 조합입니다 . 우리는 우리 자신의 작업을 위해 매일 이러한 도구를 사용합니다. 우리는 Vue 2.0도 사용할 것입니다. 저를 믿으세요. 우리는 _생각하고 있습니다. 😉

초보자를 위해 여기에서 사례를 만들었는데 좀 더 자세히 다루도록 하겠습니다. 저는 교육자입니다. 그리고 저는 _초보자를 생각하면서_ 필터 제거를 지지했습니다. 저는 개인적으로 수백 명(아마도 천 명 이상)에게 웹 개발을 연습하는 방법을 처음부터 가르쳤습니다. 이전 코딩 경험이 없습니다. 중학생, 고등학생, 대학생, 전문직 성인, 노인들과 함께 해봤습니다.

그런 관점에서, 필터는 처음에는 흥미진진한 마술처럼 보일 수 있지만, 제한된 편의를 위해 더 복잡함을 도입함으로써 궁극적으로 학생의 학습 속도를 늦추는 것이라고 말할 수 있습니다. 그들이 Angular나 Vue를 사용한 적이 없고 이 대화가 반대였다면 - 우리는 2.0에서 그것들을 _도입_하려고 했습니다 - 우리는 그것들이 왜 필요한지 그리고 언제 사용해야 하는지 설명하는 데 어려움을 겪을 것입니다.

2.0에서 더 이상 사용되지 않는다는 이야기가 나오기 전에 저는 우리 코드 학교의 커리큘럼에서 필터를 제거했습니다. 왜냐하면 우리는 초보자에게 이롭기보다 해를 끼친다는 충분한 증거를 수집했기 때문입니다. 우리는 그들이 메서드 및 계산된 속성과 같은 보다 다양한 Vue 기능에 대한 경험을 얻었으면 합니다. 필터를 사용하면 나쁜 습관을 쉽게 찾아낼 수 있으므로 사용을 권장하지 않습니다.

이 두 가지 불만 사항이 해결되기를 바랍니다. 우리는 볼 것이다. 😃

그러나 Vue에 필터가 없었다고 상상해 보십시오. 프론트엔드 프레임워크가 JavaScript의 구문을 확장하도록 요청하시겠습니까?

물론 필터는 이전에 언급한 Twig에서와 같이 _templates_에 매우 자연스럽기 때문에 그렇게 할 것입니다. 파이프 연산자를 사용하는 것은 템플릿에 콧수염 구문을 사용하는 것만큼 자연스럽다고 생각합니다. 즉, 콧수염은 html이 아니고 자바스크립트도 아니고 여러분도 제거하시겠습니까? 파이프 연산자와 다른 점은 무엇입니까?

"아이들에 대해 생각하라"는 주장은 그냥 멍청하다. 내가 아는 한, Vue는 JavaScript를 가르치기 위해 설계되지 않았지만 프론트 엔드 개발자가 작업을 완료하도록 설계되었습니다. 후자의 경우 필터가 좋습니다.

그들이 Angular나 Vue를 사용한 적이 없고 이 대화가 반대였다면 - 우리는 2.0에서 그것들을 소개하려고 했습니다 - 우리는 그것들이 왜 필요했고 언제 사용해야 하는지 설명하는 데 어려움을 겪을 것입니다.

나는 매우 동의하지 않는다. 저는 2005년부터 Django라고 하는 Python 프레임워크를 사용해 왔으며 이후에 탄생한 대부분의 템플릿 언어에 영감을 준 템플릿 언어는 첫날부터 필터를 사용했습니다. 10년 넘게 프론트엔드 개발자들과 함께 사용하면서 나는 그들의 아름다움과 유용성을 알게 되었습니다. 이 구문이 사라지면 슬플 것입니다.

(Django가 필터로 수행하는 작업은 다음과 같습니다. https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#built-in-filter-reference )

@Uninen 당신의 어조에 주의하십시오 - 다른 사람의 주장을 멍청하게 부르는 것은 토론에 참여하는 건설적인 방법이 아닙니다.

서버 측 템플릿 언어에 대한 드로잉 비유의 경우 - 주목해야 할 한 가지 중요한 측면은 서버 측 템플릿 언어가 Vue 템플릿과 같은 유연성을 갖고 있지 않다는 것입니다(계산된 속성 없음, 제한된 표현식). 또한 - 그것들은 완전히 다른 목적을 위해 만들어졌습니다: 정적 문자열 출력. Vue 템플릿은 양방향 DOM의 표현입니다. 양방향 바인딩, 이벤트 핸들러, 구성 요소 소품 등이 있습니다. 필터는 Vue 컨텍스트에서 매우 제한된 사용 사례에만 적합합니다. 오늘날 저는 v-model, v-for 및 v-on에 대한 필터와 같이 모든 곳에 필터를 허용하는 것은 좋지 않은 생각이라고 생각합니다.

한 가지 가능한 대안은 필터를 유지하되 텍스트 보간에만 사용하는 것입니다. 즉, 지시문이 아닌 {{ }} 내부에서만 필터를 사용할 수 있습니다.

흥미로운 참조로: Angular 2에는 여전히 필터("파이프"로 이름 변경)가 있지만 의도적으로 목록 필터링 필터를 제거했습니다.

제 언어로 죄송합니다. 누군가를 모욕하려는 의도는 아닙니다.

저에게 프레임워크의 목적은 어려운 작업을 수행하고 이러한 도구를 사용하는 개발자가 보기 쉽게 만드는 _is_입니다. 나는 여전히 구문이 이길 수 없다고 주장하며, 다시 말하지만 그것이 사라지는 것을 보는 것은 슬플 것입니다.

나는 내부 메커니즘을 잘 알지 못하거나 이해하지 못하지만 사용자의 관점에서 보면 실용성이 순수함을 능가합니다. :)

관련 메모에서 이 커뮤니티에 얼마나 많은 열정이 있는지 확인하는 것이 흥미로웠습니다. 저에게 Vue는 신선하고 활력을 주는 도구였습니다. 아마도 그래서 제가 이 특별한 창고를 그리는 데 참여해야 했을 것입니다. :)

다른 데이터 포인트의 경우 Ember에는 필터가 없으며 계산된 속성이 있지만 구성 요소 메서드를 허용하지 않습니다.

템플릿 내 변환을 수행하는 순수 함수의 사용 사례의 경우 핸들바 도우미/엠버 도우미를 등록해야 합니다.
http://emberjs.com/api/classes/Ember.Helper.html

핸들바 헬퍼는 핸들바 헬퍼가 아닌 것과 구문적으로 구별됩니다. 그래서 제가 그것을 가져왔습니다. 파이핑 필터 구문과 공통점이 있습니다. 그러나 핸들바 템플릿은 "논리 없는" 템플릿이므로 템플릿 내 함수 호출을 위한 특별한 구문이 필요합니다. Vue에는 없는 문제입니다.

필터는 초보자에게 간단합니다. 배열에서 예쁜 출력 또는 filter\ordersearch를 사용하여 약간의 마술을 볼 수 있습니다.

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}

그리고 쉽게 정의

Vue.filter('moment', (str, format) => moment(str).format(format));

템플릿에서 간단하고 명확합니다. 2.x의 경우 외부 모듈에서 필터를 정의하고 템플릿에서

import moment from 'moment'

methods:{
   moment(date, format){
       return moment(str).format(format)
  }
}

그리고 템플릿에서

 {{ moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss') }}

제안으로 오래된 필터를 템플릿에 남겨두고 필터를 별도의 모듈로 이동하고 메서드 섹션에서 사용하는 것이 어떻습니까?

그러니 필요하시면 그냥 하세요.

npm install vue-utils

utils 패키지의 특정 필터 사용

import {moment} from 'vue-utils/date'
import {price} from 'vue-utils/numbers'

methods:{
   moment, price
}

일반 필터로 사용

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}
 {{ product.price | price }}

결과적으로 간단한 함수 호출로 변환됩니다.

moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss')
price(product.price)

_메모_
나에게 필터는 날짜, 숫자 또는 문자열과 같은 데이터 형식을 지정하는 데 가장 많이 사용됩니다 . 배열\객체 필터링의 경우 일반 vue 모듈에서 계산 및 기능을 더 잘 사용한다고 생각합니다.

import _ from 'vue-utils/array'

computed:{
   ordersTable(){
         return _(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

이익:
초보자는 오래된 필터를 쉽게 사용할 수 있지만 계산된 템플릿에서 데이터 출력 형식을 지정하기 위해 예쁜 기능을 사용하고 프로그래머는 자체 기능 모듈을 작성하여 사용하기 쉽습니다.

_왜 별도의 모듈을 사용합니까?_
Vue의 핵심에 있을 필요는 없다고 생각하지만 Vue에는 개발자 템플릿 디자이너를 위한 일부 유틸리티가 있어야 하므로 항상 lodash, moment 또는 기타가 필요하지 않습니다. npm에서 유틸리티를 설치하고 사용하기 쉽도록 하지만 이전 호출 구문은 저장해야 합니다. 템플릿.
그러나 한 가지 중요한 생각은 필터에 대해 수행되어야 하며, vuex의 getter와 같은 순수한 기능이 있어야 한다는 것입니다.

지원하기 쉽고 사용하기 쉽고 확장하며 템플릿을 잘 볼 수 있습니다.

여러분에게 필요한 것은 명확한 업그레이드 경로와 Javascript 코드를 모듈화하는 방법을 배우고자 하는 열망입니다.

@thelinuxlich 우리는 필터에 대해 이야기합니다.

 {{ article.date.created_at | moment 'MM.DD.YYYY HH:mm:ss' }}

단지 구문 설탕

{{ moment(article.date.created_at, 'MM.DD.YYYY HH:mm:ss') }}

그러나 Vue\javascript에서 초보자를 위한 필터를 완전히 제외하는 것은 좋지 않습니다. Vue와 같은 Laravel 커뮤니티가 필요한 이유는 무엇입니까? 간단하고 강력하기 때문입니다.

필터를 완전히 제거하는 경우 _"템플릿 디자이너를 위해"_에 대한 대안을 제공해야 합니다. 배열을 정렬하거나 필터링하는 방법을 알 필요가 없습니다. 코드 형식 예제를 입력하고 결과를 얻기만 하면 됩니다.

프로그래머는 Javascript 코드를 _modularise__하는 방법을 알아야 하지만 작은 작업에 사용하는 사람은 알 필요가 없습니다.

_"템플릿 디자이너를 위해"_에 대해 말하면

<script src="vue-utils.js"></script>

내부 코드 사용

Vue.use(VueUtils)

computed:{
   ordersTable(){
         return this.utils.array(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

예를 들어 자신을 자랑스럽게 여기고 배열을 필터링하고 정렬하기 위해 js를 알 필요가 없습니다. 많은 사람들이 어떤 일을 하고 싶어하지만 다음과 같은 코드를 이해하기 어렵습니다.

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

따라서 우리가 거기에 간단한 솔루션을 제공할 수 있고 개발자에게 좋은 경우 이러한 유형의 사람들을 위해 복잡한 것을 만들 필요가 없습니다.

한 가지 가능한 대안은 필터를 유지하되 텍스트 보간에만 사용하는 것입니다. 즉, 지시문이 아닌 {{ }} 내에서만 사용할 수 있습니다.

나는 이것이 아주 좋은 타협이 될 수 있다고 생각한다. 모든 사람을 만족시킬 수는 없지만 필터를 사용한 모든 것이 현재 필터가 그 이상을 할 수 있다는 사실이 이상합니다.

필터를 사용하고 양방향 필터를 효과적으로 제거하여 복잡성을 줄이려는 경우 편리한 텍스트 서식을 허용합니다.

제 생각에는 momentjs 필터 예제가 이미 템플릿에 너무 많은 논리를 전달하고 있습니다.

진지하게, 당신은 TC39에 도달할 때까지 이 모든 "파이프 러브"를 사양 저장소로 보내야 합니다. :)

@yyx990803 과 @VitaliyLavrenko 가 제안한 것을 좋아합니다. 그것은 좋은 중간 지점이 될 수 있습니다.

스콧

나는 @VitaliyLavrenko 제안을 좋아하지만 비슷한 것을 말할 때 플러그인 @azamat-sharapov에서 플러그인에 파이프 연산자를 사용하는 것에 대해 플러그인은 컴파일러를 엉망으로 만들어서는 안 된다고 말했습니다... 그래서 그것이 가능한지 아니면 내가 그냥 댓글을 잘못 이해했나요?

@thelinuxlich

무엇을 읽는 것이 좋을까요?

<div v-for="thing in things | filterBy 'foo' | orderBy 'bar' | limitBy 5">

또는

computed: {
  filteredThings () {
    return this.things
      .filter(item => item.title.indexOf('foo') > -1)
      .sort((a, b) => a.bar > b.bar ? 1 : -1)
      .slice(0, 5)
  }
}

개발자로서 생각하고 자바 스크립트를 모르는 사람에게 물어보십시오.

나에 관해서는 _개발자가 아닌_에게 다음과 같은 것이 더 좋습니다.

Vue.use(VueUtils)

computed:{
   ordersTable(){
         return this.utils.array(this.orders)
                        .filterBy(this.filter)
                        .sortBy('date', -1)
                        .limit(10)
   }
}

그것은 중간이고 vue-resource처럼 공통 라이브러리처럼 사용됩니다.

파이프에 대해서는 구문 설탕입니다.

물건 | filterBy 'foo' | orderBy '바' | 제한 5

~을위한

thing in limitBy(orderBy(filterBy(things, 'foo'), 'bar'), 5)

읽기 쉬움?

2개의 diff 템플릿에 데이터를 전달해야 하는 경우 하나의 데이터에 대해 2개 또는 3개의 수정 사항을 저장합니까?

다음과 같은 경우:

padLeft(capitalize(title), 10)


padRight(upper(title), 5)

나는 추상적 인 상황이지만 하나 또는 두 개의 템플릿에서 사용한다면? 10개 또는 100개 개체에 대한 데이터를 저장해야 합니까? 메모리 사용량을 늘리시겠습니까? 예, 도우미 메서드를 사용하여 템플릿에서 사용할 수 있지만 _"템플릿 디자이너를 위해"_ 자바스크립트에서 멀리 떨어져 있는 경우 title | padLeft 10 이고 함수 호출로 변환되어야 합니다. 쉽고 기능적입니다.

diff 사람들에 대해 생각해보십시오. 개발자는 diff 방식으로 쉽게 할 수 있지만 다른 사람들은 간단하게 하기를 원합니다.

다시 말하지만 템플릿에 너무 많은 논리가 있는 것은 반패턴입니다. 특정 DSL(필터)을 배우는 대신 Javascript를 배워야 합니다.

@thelinuxlich JSX 를 사용하면 양방향 바인딩 및 기타 몇 가지가 포함된 React를 얻을 수 있습니다.

그러나 Vue를 사용하면 javascript를 모르는 사람들이 있지만 Google을 사용하면 무언가를 할 수 있습니다. 파이프가 마음에 들지 않으면 사용하지 마십시오. 우리는 다음과 같은 것을 추가할 수 있습니다.

Vue.config.pipeFuncCall = true

그리고 당신은 그것을 켜거나 끌 수 있지만 어떤 사람들에게는 쉽습니다.

_다시 한 번 말씀드리지만 JS 개발자들은 Vue를 사용할 수 있을 뿐만 아니라 Vue의 강점이기도 합니다._

표준 공통 필터가 필요하지만 별도의 라이브러리에 있고 vue에 추가하고 사용하기 쉽습니다.

아니면 Vue가 ASM과 같으며 좋은 개발자만 사용할 수 있기를 원하십니까?

여러분, Vue 핵심팀이 내린 결정이 잘 설명된 것 같아요. 우리는 똑같은 것을 계속해서 반복하고 새롭고 가치 있는 것이 있다면 그것에 대해서만 논평할 수 없습니까?

JS가 아닌 개발자에게 더 쉬운 것이 Vue 핵심 원칙의 일부라면 언어 원칙에 상처를 주더라도 동의하겠지만 아마도 그렇지 않을 것입니다.

전에 말했듯이 필터가 더 이상 사용되지 않는 것이 대부분이지만 편의를 위해 필터가 그리울 것이지만 매우 유사한 필터 시스템이 플러그인으로 도입될 수 있다고 확신합니다.

나는 계산된 소품과 인라인에서 사용할 수 있는 개념 증명 예제 를 조금 더 일찍 제공했습니다.

<ul>
    <li v-for="item in f(items).filterBy(foo).orderBy(bar).limitBy(5).apply()">
        {{ item.foo }}
    </li>
</ul>

반면에 누군가 파이프를 원하면 다음과 같이 할 수 있다고 확신합니다.

<ul>
    <li v-for="item in p(items, 'filterBy foo | orderBy bar | limitBy 5')">
        {{ item.foo }}
    </li>
</ul>

또는 플러그인이 표현식을 구문 분석하고 원하는 대로 처리할 수 있는 후크가 있다면 그것도 가능한 방법일 수 있지만 이는 구현이 얼마나 복잡하고 어떤 영향을 미칠지에 달려 있습니다. 프레임워크(성능/크기)에서, 그리고 @yyx990803 이 실제로 이 방향으로 가고 싶은지 아닌지!

사용하기 쉬운(플러그인이나 핵심적인 것) 우아한 대안이 주어지면 상당히 빨리 익숙해질 것 같습니다.

@rigor789 배열 필터링 및 정렬 등을 위해 계산을 더 잘 사용하면 훨씬 깨끗합니다. 하지만 diff 형식으로 데이터를 표시하는 데 문제가 있다고 생각합니다.

created_at 필드가 있고 템플릿에서 필요한 경우 dd.mm.YYYY 또는 링크로 렌더링

<a href="dd">dd</a>.<a href="mm">mm</a>.<a href="YYYY">YYYY</a>

지금 잘 사용되는 이 필터에 대해 2.x에서 어떤 대안을 얻을 수 있습니까?

지금은 만 사용

 {{ date(created_at, 'dd') }}

그리고 date 메소드를 정의하지만 템플릿을 더럽게 만들고, 3개의 필드를 추가로 저장하면 메모리가 소모되고, 100-200개 개체이면 무거워집니다.

최종 결정은 다음과 같습니다.

1. 필터는 지원되지만 텍스트 보간 내부에서만 지원됩니다. 이것은 다른 로직을 JavaScript 랜드에 적용하면서 텍스트 형식화 목적으로 제한합니다.
2. Vue 2.0은 내장 필터 없이 배송됩니다. 커뮤니티는 필요한 경우 자체 필터 팩을 만들 수 있습니다.
3. 필터 구문은 공백으로 구분되는 대신 인수에 함수 호출 구문을 사용하도록 변경됩니다. 이를 통해 JavaScript 및 기타 인기 있는 템플릿 언어(Jinja2, swig, twig...)와 더 인라인됩니다.

html {{ date | formatDate('YY-MM-DD') }}

Evan을 들어주셔서 감사합니다. 그것이 Vue를 훌륭하게 만드는 이유입니다. 훌륭한 지도자가 있습니다. :웃다:

스콧

@yyx990803 & @chrisvfritz

이 토론에서 묻힌 것처럼 보이는 한 가지는 양방향 필터입니다. 양방향 필터는 제안된 다른 솔루션으로 복제하기 가장 어려운 필터입니다.

1. 해당 포럼 스레드에 게시한 이 간단한 예 를 고려하십시오. 이에 대해 계산된 속성을 사용하면 2가지 주요 단점이 있습니다.
   
   
   
   1. 각 값에 대해 새 계산 속성을 생성해야 하므로 엄청난 양의 상용구 코드가 생성됩니다.
   
   
   2. 설상가상으로 계산된 속성은 중첩 될 수 없습니다. 더 복잡한 개체 그래프가 있는 경우 계산된 모든 속성이 최상위 수준에 있어야 합니다. 어떤 계산된 속성이 어떤 중첩 값을 추적하는지 지속적으로 추적하기 위해 더 많은 인지 과부하가 필요한 길고 장황한 속성 이름으로 끝납니다.
   
   

이 사용 사례를 "사소한" 또는 "덜 복잡한" 것으로 무시하는 것은 역효과입니다. 저는 중대형 애플리케이션 모두에서 이것을 사용했습니다. 이상하게 작동했습니다! 데모는 반드시 간단하지만 기술은 확실합니다.

1. 이것은 이 예에서 와 같이 v-for 의 배열을 다룰 때 더 혼란스럽습니다(다시 말하지만 의도적으로 단순함). 배열을 반복하면 계산된 속성에 의지할 방법이 없습니다. 이 문제를 해결하는 유일한 방법은 배열의 각 항목에 대해 별도의 구성 요소를 갖고 더 많은 상용구를 추가하는 것입니다.

이 예를 필터와 비교하십시오.

``` js
'some-currency-filter'에서 통화 가져오기;
'product-stub'에서 제품을 가져옵니다.

새로운 뷰({
엘: document.body,
데이터: { 제품 },
필터: { 통화 },
});
```

필터가 없는 사람에게:

``` js
'some-currency-filter'에서 통화 가져오기;
'product-stub'에서 제품을 가져옵니다.

새로운 뷰({
엘: document.body,
데이터: { 제품 },
구성 요소: {
제품: {
소품: ['제품'],
계산: {
가격: {
가져 오기() {
통화를 반환합니다.read(this.product.price);
},
세트(값) {
this.product.price = 통화.쓰기(값)
}
},
배송: {
가져 오기() {
통화를 반환합니다.read(this.product.shipping);
},
세트(값) {
this.product.shipping = 통화.쓰기(값)
}
},
취급: {
가져 오기() {
통화를 반환합니다.read(this.product.handling);
},
세트(값) {
this.product.handling = 통화.쓰기(값)
}
},
할인: {
가져 오기() {
통화를 반환합니다.read(this.product.discount);
},
세트(값) {
this.product.discount = 통화.쓰기(값)
}
}
}
}
}
});
```

나는 위의 어떤 것을 쓰고 싶은지 압니다.

_{(이것은 계산된 속성 팩토리를 생성하여 약간 정리할 수 있지만 요점은 이것이 필요한 것보다 훨씬 더 장황하다는 점입니다)}

핵심 팀이 필터 파이프 구문에 확고하게 반대하는 것처럼 보이므로 v-model 지시문에 filter 매개변수를 도입할 수 있습니까?

filter 매개변수를 사용하면 위의 첫 번째 우아한 버전의 JS를 유지할 수 있고 매직 파이프 구문 대신 매개변수를 사용하도록 템플릿을 다시 작성할 수 있습니다.

<tr v-for="product in products">
  <td><input type="text" filter="currency" v-model="product.price"></td>
  <td><input type="text" filter="currency" v-model="product.shipping"></td>
  <td><input type="text" filter="currency" v-model="product.handling"></td>
  <td><input type="text" filter="currency" v-model="product.discount"></td>
</tr>

이것은 많은 상용구 없이 입력을 쉽게 앞뒤로 변환할 수 있는 기능을 유지하면서 마법의 구문을 사용하지 않는 적절한 균형을 유지합니다.

이해해 주셔서 감사합니다.

필터를 사용자 지정 지시문으로 통합하도록 예제를 다시 작성했습니다: jsfiddle .
필터만큼 간결하지는 않지만 내가 상상했던 것만큼 고통스럽지는 않습니다. 그리고 이미 우리 모두가 사용할 수 있는 것들에서 조각들을 모으는 데 많은 시간이 걸리지 않았습니다.

각 필터에 대한 전용 지시문을 생성하는 @Nirazul 은 이전에 제안되었습니다 . 앱에서 사용하는 각 유형의 필터에 대해 모든 v-model 기능을 다시 구현하는 새로운 지시문을 생성해야 하는 것은 터무니없는 일입니다.

또한 지시문은 필터처럼 완전히 작동하지도 않습니다. 값을 변경한 후 필드를 흐리게 해도 형식이 다시 지정되지 않습니다. 또한 v-model 는 해당 지시문에서 수행하는 것보다 훨씬 더 많은 작업을 수행합니다.

이 지침은 분명히 더 많은 기능과 수정 사항으로 수정될 수 있지만 요점은 남아 있습니다. 이것들은 기본적으로 매우 간단해야 하는 것 외에 모든 반창고입니다.

이 스레드에서 사용자 지정 지시문을 언급하는 제안을 본 적이 없습니다. 이 댓글을 지적해 주시겠습니까?

당신이 상상할 수 있듯이, 나는 당신이 당신의 앱에서 사용하기 위해 그것을 작성하고 테스트하지 않았습니다. 대안으로 지금 가능한 것이 무엇인지 보여주고 싶었습니다. 이것이 그렇게 쉽게 가능하다면 플러그인이 프로세스를 훨씬 더 자동화할 여지가 있을 수 있습니다.
이 빠르게 작성된 지시문에는 v-model의 전체 기능이 부족하다는 것이 분명합니다. 매개변수 및/또는 수정자와 결합된 하나의 사용자 정의 필터 지시문이 필터를 대체하기에 충분할 수 있습니다.

내가 당신의 문제를 해결하기 위해 시도한 것처럼 건설적인 상태를 유지합시다. 기여하고 앞으로 나아가는 것보다 솔루션을 강타하는 것이 항상 더 쉽습니다.

@JosephSilber 긴장 을

안녕하세요, 템플릿 혼란을 줄이기 위해 필터를 제거하고 있습니까 아니면 심각한 영향을 미치고 있습니까?
2.0의 기술 구현? 이전 시각 효과 문제라면 허용하는 것은 어떻습니까?
지금과 같은 필터 (그러나 새로운 자바 스크립트 양식으로)
그러나 v-for="i of list | orderBy('key')", (하나 이상의 파이프 기호)와 같이 표현식당 하나만으로 제한합니다.
이것은 2.0에서 필터 처리를 더 간단하고 예측 가능하며 시각적으로 덜 복잡하게 만들 수 있습니다.
{{}}에 대한 필터 구문 분석이 있으므로 다른 표현식에서 이를 허용하는 것이 좋습니다.
이것은 기존의 모든 사용 사례/기능(예: 양방향 필터링, v-for 내의 항목)을 수용합니다.
둘 이상의 필터에 대한 기존 사용은 소유자가 쉽게 병합/업그레이드할 수 있습니다.

@tomsmithgroup 귀하가 제안한 것(및 그 이상)은 2.0에서 계속 지원되기로 결정 되었습니다.

@yyx990803 & @chrisvfritz 는 양방향 필터 에 대한 귀하의 생각을 듣고 싶습니다.

@JosephSilber 따라서 언급한 계산된 속성 공장에는 상용구도 많지 않습니다.

import currenciesFactory from 'some-computed-currencies-factory'
import products from 'products-stub'

new Vue({
  el: 'body',
  data: { products },
  components: {
    product: {
      props: ['product'],
      computed: currenciesFactory(['price', 'shipping', 'handling', 'discount'])
    }
  }
})

개인적으로는 이 예제에 대한 팩토리를 만들지 않을 것입니다. 왜냐하면 이러한 각 속성은 실제로 현재만 동일하게 _나타나는_ 별개의 관심사이기 때문입니다. 필터를 제거하면 한 구성 요소가 얼마나 복잡한지 훨씬 더 명확해집니다. 그것이 당신이 보일러 플레이트로보고있는 것입니다.

그리고 이것이 구성 요소가 _존재하는_ 큰 이유입니다. 복잡성을 관리 가능한 문제로 나눕니다. 구성 요소를 볼 때 구성 요소가 수행하는 모든 작업은 내 작업 메모리에 쉽게 맞아야 합니다. 그렇지 않으면 개발 속도가 훨씬 느려지고 오류가 발생하기 쉽습니다. 필터 구문 뒤에 복잡성을 숨긴다고 해서 복잡성이 제거되는 것은 아닙니다.

이를 입증하기 위해 문제가 실제 변화하는 요구 사항을 충족할 때 어떤 일이 발생하는지 살펴보겠습니다. 할인이 가격 + 배송 + 취급보다 클 수 없도록 결정했다고 가정해 보겠습니다. 또는 취급은 X 금액을 초과해서는 안됩니다. 또는 할인 필드는 통화가 아닌 백분율이어야 합니다. 또는 총액이 일정 금액을 초과하는 경우 자동으로 최소 할인이 적용됩니다.

추가 옵션과 조건부 논리를 사용하여 필터를 더 복잡하게 만들고 싶을 수 있습니다. 필터의 API 및 내부 로직을 업데이트할 때 변경 사항이 필터를 사용하는 다른 모든 항목에 어떻게 영향을 미칠지 생각해야 합니다. 공유 필터인 경우 현재 구성 요소 외부에서도 가능합니다. 이제 앱을 변경하는 것이 어렵게 느껴지기 시작하는 상황에 처해 있습니다. 그리고 이는 모두 공유된 2개 필터를 통해 내부 구성 요소 상태를 구성 요소 외부에 위임할 수 있으므로 구성 요소 경계를 위반하고 결합이 증가하고 구성 요소에 대해 작업할 때마다 여전히 생각해야 하는 복잡성을 숨길 수 있기 때문입니다.

개별적으로 정의된 계산된 속성 또는 바인딩된 props를 사용하여 개별적으로 덜 복잡한 여러 구성 요소로 항목을 나누면 변화하는 요구 사항에 맞게 한 줄을 업데이트하는 경우가 많습니다. 추가 옵션이나 조건이 없습니다. 확장 복잡성을 충족하기 위한 리팩토링이 없습니다. 구성 요소 외부 또는 단일 속성 외부에 대해 생각할 필요가 없습니다. 귀하의 애플리케이션은 처음부터 있었고 여전히 쉽게 생각하고 업데이트할 수 있습니다.

이 경우 필터가 처음에 매혹적으로 만드는 이유는 복제에 대한 치료법이 쉽게 접근할 수 있다는 것입니다. 그러나 중복은 부수적일 때 상용구가 아닙니다(즉, 실제 문제가 필연적으로 시작되기 전에 코드가 바로 지금 발생합니다).

그리고 나는 그것을 Sandi Metz보다 더 잘 표현할 수 없습니다.

복제는 잘못된 추상화보다 훨씬 저렴합니다.

@chrisvfritz 필터는 비즈니스 요구 사항과 전혀 관련이 없습니다. 필터는 데이터의 형식만 지정합니다. 그게 다야 그들은 어떤 형태나 형태로든 그것을 조작하지 않습니다. filter="currency" 는 개념적으로 number 매개변수와 동일합니다. 비즈니스 요구 사항은 분명히 필터에서 처리되어서는 안 됩니다.

할인이 가격 + 배송 + 취급보다 클 수 없도록 결정했다고 가정해 보겠습니다. 또는 취급은 X 금액을 초과해서는 안됩니다.

그런 다음 vue-validator 와 같은 적절한 유효성 검사 모듈을 사용합니다. 통화 필터는 기본 값을 표시하기만 하면 관계없이 그대로 유지됩니다.

할인 필드는 통화가 아닌 백분율이어야 합니다.

그렇다면 분명히 그 유형은 더 이상 통화가 아닙니다. 사용자 이름 요구 사항이 변경될 때 type="text" 를 type="email" 바꾸는 것과 다르지 않습니다. 또는 필드가 더 이상 숫자가 아닐 때 number 매개변수를 제거하는 경우에도 마찬가지입니다.

총액이 일정 금액을 초과하면 자동으로 최소 할인이 적용됩니다.

다시 말하지만 최소값이 적용되지만 통화 필터는 그대로 유지됩니다. 여전히 통화로 표시하고 싶을 것입니다.

필터의 API와 내부 로직을 업데이트할 때, 이제 변경 사항이 필터를 사용하는 다른 항목에 어떤 영향을 미칠지 생각해야 합니다. [...] two-filter를 사용하면 내부 구성 요소 상태를 구성 요소 외부에 위임할 수 있습니다.

아니요. 필터 자체에 논리나 상태를 _절대_ 넣지 않습니다. 필터는 엄격하게 형식 값을 위한 멱등 함수입니다. 이상적으로는 VM 컨텍스트에서 실행되지 않아야 합니다 . 추가 데이터를 가져올 this 가 없어야 합니다.

복제는 잘못된 추상화보다 훨씬 저렴합니다.

...당신이 말했듯이, 당신은 바로 지금 같은 일이 발생하는 코드를 추상화하고 있습니다. 반면에 필터는 값의 형식을 지정하는 간단한 멱등 함수입니다. 그것들은 전혀 추상화가 아닙니다.

tl;dr 필터는 추상화가 아니며 명시적인 비즈니스 요구 사항을 대신하지 않습니다. 필터에는 내부 논리가 없으며 절대 없어야 합니다. 개념적으로 HTML의 type 속성 및 v-model 의 number 매개변수와 유사합니다.

양방향 필터는 확실히 추상화입니다. v-model 에 대한 양방향 필터의 현재 동작은 내부에 많은 마법을 숨깁니다. 특히 입력의 DOM 값이 기본 모델과 일시적으로 동기화되지 않고 다음과 같은 경우에만 "동기화"되도록 합니다. 필드를 흐리게 합니다. BTW @JosephSilber 이 동작은 특별히 귀하의 요청으로 인해 구현되었으므로 귀하가 이에 대해 그렇게 강하게 느끼는 이유를 이해할 수 있습니다.

그러나 양방향 필터에서 내가 본 가장 큰 문제는 기본 논리가 블랙박스이고 사용자가 기능 요청을 만드는 것 외에는 추가로 사용자 지정할 수 있는 방법이 없다는 것입니다. 나에게 더 나은 옵션은 그러한 행동을 직접 구현하기 위한 적절한 빌딩 블록을 제공하는 것입니다. 2.0에서 이것이 어떻게 가능한지 보여드리겠습니다.

https://jsfiddle.net/yyx990803/5bnu6xb6/

여기에 현재 양방향 필터의 "out-of-sync-until-blur" 동작을 구현하는 기본 CustomInput 구성 요소가 있습니다. 2.0의 변경 사항으로 인해 구성 요소가 value input 이벤트를 $emit하는 한 사용자 지정 구성 요소에서 v-model 를 직접 사용할 수 있습니다. 또한 현재 양방향 필터로는 불가능한 change 이벤트의 값 형식을 지정합니다 . 프레임워크에서 양방향 필터를 구현하는 방법에 얽매이지 않고 원하는 동작 을 얻기 위해 이 구성 요소를 추가로 조정할 수 있습니다.

기본 구성 요소는 구문 분석/포맷팅 로직을 구현하지 않습니다. parse 및 format 메서드로 확장하여 특정 사용 사례에 맞는 맞춤형 입력 구성 요소를 얻습니다. 이 경우 CurrencyInput 구성 요소입니다.

기본 구성 요소는 양방향 필터보다 더 복잡합니다. 이제 이전 매직 동작을 직접 구현하기 때문입니다. 그러나 이 구성 요소는 한 번만 정의하면 됩니다. 그 대가로 나중에 변경하려는 경우 작동 방식을 완전히 제어할 수 있습니다. 나는 이것이 가치 있는 절충안이라고 생각합니다.

이것은 가장 많은 제어를 제공하는 재사용성을 위한 통합된 추상화이기 때문에 컴포넌트에 대해 더 많이 생각해야 하는 방법의 예입니다. 또한 2.0 select2 예제를 참조하십시오. 이전에는 1.0에서 지시문으로 구현되었지만 이제는 동일한 v-model 인터페이스를 가진 구성 요소입니다.

나에게 더 나은 옵션은 그러한 행동을 직접 구현하기 위한 적절한 빌딩 블록을 제공하는 것입니다.

이것은 훌륭하고 가장 확실히 Vue가 필요로 하는 것입니다. 그러나 나는 이것을 읽고 싶었습니다.

나에게 더 나은 옵션은 Vue를 시작하고 새로운 필터링 동작으로 Vue를 확장하기 위한 적절한 빌딩 블록을 제공하는 것입니다.

즉, 통화 입력 구성 요소와 다른 여러 기본 필터링 구성 요소가 Vue의 일부가 될 수 없습니까? 누구나 한 번쯤은 화폐를 사용하기 때문이겠죠? 왜 똑같은 일을 계속해서 다른 사람들에게 맡길까요? 통화 형식은 Vue 자체 필터링 구성 요소 도구 모음의 일부로 만들기에 충분히 표준이며 다른 사람들이 자체 필터링 구성 요소를 만드는 방법을 배울 수 있는 훌륭한 기본 예제입니다.

그리고.....완성된 통화 입력 구성 요소가 되는 예제에서 누락된 단 한 가지는 i18n 기능입니다. Vue도 이를 수반해야 한다고 생각합니다. 통화 숫자 형식은 사람(시청자)이 선택한 로케일에 따라 변경되어야 합니다. 내 말은 로케일 데이터 즉 . "DE_de"를 사용하여 이 로케일 탐색기에 표시된 대로 통화 및 기타 숫자 형식을 지정합니다(표준에서 파생됨). Vue에 추가하면 Vue에 바로 내장된 훌륭한 통화/숫자 서식 구성 요소 시스템이 있습니다. Vue를 사용하는 1000명의 다른 개발자는 스스로 생성할 필요가 없고 Vue를 얻었을 때 그 자리에서 바로 사용할 수 있습니다. . 이것은 Vue를 강력한 템플릿 시스템으로 만듭니다!

이 "i18n 형식 구성 요소"를 사용하는 것이 1.0에서와 같이 필터로 연결 가능한 방식으로 사용될 수 없다면 플러그인 가능해야 합니다. 그것도 괜찮을거야. 그것이 Aurelia가 하고 있는 일 이며 Twig가 확장 기능으로 하는 일이기도 합니다 . 통화 입력 구성 요소는 여전히 <currency-input> 일 수 있습니다.

이 i18n 및 기타 표준 템플릿 필터는 다른 사람들이 계속해서 재생산할 필요가 없는 경우에만 실제로 필요합니다. 그런 플러그인 만드는 방법을 알려주시면 i18n 플러그인도 만들어 드리겠습니다. 나는 이것에 관심이 있습니다!:스마일:

스콧

누구나 한 번쯤은 화폐를 사용하기 때문이겠죠?

아니요. 저는 한 번도 실제로 사용한 적이 없습니다. 다른 모든 내장 필터에도 동일하게 적용됩니다. 일부는 우리에게 유용하지만 나머지는 쓸모가 없습니다. 이 주제에 대해 이야기하는 동안 대부분의 경우 내장 필터를 사용하고 싶었지만 결국 제 자신의 버전을 작성하여 내장 버전의 데드 코드를 렌더링했습니다.

Vue도 수반되어야 한다고 생각하는 i18n 기능입니다.

이것은 다시 매우 논쟁의 여지가 있습니다. 포괄적인 i18n 지원은 매우 복잡할 수 있으며 IMO는 Vue에 속하지 않습니다. 특히 대부분의 사용자가 필요하지 않을 때는 더욱 그렇습니다.

이제 이것을 제기하고 싶습니다. Vue와 다른 템플릿/프레임워크를 비교할 때마다 명심해야 할 중요한 사항이 하나 있습니다. Django/Laravel/Twig와 달리 Vue는 본질적으로 클라이언트 라이브러리이므로 최대한 가벼워야 합니다. 소위 "유용성" 또는 "우아함"을 위해 "기능" 및 "유틸리티"를 추가하는 대신 모든 _core_ 기능을 유지하면서 충분히 단순하게 유지하는 것이 더 합리적입니다. 핵심 기능 이외의 다른 것을 원한다면 플러그인을 사용하거나 직접 개발하는 것이 더 선호됩니다. 이것을 예로 들어 보겠습니다. 일반적으로 볼 수 있는 SPA의 경우 i18n/currency가 라우터나 상태 관리자보다 더 중요합니까? 나는 그렇게 생각하지 않는다. 그러나 vue-router와 vuex는 Vue에 속하지 않고 자체 저장소가 있습니다. 즉, Vue는 점진적 입니다.

그런 플러그인 만드는 방법을 알려주시면 i18n 플러그인도 만들어 드리겠습니다. 나는 이것에 관심이 있습니다!

더 합리적인 접근이라 생각하고 많은 관심 부탁드립니다 :)

일부 영역에서 i18n을 사용해야 하는 경우)) 아름다움을 위해 코드에 들어가서 수동으로 몇 가지 이름을 변경할 수 있다고 생각합니다.
예를 들어: 불과 몇 시간 전에 butstrap.datepikker가 필요했습니다. - 그런 가능성이 있음에도 불구하고 i18n에 연결하지 않습니다. 빠른 60초. "수동으로"는 요일과 월의 이름을 모두 대체했습니다. ))

@phanan - 귀하의 주장이 "플러그인"을 언급한 이유입니다. 모든 사람이 통화 또는 i18n 기능을 원하지 않고 앱을 가볍게 유지할 수 없는 기능을 원할 것이라는 점에 동의합니다. 그러나 템플릿 시스템으로서 (이는 지극히 제 개인적인 의견입니다) Vue도 이러한 표준 기능을 사용할 수 있어야 합니다. 도. 더 중요한 것은 모든 사람이 i18n 또는 통화 필터 구성 요소 휠을 재발명해야 하는 것은 아니라는 점입니다. 즉, Vue-Router 및 Vuex가 Vue에 추가로 사용 가능한 것처럼 통화 및 i18n과 같은 많은 표준 필터도 추가될 수 있습니다.

아, 그리고 흥미롭게도 Angular에는 i18n이 내장되어 있는 것 같습니다.

https://docs.angularjs.org/guide/i18n

Angular는 날짜, 숫자 및 통화 필터에 대해 i18n/l10n을 지원합니다.

Ember와 React는 "개발자가 알아서 하도록 내버려두는" 방식을 택한 것 같습니다.
흥미로운 비디오.
https://www.youtube.com/watch?v=Sla-DkvmIHY

Vue는 FormatJS와의 통합만 필요할까요? 뷰 국제? :웃다:

편집: 그렇게 간단할 수 없습니다. https://github.com/learningequality/vue-intl/blob/master/index.js

스콧

Angular에는 i18n이 내장되어 있는 것 같습니다.

Angular는 또한 ng-router와 함께 제공되며, 내가 들은 바에 따르면 ng-community는 ui-router를 선호하여 기피합니다.

이제 Angular 팀이 ng-router를 ui-router로 교체하면 브레이킹 체인지와 고통이 따릅니다.

ng-router를 개선하려고 하면 더 나은 솔루션(ui-router)이 이미 존재하기 때문에 시간을 낭비하고 있습니다.

Vue가 코어에서 i18n, 통화 등을 지원하기 시작했다면 동일한 상황이 vue에도 발생할 것입니다.

내장 필터가 편리하다고 생각하지만 이 문제에 대해서는 vuejs 팀에 동의합니다..

그런 다음 우리는 Vue 코어에 없는 필터에 모두 동의합니다. 나는 또한 실제로 구성 요소화의 팬입니다. 그런데 Vue는 필터도 코어 플러그인으로 제공할 수 없나요? Vuex 및 Vue-Router처럼?

스콧

그런데 Vue는 필터도 코어 플러그인으로 제공할 수 없나요? Vuex 및 Vue-Router처럼?

이것이 바로 @blake-newman이 이전에 공유 한 내용입니다.

안녕하세요: 최종 결정 페이지에서 텍스트에 대한 필터만 허용하는 것으로 표시됨
{{}} 표시(v-텍스트)
v-for="item of list | sortBy"와 같은 다른 표현식에는 적용되지 않습니다.
아니면 제가 잘못 이해한 건가요?
내 말은 1.0에서와 같이 필터를 계속 사용하지만 하나의 필터만 제한한다는 것입니다.
표현 당

2016년 5월 1일 일요일 오후 10시 24분에 Phan An [email protected] 이 다음과 같이 썼습니다.

@tomsmithgroup https://github.com/tomsmithgroup 제안하신 내용
(그리고 그 이상)이 결정되었습니다
https://github.com/vuejs/vue/issues/2756#issuecomment -215868244
2.0에서 계속 지원됩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/vuejs/vue/issues/2756#issuecomment -216093937

@yyx990803 답변 에서 양방향 필터가 2.0에서 지원되지 않을 것이라고 결론을 어도 될까요?

@fnlctrl 맞습니다. 자신의 구성 요소를 구축하기만 하면 됩니다.

주제에서 조금 벗어나겠습니다. 이 양방향 필터가 실제로 프로덕션에서 그렇게 유용한가요?
내 말은, 사용자가 입력에 아무 것도 입력하지 않고 흐리게 처리한 후 다시 포맷하도록 하는 것이 정말 괜찮습니까?
우리 비즈니스 팀은 항상 다음 과 같이 행동하도록 입력을 요구합니다. 아무 것도 잘못 입력하면 안 됩니다. 그래서 지금도 Vue 를 사용하여 즉각적인 양방향 변경이 더 이상 사용되지 않기 때문에 해당 목적으로 jquery.inputmask를 사용합니다.
제 말은, 그 양방향 필터에 문제가 있습니까? 아니면 사람들이 그것을 지나치게 생각하는 것입니까? :)

@fullfs 양방향 필터는 편의를 위해 프로덕션 앱(많은 <input> s)에서 광범위하게 사용되지만 지금 보니 값이 표시되기 전에 한 번만 필터링하는 대신 실시간으로 값을 필터링하는 이유는 서버에 POST를 보내셨나요? 코드를 리팩토링하는 데 시간이 좀 걸리겠지만 놓치지 않을 것 같아요 :D

UI의 낙관적 업데이트 (오늘날 IMHO, 특히 모바일의 표준임)를 원하면 입력이 제공된 시점에 실제로 적절하게 형식이 지정된 입력을 원할 것입니다.

스콧

2way 필터는 vue에서 정말 좋습니다. 필터를 사용하거나 사용하지 않고 언제든지 사용자 지정 구성 요소를 만들 수 있지만 시간이 걸립니다. 라이브러리는 유연성을 제공해야 하지만 작업을 수행하는 더 빠르고 편리한 방법도 제공해야 합니다. 양방향 필터를 포함하면 사람들이 필요한 경우 자체 구성 요소를 구축하는 것을 막을 수 없지만 기존 기능이 대부분의 경우 요구 사항에 맞을 때 더 빠른 개발을 허용합니다. 항상 API 표면과 편의성 사이의 절충안입니다. 균형을 찾아야 하고 Vue에는 이미 훌륭한 균형이 있었습니다. 필터를 제거하는 것은 균형의 올바른 지점에서 한 발짝 뒤로 물러난 것처럼 보입니다. 라이브러리는 작아지지만 이를 사용하는 모든 프로젝트의 코드베이스와 상용구는 커집니다.

필터가 실제로 더 이상 사용되지 않는 경우 쉬운 방법으로 v-model 지시문에 대한 파서 및 포맷터를 지정할 수 있는 대안을 제공하는 것이 좋습니다. 필터를 사용하면 제공된 @yyx990803 예제 의 이 부분만 작성할 수 있습니다.

const CurrencyInput = CustomInput.extend({
  methods: {
    parse(val) {
      var number = +val.replace(/[^\d.]/g, '')
      return isNaN(number) ? 0 : number
    },
    format(val) {
      return '$' + Number(val).toFixed(2)
    }
  }
})

양방향 필터가 없으면 작성해야 합니다.

const CustomInput = Vue.extend({
  template: `
    <input type="text"
      @focus="onFocus"
      @blur="onBlur"
      @input="onInput"
      @change="setDisplayValue">
  `,
  props: ['value'],
  watch: {
    value() {
      if (!this.focused) {
        this.setDisplayValue()
      }
    }
  },
  ready() {
    this.setDisplayValue()
  },
  methods: {
    onInput() {
      this.$emit('input', {
        target: {
          value: this.parse(this.$el.value)
        }
      })
    },
    onFocus() {
      this.focused = true
    },
    onBlur() {
      this.focused = false
      this.setDisplayValue()
    },
    setDisplayValue() {
      this.$el.value = this.format(this.value)
    }
  }
})

따라서 유연성이 향상되지만 동일한 결과에 대해 더 많은 코드가 필요합니다.

@aristidesfl - 필터가 더 이상 사용되지 않습니다. 우리는 부분적으로 전투에서 승리했습니다. ㅋ ㅋ ㅋ! 텍스트 보간에만 사용하도록 제한될 것입니다. 여기를 참조하십시오: https://github.com/vuejs/vue/issues/2873

스콧

@smolinari 감사

다시 오세요! 우리는 그것을 필요로 합니다. 나는 당신이 말한 모든 것에 동의합니다. 하지만 너무 쉽습니다. 우리는 게으른 사용자입니다. 우리는 게으르고 쉬운 방법을 원할 뿐입니다. 유지처럼.

사용자 정의 v-model 수정자를 추가하는 방법이 있을 수 있습니다(http://rc.vuejs.org/guide/forms.html#Modifiers).

양방향 필터처럼 작동합니다.

@ecmel이 동의했습니다. 이것이 갈 길입니다.

그런 다음 기능 요청 문제를 엽니다. :)

@ecmel 비슷한 아이디어가 유형 수정자로 설명되었지만 여기 에서 논의

@rpkilby 해당 토론도 종료되었습니다. 맞춤형 v-model 수정자를 위한 새 토론을 열어야 할 수도 있습니다.

더 이상 할 수 없음:

<span :title="item.Modified | date('dd-mmmm-yyyy H:MM:ss')">{{item.Modified | date('dd-mmmm-yyyy')}}</span>

필터를 {{ }} 로 제한하는 것이 이상해 보입니다. 속성 바인딩에서 필터를 사용하고 싶은 경우가 많습니다(prop를 전달하지 않음). 이제 더 이상 속성에서 {{ }} 를 사용할 수 없습니다. !

@LinusBorg 오픈 https://github.com/vuejs/vue/issues/3666

필터를 {{ }} 제한하는 것이 이상하게 보입니다. 속성 바인딩에서 필터를 사용하고 싶은 경우가 많으며(prop를 전달하지 않음) 더 이상 속성에서 {{ }} 를 사용할 수 없습니다. !

그것들은 계산된 속성과 메서드로 쉽게 대체될 수 있기 때문에 제거되었지만 더 제한된 API를 가지고 있기 때문에 결과를 캐싱할 가능성이 없습니다.

그래서:

• API 하나 감소
• 템플릿과 JS 코드에서 동일한 방법을 사용하면 앱 코드에서 사용하기 위해 필터 동작을 복제할 필요가 없습니다.
• 계산된 소품을 캐시할 수 있습니다.
• JS이기 때문에 더 많은 유연성

앞으로 의사 코드:

<!-- method, suitable in v-if  -->
<span :title=" date(item.Modified, 'dd-mmmm-yyyy H:MM:ss')>

<!-- computed prop, more suitable for single values -->
<span :title="formattedModified">
<script>
computed: {
  formattedModified () { return date(this.item.Modified, 'dd-mmmm-yyyy H:MM:ss') }
}
</script>

죄송합니다. 저는 "신규"일 뿐입니다.
그러나 필터가 없는 Angular 1에서 오는 것은 정말 이상하고 직관적이지 않습니다. 모든 개발자가 자체 필터 세트를 개발하고 계산된 항목 등을 자체적으로 설정하는 것이 빌드하는 것보다 더 나은 이유는 무엇입니까?
이제 요소의 개체별로 정말 큰 배열을 필터링하는 가장 좋은 방법으로 간주됩니다. Angular의 경우 이것은 한 줄의 코드에 불과했습니다. 검색 입력을 위해 배열을 필터링하는 것이 가능했으며 프레임워크의 기능이어야 하는 모든 마법을 수행할 것입니다.

이제 정말 큰 배열을 필터링하는 모범 사례로 간주되는 것은

정말 큰 배열이란 무엇입니까? 이론적으로 계산된 속성은 필터링에도 유용합니다.

https://jsfiddle.net/sat25z51/3/

모든 개발자가 자신의 필터 세트를 개발하고 계산된 항목 자체를 설정하는 것보다 빌드하는 것보다 더 나은 이유는 무엇입니까?

나도 같은 방식으로 생각하곤 했지만(그리고 왜 스레드를 시작했는지), 기본적으로 이러한 종류의 필터를 스스로 만드는 것은 식은 죽 먹기이며 각 개발자가 원하는 것이 너무 많다는 것을 알게 되었기 때문에 필터(또는 계산된 속성)로서, 필터를 내장하지 않는 것이 그렇게 큰 문제가 아니라는 것을 깨달았습니다.

스콧

제 경우에는 Firebase 데이터베이스에서 제공하는 json의 >10.000줄과 같습니다.
나는 당신이 그렇게 생각하는 이유를 알고 기능을 삭제하기로 결정했지만 그럼에도 불구하고 개발자에게는 상당히 번거로운 일입니다.

바이올린이 내 데이터 구조와 인라인되도록 포크했습니다.
https://jsfiddle.net/nw5yhLwv/
그래서 내 개체의 검색 문자열을 손으로 코딩해야 합니까?

나는 당신의 질문을 이해하지 못합니다. 죄송합니다. 바이올린은 내가 게시 한 것과 같습니다.

스콧

계산 대 필터

필터는 (메소드처럼) 모든 렌더에 대해 계산되고 계산된 속성은 케이크처럼 쉽고 필요할 때만 다시 계산되기 때문에 성능에 좋지 않을 수 있습니다. 그렇지 않으면 결과가 캐시되어 Vue가 날아갈 수 있습니다.

오. 그리고 우리는 둘 다 가지고 있습니다. 😄

스콧

이봐, 나는 약간의 만지작 거리고 이제 이해가 간다. 그것은 훌륭한 개념이다! 😄

이에 대한 논의가 오랫동안 끝났기 때문에 지금 이 스레드를 잠글 것입니다. Vue 2.0이 출시된 지 몇 달이 지났고 필터 저하에 대한 비판이 크게 가라앉았습니다.

이 스레드에서 더 이상의 논의는 생산적이지 않습니다. 토론이 필요하다고 생각되는 주제에 대한 새로운 관점이 보이면 새 문제를 열어주세요.