Vue: واجهة برمجة تطبيقات محسّنة لمكونات واجهة المستخدم ، مما يقلل من الصيغة المعيارية لإعادة توجيه السمات والأحداث

حسنًا ، لا أعرف شيئًا عن ذلك ، لكن بالنسبة لمكونات مثل تلك ، أعتقد أنه يمكنك استخدام JSX أو createElement لنشر الدعائم.

https://github.com/doximity/vue-genome

بالنسبة لنا سيكون هذا رائعًا. نحن نلف جميع المدخلات في ملصق لأغراض التصميم و ux. أوافق على أنه يمكننا الانتقال إلى jsx بدلاً من ذلك ، لكن القوالب يسهل على الجميع متابعتها.

Austio ، لسوء الحظ ، هذا هو العائد للقوالب ... انتظر ... ربما يمكننا التفكير في طريقة لجعل الدعائم spread في قوالب vue؟

أنا أحب هذه الميزة شخصيًا. ولكن يبدو أنه يكسر تناسق سلوك v-bind ، مثل أحيانًا ما زلت بحاجة إلى ربط الخاصية class لعنصر الجذر.

حسنًا ، ماذا عن استخدام زوج من التوجيهات مثل getter و setter مثل:

داخل المكون ، حدد v-expose anchor:

<input v-expose="foo" />

عند استخدامه:

<the-component v-define:foo="{propA: '', propB: ''}"></the-component>

<!-- or maybe use v-bind for it directly -->
<the-component :foo="{propA: '', propB: ''}"></the-component>

jkzing ، هذا يبدو رائعًا ، ولكن مرة أخرى ، يبدو أنه انتشار أساسي ومع وجود مشاكل محتملة مثل كيف يمكنك تحديد @keyup.enter.prevent="myAction" ؟

لا يمكنك فقط <the-component :foo="{'@keyup.enter.prevent': myAction}"></the-component> ، وهذا يعني أنه يجب عليك الاحتفاظ بجميع المعدلات مثل enter و prevent في وقت التشغيل (وهو جزء من vue-template-compiler ماكينة الصراف الآلي)

تضمين التغريدة

التي تبدو وكأنها فارق أساسي

الشيء الذي نتحدث عنه هو تقديم شيء مثل الانتشار لمستخدمي القالب

<the-component :foo="{'@keyup.enter.prevent': myAction}"></the-component>

@ هو v-on shortland ، ولا يعني prop (v-on).

jkzing ، في الرابط من الوصف ، هناك الكثير من الارتباطات v-on أيضًا

nickmessing Um ... أما بالنسبة v-on ، فهو موضوع آخر IMO ، مثل حدث فقاعة. 🤔

jkzing ، كان هذا هو المفهوم الكامل لـ v-expose afaik ، لجعل جميع الخصائص "تذهب" إلى عنصر معين في المكون

nickmessing ، لا يمكنني التأكد من الاقتراح الأصلي ، لكن لا أعتقد أنه يجب اعتبار مستمع الحدث على أنه attribute .

jkzing ، ربما لا ، ولكن بالنظر إلى المثال الشائع لـ <my-awesome-text-input /> حيث يمكنك الحصول على أكثر من 9000 من الدعائم المختلفة ، فأنت تريد فقط أن يصلوا جميعًا إلى yout <input /> الموجود داخل المكون المخصص الخاص بك بدون طن من التعليمات البرمجية.

أنا شخصياً أستخدم v-bind="$props" أو يمكنك تصفية هؤلاء لاستبعاد الدعائم التي لا تريد تطبيقها. بهذه الطريقة يمكنك تطبيق دعائم متعددة في وقت واحد على الإدخال. في الواقع ، قد يكون v-expose مفيدًا لأنه بالنسبة لمكونات الغلاف مثل المدخلات ، يجب عليك تحديد جميع عناصر HTML هذه

إذا هذا
https://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vue#L9
يمكن تقليل قيمة cane إلى v-bind="$props" أو v-bind="filteredProps" حيث قد تكون filteredProps بعض الخصائص المحسوبة

