vue 3についてデフォルトでは、すべてのonSomethingをv-onイベントとして結びつける考えです。


最近Vue 3のrfcsを見なおしています。詳細は次の通りです。
props that start with on are handed as v-on bindings、with everthing after on being converted to all-lowercase as the event name(more on this below)
つまり、今後プロを伝える時に、onで始まるプロpsがコンポーネント上でプロpsの声明をしないと、イベントとしてコンポーネントのルートノードに結び付けられます。
その原因を追求して、私は大体2点を要約しました。
  • は、vue 2のv-on.native
  • に対応しています。
  • vue 3のvnode声明はpropsを撮影しました。イベントと他のpropsを区別するために、全てのon開通のpropsをデフォルトにしてイベントとして結びつけられました。
    このために、私はこの問題を議論するためにissueを開設しました。issueアドレス。私の関心は主に2つあります。
  • functional componentに対する厳しい制限
  • です。
  • は困惑する誤解を招くかどうか
  • まず第一を言います
    vue 3では、関数コンポーネントを直接function(){}で宣言することができます。これは非常に便利さを向上させます。以前にコンポーネントを宣言したいですが、必要です。
    
    {
      functinal: true,
      props: {},
      render() {}
    }
    
    
    この最大のアップグレードはpropsを声明する必要がないからです。なぜこれがアップグレードされたのかというと、HOCを開発するのが便利になりました。私たちは今、HOCの関心のないプロpsを、レスで直接下に伝えられます。
    しかし、このデフォルトの制限のため、私たちはHOCで可能性のあるすべての彼の拡張コンポーネントをonで開始するpropsを宣言しなければならない。例えば、次のようなコンポーネントがあります。
    
    {
      props: {
        name: String,
        onChange: Function
      }
    }
    
    
    私達のHOCの機能はnameの前にprefixを加えるので、このHOCに対して私達が関心を持つのはnameと彼の自分のprops:prefixだけです。だから彼の声明は次のようにすべきです。
    
    {
      props: {
        name: String,
        prefix: String
      }
    }
    
    
    そしてレンダーの中で彼はこうすることができます。
    
    {
      render() {
        const {name, prefix, ...rest} = props
        return <WrapperedComponent name={`${prefix}-${name}`} {...rest} />
      }
    }
    
    
    つまりHOCにとっては、彼の拡張したコンポーネントの他のpropsに関心を持つ必要はないのですが、この場合、HOCで声明しないと、使用時に入ってきたオンChangeはpropsとして渡されるのではなく、rootノードに自動的に結合されます。
    第二点:困惑した使い方
    たとえば、コンポーネントがあれば、
    
    {
      props: {
        onChange: Function
      },
      methods: {
        handleInput() {
          // do someting
          //         `onChange`
        } 
      },
      render() {
        return <input onInput={this.handleInput} />
      }
    }
    
    
    明らかに私はinputの変化をカプセル化したいので、ある条件を満たす時やっと外に出して新しいvalue。しかし、もしこの時に文書を見ないで直接にオンインプを伝えている人がいるなら、この時inputイベントは直接ノードに結び付けられます。これもトリガとなります。
    もし私たちのテストの用例が少なすぎたり、詳しくなかったりしたら、彼らの違いに反応できないかもしれません。これは明らかにコンポーネント開発者としての私たちが望んでいないことですが、このような行為を制限することはできません。
    締め括りをつける
    この二つの問題を考えている時は、ある程度のReact思考が中にあると言わざるを得ません。個人的には、ReactのAPIデザインが好きです。非常に簡潔で、コンポーネントの使用も極めて近いです。すべてのコンポーネントです。
    vueはreactについてきていますが、これを信じても否定しません。vue 3に更新されたhooks API、Suspenseなどは明らかに参考にされているReactの概念です。
    しかし、同時に私はvue 3をよく見ています。vue 2のようなAPIデザインやvueファイルの開発パターンは、中高年のユーザーを引きつけるために用意されています。高級APIの特性を捨てるほどです。
    vue 3のヤフオクAPIとJSXに対するより良いサポート、そしてより純粋なfunctional componentによって、工程におけるvueの急進的な変化を見たことがあります。
    しかし、v-onのデフォルトは、ユーザーのために明確に決定する行動です。実際にこの問題を解決するのは簡単で、v-onを全く考慮しなくてもいいです。すべての伝達パラメータをpropsとして、もしコンポーネント開発者がルートノードでイベントをバインディングするなら、彼が実現できる時にバインディングするべきです。コンポーネントを使用するシーンで、コンポーネント内部のノードで何かを行うべきではないです。このようにする副作用は本当に大きいです。
    今から見れば尤先生が私の意見を聞く可能性はとても小さいですが、やはり簡単な期待を持っています。
    ここで、vue 3についてのデフォルトでは、すべてのonSomethingをv-onイベントとして結びつけるという考えについての文章を紹介します。vue 3 onSomethingをv-onイベントのバインディングとして使っています。以前の記事を検索したり、下記の関連記事を見たりしてください。これからもよろしくお願いします。