cristijora نحن نستخدم v-bind="someProps" أيضًا. تكمن مشكلة هذا الحل في إضافة الخصائص الزائدة كسمات HTML. سيكون من الرائع أن يتمكن v-bind= تصفية جميع الخصائص التي لا يقبلها المكون. باستخدام الديناميكي <component> لا نعرف أي الدعائم يجب تصفيتها في الخاصية المحسوبة. على الرغم من أنه من الممكن استخراج options.props واستخدام lodash._pick .

هل هذا ممكن حقا مع التوجيه؟

posva ، لا أعتقد أن هذا سيعمل

posva ليس

chrisvfritz هل لديك أي أفكار حول واجهة برمجة التطبيقات حول كيفية استخدامها (تحديد ما يجب الكشف عنه وكيفية إضافته إلى الطفل)

أستطيع أن أرى هذا مشابهًا في الاستخدام لتوفير / حقن المفهوم.

Austio ربما لا أفهم السؤال ، لكني أقدم بعض الأفكار حول API في

مرحبًا كريس ، قصدت أفكارًا إضافية حول استخدام مماثل لتوفير الحقن حيث تعلن عن ما يمكن كشفه في الوالد ثم استخدام ذلك في الطفل.

آه لقد فهمت. لست متأكدًا من وجود حاجة لذلك. يمكن بالفعل تمرير المعلومات عبر الدعائم والفتحات - وحتى الخصائص الخاصة للوالد يمكن الوصول إليها باستخدام this.$parent ، على الرغم من أنني أعتقد أنه من الأفضل تجنب هذا النمط.

Austio هل هناك حالة استخدام معينة تفكر فيها؟

chrisvfritz كيف سيعمل ذلك في وظائف العرض؟

أعتقد أنه ربما يكون من الأفضل:

• يوفر خيارًا لتعطيل التوريث التلقائي لسمات عقدة الجذر
• فضح هذه السمات كـ $attributes ، على سبيل المثال (تسمية tbd)
• استخدم v-bind لإضافتها أينما تريد ، تمامًا كما أظهرنا فعلاً مع $props :

v-bind="$attributes"

سيكون لذلك فائدة إضافية تتمثل في العمل بشكل متطابق عمليًا في وظائف JSX / العرض

LinusBorg تعجبني طريقة تفكيرك. 😄 طريقك أكثر سهولة.

كإجراء جانبي ، أعتقد أنه مع وجود واجهة برمجة التطبيقات هذه ، يمكن للإصدار الرئيسي التالي من Vue أن يزيل التوريث التلقائي للسمات تمامًا ، بحيث يظل الاتصال عبر المكونات واضحًا على كلا الجانبين.

سيكون من الممكن تقليل أو إزالة هذا السلوك ، نعم.

إذا كان ذلك يستحق التغييرات المطلوبة المحتملة على العديد من المكونات في libs وما إلى ذلك ، فسيتم تحديده ويجب مناقشته مع المجتمع ، وخاصة مؤلفي مجموعة واجهة المستخدم.

ج حول الميزة المطروحة: هذه المعلومات متاحة بالفعل في المكونات الوظيفية عبر context.data.attributes ، لذلك ستوفر هذه الميزة بشكل أساسي الوظائف المماثلة لمكونات المثيل.

نعم بالضبط. الغرض الرئيسي الذي يدور في بالي هو جعل العمل أبسط لمؤلفي مكونات واجهة المستخدم (كلا من الجهات الخارجية والداخلية). يوجد حاليًا الكثير من الحالات التي يكون فيها شيء من هذا القبيل ضروريًا:

<input
  v-bind:id="id"
  v-bind:accept="accept"
  v-bind:alt="alt"
  v-bind:autocomplete="autocomplete"
  v-bind:autofocus="autofocus"
  v-bind:checked="checked"
  v-bind:dirname="dirname"
  v-bind:disabled="disabled"
  v-bind:form="form"
  v-bind:formaction="formaction"
  v-bind:formenctype="formenctype"
  v-bind:formmethod="formmethod"
  v-bind:formnovalidate="formnovalidate"
  v-bind:formtarget="formtarget"
  v-bind:list="list"
  v-bind:max="max"
  v-bind:maxlength="maxlength"
  v-bind:min="min"
  v-bind:multiple="multiple"
  v-bind:name="name"
  v-bind:pattern="pattern"
  v-bind:placeholder="placeholder"
  v-bind:readonly="readonly"
  v-bind:required="required"
  v-bind:src="src"
  v-bind:step="step"
  v-bind:type="type"
  v-bind:value="value"
  v-on:keydown="emitKeyDown"
  v-on:keypress="emitKeyPress"
  v-on:keyup="emitKeyUp"
  v-on:mouseenter="emitMouseEnter"
  v-on:mouseover="emitMouseOver"
  v-on:mousemove="emitMouseMove"
  v-on:mousedown="emitMouseDown"
  v-on:mouseup="emitMouseUp"
  v-on:click="emitClick"
  v-on:dblclick="emitDoubleClick"
  v-on:wheel="emitWheel"
  v-on:mouseleave="emitMouseLeave"
  v-on:mouseout="emitMouseOut"
  v-on:pointerlockchange="emitPointerLockChange"
  v-on:pointerlockerror="emitPointerLockError"
  v-on:blur="emitBlur"
  v-on:change="emitChange($event.target.value)"
  v-on:contextmenu="emitContextMenu"
  v-on:focus="emitFocus"
  v-on:input="emitInput($event.target.value)"
  v-on:invalid="emitInvalid"
  v-on:reset="emitReset"
  v-on:search="emitSearch"
  v-on:select="emitSelect"
  v-on:submit="emitSubmit"
>

خاصية $attributes يمكن أن تختصرها إلى هذا:

<input
  v-bind="$attributes"
  v-on:keydown="emitKeyDown"
  v-on:keypress="emitKeyPress"
  v-on:keyup="emitKeyUp"
  v-on:mouseenter="emitMouseEnter"
  v-on:mouseover="emitMouseOver"
  v-on:mousemove="emitMouseMove"
  v-on:mousedown="emitMouseDown"
  v-on:mouseup="emitMouseUp"
  v-on:click="emitClick"
  v-on:dblclick="emitDoubleClick"
  v-on:wheel="emitWheel"
  v-on:mouseleave="emitMouseLeave"
  v-on:mouseout="emitMouseOut"
  v-on:pointerlockchange="emitPointerLockChange"
  v-on:pointerlockerror="emitPointerLockError"
  v-on:blur="emitBlur"
  v-on:change="emitChange($event.target.value)"
  v-on:contextmenu="emitContextMenu"
  v-on:focus="emitFocus"
  v-on:input="emitInput($event.target.value)"
  v-on:invalid="emitInvalid"
  v-on:reset="emitReset"
  v-on:search="emitSearch"
  v-on:select="emitSelect"
  v-on:submit="emitSubmit"
>

على الرغم من أنني أفترض أنه لا يزال من الجيد أن يكون لديك طريقة ما لفضح الأحداث أيضًا. ربما يمكن للتوجيه الفارغ v-on توجيه جميع مستمعي الأحداث على الأصل إلى هذا العنصر؟

<input
  v-bind="$attributes"
  v-on
>

أو إذا انتهى الأمر بكوننا مخاوف متعددة نريد تجميعها ، فقد نعود إلى شيء مثل v-expose :

<input v-expose>

لقد تحول هذا إلى مناقشة أوسع حول كيفية تبسيط بناء مكونات واجهة المستخدم ، بدلاً من طلب ميزة معينة ، لذلك سأعيد تسمية هذه المشكلة. 🙂

لقد تأخرت عن هذا الموضوع ، لكن لدي بعض الأفكار أيضًا.

v-bind الحل الحالي وعيوبه

أولاً ، أنا بالفعل أستخدم وأحب ميزة v-bind="propObject" (قوية جدًا). على سبيل المثال ، يحتوي bootstrap-vue على مكون ارتباط داخلي يتم استخدامه في كل مكان (الأزرار والتنقلات والقوائم المنسدلة وما إلى ذلك). تصبح محاور المكون نقطة ارتساء أصلية مقابل ارتباط جهاز توجيه قائم على href مقابل to ووجود vm.$router ، لذلك هناك الكثير من الخصائص لتمريرها بشروط لكل منها من هذه المكونات.

كان حلنا هو وضع هذه العناصر في مزيج واستخدام v-bind="linkProps" مع كائن محسوب. يعمل هذا بشكل رائع ، ولكن لا يزال هناك الكثير من النفقات الإضافية لإضافة هذا المزيج إلى جميع المكونات الأخرى باستخدام مكون الارتباط.

v-expose الاحتمالات باستخدام v-bind

أنا شخصياً أحب مفهوم v-expose ، وربما يمكن أن يعمل مثل الفتحة الافتراضية + الفتحات المسماة ، ثم استخدام المعدلات للوصول إلى فتحات السمات المسماة.

السمة الافتراضية _ "الفتحة" _ تمرر السمات دائمًا إلى المكون نفسه (بدون تغيير) ، بينما يمكن تحديد الأهداف المسماة الأخرى بواسطة المكون. ربما شيء من هذا القبيل:

<template>
  <my-component 
    <!-- Nothing new here -->
    v-bind="rootProps"
    <!-- This binds the `linkProps` object to the named attribute slot `link` -->
    v-bind.link="linkProps"
  />
</template>

داخل MyComponent.vue :

<template>
  <div>
    <router-link v-expose="link" />
  </div>
</template>

وكيل الحدث

ليس لدي الكثير لأضيفه هنا ، باستثناء أن .native معدل قوي بشكل مذهل. حل الكثير من المشاكل بالنسبة لي. يبدو أن Vue devs غير معروف إلى حد كبير (أرى قدرًا جيدًا من مشكلات واجهة المستخدم lib التي يتم حلها من خلال تعريض المطورين لهذه الميزة). لقد وضعت علاقات عامة على موقع الويب لإضافة المزيد من المستندات ودعم البحث في الموقع ومن المحتمل أن تكون محسّنة لبحث google.

قادمًا من مناقشة حول سطح واجهة برمجة التطبيقات في قضية أخرى ، يجب أن أكرر أنني لست من المعجبين بفكرة v-expose . إنه يقدم "طريقة عمل الأشياء" ، ولا يعمل مع JSX دون تنفيذ شيء خاص هناك أيضًا ، وما إلى ذلك.

أحد الأشياء التي أحترمها في React People هو التزامهم بواجهة برمجة تطبيقات نحيفة واستخدام ميزات اللغة قدر الإمكان. بهذه الروح ، فإن إعادة استخدام نمط لدينا بالفعل للدعائم للسمات يبدو أفضل بكثير من تقديم تجريد آخر.

<my-input
  type="file"
  mode="dropdown"
>

<template>
  <div>
    <input v-bind="$attributes">
    <dropdown v-bind="{ ...$props, $attributes.type }"/>
  </div>
</template

آه ، أرى ما تقوله الآن. وأنا أحبه! هل هذا متاح حاليا؟ vm.$attributes هو الإضافة بدلاً من ذلك؟

إعادة قراءة تعليقاتك. أنا أتعقب الآن 👍

نعم ، سيكون $attributes هو الإضافة.

أيضًا ، سنحتاج إلى خيار لتغيير السلوك الافتراضي الحالي لتطبيق السمات على عنصر الجذر ، مثل هذا:
"" html

يمكن أن يصبح هذا بعد ذلك إعدادًا افتراضيًا في Vue 3.0 إذا قررنا القيام بذلك مما أدى إلى تغيير فاصل.

LinusBorg ما هي أفكارك حول التعامل مع الأحداث الجانبية للأشياء؟ لاتباع نفس الإستراتيجية ، افترض أنه يمكننا أيضًا إضافة خاصية $listeners ، والتي قد تبدو كالتالي:

{
  input: function () { /* ... */ },
  focus: function () { /* ... */ },
  // ...
}

ثم ربما يقبل v-on كائنًا مشابهًا لـ v-bind . لذلك سيكون لدينا:

<input v-bind="$attributes" v-on="$listeners">

إحدى المشكلات التي أتوقعها تتعلق بأحداث input / change ، نظرًا لأن v-model يعمل بشكل مختلف قليلاً للمكونات عن العناصر. لا أعرف أيضًا ما إذا كنا نريد كلاً من $listeners و $nativeListeners . أفترض أنه إذا كان $listeners متاحًا ، فقد يكون المُعدِّل .native قديمًا.

أيضًا ، فيما يتعلق بخيار applyComponentAttrsToRoot ، ربما يكون exposeRootEl اسمًا جيدًا ، والذي عند تعيينه على false ، يمكنه تعطيل كل من السمات المطبقة تلقائيًا وحدث .native الشحن؟

قد يكون من الجيد أيضًا أن تكون قادرًا على تعطيل هذا للتطبيق بأكمله عبر Vue.config ، وكذلك لمكون واحد.

كانت لدي فكرة مماثلة مؤخرًا حول $listeners - إنها متوفرة أيضًا على المكونات الوظيفية عبر

context.data.listeners

لذلك سينتهي بنا الأمر بـ $props و $attributes و $listeners الأمر الذي يبدو جيدًا بالنسبة لي.

هناك أيضًا # 5578 يطلب بناء جملة كائن v-on="{...}" كما استخدمته لـ $attributes ، سيكون مناسبًا تمامًا.

لكنني غير متأكد من المعدل الأصلي. لجعل هذا العمل مع كل من الأحداث المكونة والمستمعين الأصليين ، سينتهي الأمر بواجهة برمجة التطبيقات (API) أكثر تعقيدًا ، ويكون الاستخدام مشكوكًا فيه ، نظرًا لأن مستمع الحدث الأصلي المطبق على عنصر الجذر سيستمر في التقاط الحدث المرغوب فيه ، لذلك قد لا يكون تكون ضرورية لتخصيصها لعنصر معين في القالب.

بشكل عام ، أود أن أقول بالنسبة إلى libs ذات المستوى المنخفض ، يجب تفضيل وظائف العرض عندما تصبح القوالب غير ملائمة للعمل معها. لكنني أوافق على أن ما يلي سيكون ذا قيمة:

1. تعطيل السلوك الافتراضي لـ "الربط التلقائي للتطبيق غير الموجود في الخاصيات كسمات لعنصر الجذر" (مشكلة ذات صلة: هل يجب أن يؤثر ذلك على الارتباطات class و style أيضًا؟)

2. كشف طريقة أسهل لـ "وراثة" الارتباطات الخارجية للمكون على عنصر داخلي ليس بالضرورة الجذر. بشكل مثالي مع الاتساق بين القوالب ووظائف العرض.

ia kie مثل vue ، أدوات بسيطة

فقط أريد أن أقول أن العلاقات العامة لهذا في الإصدار 2.4 ممتاز! 👍

من مذكرة الإصدارات

الجمع بين هذه يسمح لنا بتبسيط مكون مثل هذا وصولا إلى هذا:

<div>
  <input v-bind="$attrs" v-on="$listeners">
</div>

يبدو لطيفًا ولكن هذا ليس صحيحًا تمامًا ، نظرًا لأن هذا النوع من المكونات مصمم للعمل مع طراز v وبقدر ما أعرف أن نموذج v على مكون التغليف لا يعمل بشكل جيد. هل هناك أي مثال على كيفية إعادة توجيه نموذج v من مكون التفاف إلى إدخال على سبيل المثال؟
أبسط طريقة وجدتها:
https://jsfiddle.net/60xdxh0h/2/

ربما مع وجود مكون وظيفي يعمل على طول القالب ، سيكون الأمر أكثر وضوحًا

تم تصميم هذا النوع من المكونات للعمل مع نموذج v وبقدر ما أعرف أن نموذج v على مكون التغليف لا يعمل خارج الصندوق.

لماذا تعتقد هذا؟ نموذج v هو عبارة عن سكر لغوي لدعامة ومستمع حدث ، وكلاهما سيكون في الدعائم $ attr / $ وبالتالي يمكن نقلهما بسهولة.

أفترض أن الشيء الوحيد الذي يتطلب معرفة خيارات الطفل سيكون إذا قام الطفل بتغيير الإعدادات الافتراضية model ، هذا صحيح.

لكن سيكون من الممكن قراءتها ، حسب الظروف.

من المؤكد أنه سكر نحوي ، لكنني أعني أنه قد يكون محيرًا في القراءة

الجمع بين هذه يسمح لنا بتبسيط مكون مثل هذا وصولا إلى هذا:

عندما تستند فعليًا إلى المثال https://github.com/almino/semantic-ui-vue2/blob/master/src/elements/Input.vue ، لا يمكنك تمرير المستمعين مباشرةً لتحقيق نفس التحكم. (على سبيل المثال: يجب عليك استخدام v-on: input = "emitInput ($ event.target.value)")

على أي حال ، هذه العلاقات العامة قيمة ، عمل جيد!

AlexandreBonaventure هذا لأن v-model يعمل بشكل مختلف قليلاً على المكونات عما يعمل على العناصر. توفر أحداث DOM كائن حدث لعمليات الاسترجاعات ، بينما توفر أحداث المكون قيمة مباشرة. والنتيجة هي أن v-model _does_ يعمل ، لكن القيمة المرتبطة هي كائن حدث DOM. 😕

أعتقد أنك محق في أنه سيكون من المرغوب فيه أن تعمل هنا v-model ، لكنني لست متأكدًا من أفضل مكان لحلها. بعض الافكار:

ربما يمكن إضافة خاصية غير قابلة للعد إلى $listeners (على سبيل المثال ، __$listeners__: true ، لمساعدة v-on اكتشاف استخدامات v-on="$listeners" . ثم في الحالات التي يكون فيها $listeners يتم تمرير الكائن v-on ، يمكن تغليف كل مستمع:

function (event) {
  listener(event.target.value)
}

أحد الجوانب السلبية الآن هو أننا نتخلص من البيانات. إذا أراد شخص ما الوصول إلى keyCode ، على سبيل المثال ، فلن يحالفه الحظ. ومع ذلك ، إذا تم دعم المُعدِّلات لبناء جملة كائن v-on ، فيمكننا إصلاح ذلك بجعل .native يعطل سلوك الالتفاف التلقائي.

@ yyx990803LinusBorg ما هي أفكارك حول جدوى؟ أي حالات حافة أنا في عداد المفقودين؟

أوه ، أرى أنك تشير إلى نموذج v على rral. عناصر النموذج ، كنت أفكر في ذلك على المكونات.

لا يمكنك / لا ينبغي عليك استخدام ذلك على الدعائم على أي حال ، مع أو بدون هذه العلاقات العامة. وفي التطبيقات المتقدمة ، من غير المألوف استخدامه (على الرغم من إمكانية تحقيقه).

LinusBorg أريد فقط التأكد من أننا على نفس الصفحة. إعطاء مكون CustomInput مع هذا القالب:

<div>
  <input v-bind="$attrs" v-on="$listeners">
<div>

ألا تتوقع أن يعمل الرمز أدناه؟

<CustomInput v-model="myValue" />

أتوقع أن يعمل - ولكن بالطريقة التي فهمت بها ألكسندر ، كان يشير إلى نموذج v على العنصر ، وليس المكون - والذي يعمل في النهاية فقط مع الحالة المحلية المتغيرة.

كنت أحاول أن أقول ما شرحه chrisvfritz في رسالته الأخيرة. (عذراً اللغة الإنجليزية ليست لغتي الأم :))

LinusBorg المشكلة في القيام بذلك في الإصدار الأخير هي أنه لا يزال يعتبر مضادًا للنمط ويطلق تحذيرًا بشأن تغيير الحالة.

من المفيد للغاية أن يكون لديك ما سبق يعمل حيث تكون خاصية value غير سلسلة. خذ على سبيل المثال مكون التحرير والسرد حيث أحاول استخدام التعدادات المستوردة من مكتبتي الخاصة كقيم لخيارات التحديد:

<template>
    <select class="combo" v-model="value" v-on="$listeners"> 
      <option v-for="(item, key) in items" :value="item">{{key}}</option>
    </select>
</template>

<script>
export default {
    props: {
        items: {
            type: Object,
            required: true
        },

        value: {}
    }
}
</script>

هذا مثال على إحدى القوائم التي أستخدمها للعناصر في الأصل:

            execList: {
                "None": ACT_EXEC_TYPES.NONE,
                "Function": ACT_EXEC_TYPES.FUNCTION,
                "Code": ACT_EXEC_TYPES.CODE
            }

وكيف أستخدم مكون التحرير والسرد:

<combo :items="execList" v-model="selectedAction.execType"/>

لقد كنت أحاول أن أجعل هذا يعمل لمدة يومين الآن وما زلت أشعر بالإحباط حقًا. تكمن المشكلة في أن $ event.target.value دائمًا عبارة عن سلسلة ولا يتم تقييمها كما يجب أن تكون في :value .

LinusBorgAlexandreBonaventureRobertBColton أنا فقط فتحت قضية حيث يمكننا التركيز مناقشة مستقبل هذه المشكلة.