Vue: 2.0 Изменения

Я только что увидел, что некоторые функции будут доступны только в автономной сборке. Означает ли это, что эта версия и версия NPM существенно отличаются?

Средство автономной сборки

Спасибо, @ yyx990803. У меня еще есть пара вопросов по компилятору и другим функциям, но я использовал для этого форум .

Есть ли какие-либо тревожные изменения в документах, которые я должен случайно просмотреть? Отличная работа! Так держать, чувак. Вы меняете определение веб-разработки. Спасибо!

Могу ли я получить this.arg моей директивы?

Я вижу, что vnode.data.directives имеет arg , но когда у меня есть две или более директив, я не могу знать index .

<!-- show @ 0, img @ 1-->
<img v-show="true" v-img:200*200="imgSrc">

<!-- img @ 0, show @ 1-->
<img v-img:200*200="imgSrc" v-show="true">

Стоит ли использовать forEach ? Спасибо!

@banricho хороший момент, это было упущено! См. Обновленную сигнатуру функции директивы.

Прежде всего, извините за то, что я не совсем уверен, что могу задать эту проблему здесь, и у меня есть некоторые требования, которые я хочу сказать.
Требование состоит в том, что я надеюсь, что смогу спроектировать использование моего компонента следующим образом

<carousel>
  <img src="..." alt="..." desc="..." is="argument">
  <img src="..." alt="..." desc="..." is="argument">
</carousel>

Надеюсь, дети могут быть в качестве каких-то аргументов, а не только ограничивать в атрибутах
А пока я могу сделать компонент, использование вроде

<carousel items="[{}, {}, {}]"></carousel>

Но я думаю, что это не совсем хорошо, надеюсь, ему понравится тот, который я сделал раньше в React coverflow

@andyyou - этот вопрос, вероятно, лучше всего разместить на форуме, поскольку он не является проблемой, не является четким предложением или какой-либо реальной помощью в этом вопросе.

http://forum.vuejs.org/

Если вы обнаружите, что ваши требования не могут быть выполнены с помощью Vue в своей ветке форума, вы можете открыть здесь новую проблему.

Скотт

@smolinari Спасибо

«Но для более сложных случаев рекомендуется ввести специальный уровень управления состоянием с использованием Vuex». Похоже, это подразумевает, что состояние следует использовать над событиями. Я вижу их совершенно отдельными: событие - это момент времени, а состояние не меняется. Вы могли бы сказать, что можете наблюдать за состоянием, но это также не передает конкретный момент, а вместо этого всегда что-то меняется. Меня интересует смысл этой рекомендации.

@jrenton В общем, мы можем рассматривать систему событий просто как компонент A, говорящий компоненту B об изменении его состояния, или как A, говорящий B сделать что-то еще.
Итак, в первом случае мы можем использовать управление состоянием (управление общим состоянием для A и B) вместо использования системы событий, чтобы позволить A сказать B об изменении состояния.
Что касается второго случая, я думаю, что с этим можно справиться с помощью подхода «шины событий».

@jrenton вместо

Я использую Twig вместе с Vue.

До сих пор (vue 1.0) я передавал данные в свои компоненты следующим образом:

<my-component data="{{ DATA }}"><my-component>

(Обратите внимание, что {{ и }} - теги веточки - для vue я использовал настраиваемые разделители ${ и } )

Если я правильно понимаю, в Vue 2.0 я должен делать это так:

<my-component :data=" '{{ DATA }}' "></my-component>
правильно?

@gholol нет, это просто

<my-component :data="{{ DATA }}"></my-component>

На самом деле кажется, что ваше старое использование вообще не должно работать.

Хорошо, что все заработало ...

Как я уже сказал, данные поступают из движка шаблонов twig. Сейчас в Vue 2.0 это не работает. Я пытался передать это, как вы сказали (без единого апострофа), но свойство данных становится неопределенным.

Ошибка: SyntaxError: missing} после списка свойств

РЕДАКТИРОВАТЬ: это работает, я забыл упомянуть, что переменная DATA - это строка

@jrenton Моя идея и мотивация довольно просты, кажется, Vue не любит React, который заставляет нас использовать JSX. Мы можем выбрать много template .

Я надеюсь, что смогу использовать синтаксис дочерних элементов в качестве параметра (аргументов) для передачи аргументов родительскому элементу, потому что в некоторых языках шаблонов, таких как slim если у вас немного много атрибутов или если имя attr довольно длинное, тогда мы должны поставить все в одной строке. проще сделать код из одной строки длиной более 80 символов.

@ yyx990803 Чувствуя себя авантюристом сегодня, захотелось посмотреть, сколько усилий потребуется для перехода с 1.0 на 2.0a, к сожалению, поскольку уже невозможно использовать простую интерполяцию, как бы мне сделать что-то простое, например <input type="text" name="account[categories][{{ category.id }}]"> в 2.0?

Встроенные шаблоны ES6 работают в выражениях привязки:

<input type="text" :name="`account[categories][${ category.id }]`">

https://jsfiddle.net/Linusborg/cm4v75xh/

Если это единственный способ заставить это работать в 2.0, то не возражайте, если я скажу, что это регресс в прекрасном синтаксисе 1.0, к которому мы привыкли - да, я знаю, что это просто ES2015.

Я полагаю, интерполяция была удалена из соображений производительности? Я просто надеюсь, что это стоит более уродливого синтаксиса.

@oskarkrawczyk Я предполагаю, что вы хотите получить что-то вроде name="account[categories][fruits]" в вашей DOM, потому что это то, что будет отображать ваше выражение.

Версия 2.0 (и собственно 1.0) будет иметь вид :name=" 'account[categories][' + category.id + ']' " .

@simplesmiler Понятно. Думаю, {{ }} просто меня немного испортил.

@ yyx990803 могу ли я динамически вставлять такой компонент?

    render () {
        return this.$createElement('div', { staticClass: 'list-container' }, this.list)
    },
    data () {
         return {
               list: []
         }
    },
    method: {
         a () {
               this.list.push(this.$createElement('myComponent', {}))    
         }
    }

Как я могу связать несколько значений для атрибута, которые зависят от выражения? Например:

new Vue({
  el:'body',
  data:{
    flag: true
  }
})

<input type="text" v-bind:placeholder="{test: flag, test2: !flag}" />

Ожидаю следующий результат:

<input type="text" placeholder="test" />
<!-- or -->
<input type="text" placeholder="test2" />

@nervgh, это не то место, чтобы задавать этот вопрос.
Используйте троичное выражение, v-bind:placeholder="flag ? 'test' : 'test2'" .

@simplesmiler , спасибо за ответ. Я пытаюсь сказать, что _Object-Syntax_ будет полезен в этих случаях, но он работает не так, как я ожидал.

Синтаксис объекта class , и для компонентов не будет возможности определить со стороны дочернего элемента, хотите ли вы отправить список строк или правильный объект.

Re: .once и .sync устарели.

Разве это не нарушает общие шаблоны проектирования?

Я не могу представить, как вы могли бы иметь простые компоненты для обработки полей формы без них.

У меня есть простые компоненты для разных типов полей формы, например, вот мой шаблон компонента "текстовое поле":

<label>{{type.caption}}:<input type="text" v-model="data"></label>

... а также более сложный компонент для списков, который предоставляет пользовательский интерфейс для добавления и удаления элементов из массивов в структуре данных

Затем я использую эти компоненты, например, так:

<div v-for="field in type.fields">
    <component :data.sync="data[field.name]" :is="field.ctype" :type="field">

Примечание. Все эти компоненты имеют два свойства: data и type . data - это узел в редактируемой структуре данных, за который компонент отвечает за предоставление пользовательского интерфейса для редактирования, а type - это узел в (массивной, статической) структуре данных, который содержит типы / Иерархия полей.

Как такое может работать без .sync ?

Мне кажется, что создание какой-то системы обмена сообщениями между этими компонентами, где подкомпоненты могут каким-то образом сообщать родителю, какой подкомпонент они являются, сильно усложнит задачу, а затем родитель может выяснить, какая часть его данных структура, которую нужно изменить.

Я действительно надеюсь, что мне что-то не хватает ... потому что похоже, вы говорите, что использование компонентов для создания редакторов для частей вашей структуры данных - это анти-шаблон. Что? Пока это единственное, для чего я использовал Vue. Полагаю, вы думаете, что удаление этой функции побудит людей писать более чистый код. Может быть, это так повлияет на некоторых людей, но многие люди напишут гораздо более мерзкий код, чтобы обойти это ограничение. Изменение состояния - единственная полезная вещь, которую делают компьютеры. Пожалуйста, продолжайте делать это проще.

@JasonWoof v-model в версии 2.0 может работать с пользовательскими компонентами. Компоненту просто необходимо:

1. выставить опору с именем value
2. генерировать событие input когда значение необходимо синхронизировать с родительским, например this.$emit('input', value)

См. Пример .

@ yyx990803 Спасибо за объяснение и ссылку. Теперь я просто застрял на:

Зачем удалять .sync ?

Не вижу плюсов, только минусы. Пример, который вы связали, показывает, что вы можете добиться того же с помощью :selected.sync или v-model . Я вижу только недостатки метода v-модели:

1. Он требует значительного количества шаблонов на стороне подкомпонентов, он более сложен, требует большего изучения и т. Д.
2. Вы можете передать только одно значение с помощью v-модели, но у вас может быть несколько реквизитов .sync

Я не понимаю, как переход на v-модель делает что-то более ясным / чистым. В обоих случаях единственное указание в родительском компоненте на то, что дочерний компонент может легко изменять родительское состояние, - это синтаксис опоры в шаблоне. Я бы даже сказал, что .sync более понятен.

Другое дело, что когда вы передаете объекты / массивы / и т. Д. В качестве свойств, они изменяются из дочернего компонента. Таким образом, вы не можете защитить программистов от возможности изменять состояние дочерних компонентов в этом случае (что, как я полагаю, очень распространено). Мне кажется, что вы вводите камень преткновения, удаляя то, что делает его таким. передача строковых значений работает так же, как передача значений объектов. .sync делает мой код более простым и последовательным, всегда имея возможность записи моих "данных" с дочерней стороны, независимо от типа данных.

Я новичок в Vue.js (3 дня назад), но из того, что я вижу до сих пор, Vue.js ценен в основном по двум причинам:

1. простое манипулирование домом с помощью шаблонов
2. автоматическое распространение изменения значений / данных, включая запуск изменений шаблона

По крайней мере, это то, что я обнаружил до сих пор.

Мне кажется, что удаление .sync мешает заставить Vue.js последовательно выполнять второе.

@JasonWoof, потому что явные и неявные побочные эффекты за пределами собственной области действия компонентов имеют

... и хотя можно утверждать, что людям просто следует научиться, когда не использовать .sync , наш опыт пока другой. люди склонны слишком полагаться на это и создавать код, который впоследствии вряд ли удастся отладить.

так что это дизайнерское решение, которое заставляет людей делать это с самого начала.

пример:

• Мы синхронизируем значение name между родителем и потомком. все хорошо.
• мы решаем _ 'эй, когда это значение изменится, нам нужно что-то сделать в родительском элементе!' _
• Итак, мы создаем функцию watch . Хороший!
• Позже мы понимаем, что наблюдатель стреляет, когда мы этого не хотим. Но мы не можем точно сказать почему, потому что мы не можем никуда поместить console.log() чтобы отследить поведение.
• После долгих размышлений мы понимаем, что на самом деле мы действительно хотим, чтобы это происходило только при изменении значения в родительском элементе, а не в дочернем или «дедушке или бабушке».
• Теперь мы пытаемся найти способ как-то разграничить эти сценарии в функции watch .
• Только чтобы понять, что это делает простую вещь очень сложной.
• и, в конце концов, кто-то говорит нам удалить синхронизацию, поэтому мы отбрасываем все это и используем одностороннюю опору и генерируемое событие для обработки ситуации - код становится проще и яснее, поэтому легко рассуждать о том, как и когда данные текут, и их становится легче отлаживать. Ошибка обнаруживается быстро, и мы можем двигаться дальше.

... и это становится еще более безумным, когда вы синхронизируете более одного уровня.

Это (анти) шаблон, который мы видели снова и снова на форумах и в чате gitter.

Удаление .sync заставляет людей писать ясный, понятный, поддерживаемый код с самого начала, потому что их код не будет оставаться достаточно простым для .sync течение очень долгого времени, большую часть времени.

В ПОРЯДКЕ. Спасибо за объяснение.

Приятно слышать, какую проблему вы пытаетесь решить.

Я серьезно сомневаюсь, что это поможет ... Сделайте так, чтобы люди не могли легко нарушить шаблоны, которые вам нравятся, и люди будут делать гораздо худшие вещи, чтобы обойти ограничения.

Это во многом напоминает мне абстракцию. Абстракции доставляют нам столько неприятностей. Они затрудняют чтение кода, отладку и т. Д. Но вы не можете исправить это, лишив возможности создавать абстракции ... это в значительной степени то, что делает программирование возможным / полезным. Решение этой проблемы не на уровне языка или структуры, а в обучении, совете, обучении. Мы призываем людей не делать вещи излишне абстрактными.

Мне кажется, вы говорите о такой философии дизайна. Во многих случаях это отличная философия, о которой следует помнить при кодировании. Но когда это наложено как ограничение, и программист думает, что это ограничение мешает ему делать то, что ему нужно, тогда он будет работать над этим, что приведет ко всем проблемам, которых вы пытались избежать, и даже хуже.

Люди не перестанут пытаться мутировать родительское состояние из потомков. Вы не можете заставить людей этого не делать.

Ваша вещь v-model достаточно сложна, чтобы я мог обойти эту проблему, передав родительский объект / массив и ключ, чтобы дочерний элемент мог его изменить.

Я полагаю, что этот последний хит лежит в основе того, что я пытаюсь донести: я (лично) вижу отсутствие .sync как проблему и буду работать над этим или не буду использовать ваш фреймворк. Готов поспорить, что у многих будет такой же подход.

Возможно, это само собой разумеется, но меня немного злит, когда люди пытаются навязать мне философию дизайна. Я бы предпочел создавать вещи, которые идут ужасно неправильно, и научиться не делать этого снова, чем использовать системы, которые намеренно удерживают энергию из опасения, что я могу ее использовать неправильно.

PS Извините, ничего не могу с собой поделать, еще один комментарий, а потом оставлю вас в покое. Большинство программистов пишут код, который они не могут отлаживать. Это происходит с каждым программистом на каждом языке и в каждой структуре. Вот как программисты становятся лучшими программистами: они делают ошибки, создают код, который не могут исправить, они учатся писать по-другому в будущем. Пожалуйста, не принижайте свой фреймворк для всех, пытаясь сделать так, чтобы программисты, отвлекающиеся в угол, могли сделать свой материал немного более запутанным / сложным, прежде чем он станет таким беспорядком, что они не смогут его отлаживать.

@JasonWoof это не имеет ничего общего с "тупой", и предотвращение пользователей от распространенных ошибок / обеспечение лучшей ремонтопригодности по определению является частью работы фреймворка. Мы приняли решение, основываясь на собственном опыте проектирования, использовании самого фреймворка и наблюдении за поведением пользователей в различных сценариях использования. Если это антипаттерн, мы отговорим пользователей от его использования и предоставим рекомендации по идиоматическому решению. Вы можете не согласиться с этим, основываясь на своем личном мнении, но я считаю ваши аргументы неубедительными.

Люди не перестанут пытаться мутировать родительское состояние из потомков. Вы не можете заставить людей этого не делать.

Конечно. И мы не будем их «заставлять», потому что могут быть некоторые крайние случаи, когда это все еще может быть необходимо. Таким образом , вы можете получить доступ к this.$parent , вы можете передать $data через опору и т.д., но , откровенно говоря , сделать это будет не намного больше Convient , что $emit ING событие большинство из время, поэтому они не будут такими привлекательными, как .sync сахар.

Кроме того, $parent et.al. не являются частью официального руководства, поэтому пользователи, которые их используют, активно работают над предлагаемыми передовыми методами - что они могут делать бесплатно, но мы не поощряем такое поведение.

Следовательно, фреймворк не должен поощрять подобное поведение, предоставляя «волшебный» синтаксический сахар, такой как .sync если мы чувствуем, что такая функция неправильно используется в большинстве сценариев и противоречит лучшим практикам, которые фреймворк стремится установить.

Есть ли у Youda китайская версия? .

Как выглядит совместимость vue-router?

@ roblav96

Для обеспечения совместимости необходимо внести некоторые изменения, мы надеемся лучше интегрировать маршрутизатор в Vue.

@ Blake-Newman

Можем ли мы собрать шаблонный шаблон на vue-cli? Я не могу заставить это работать 😢

@ roblav96

В настоящее время есть некоторые изменения, необходимые для vue-loader, чтобы сделать его совместимым. В настоящее время 2.0 следует использовать только для экспериментов, пока не будут обновлены все дальнейшие зависимости для крупномасштабных приложений.

Есть ли расчетное время прибытия для бета-версий / релизов-кандидатов?

Альфа- версия @Evertt должна выйти на этой неделе. Бета-версия будет сопровождаться завершенной документацией и, возможно, дополнительной поддержкой со стороны основных расширяющих библиотек (Vue-router и т. Д.). Релиз-кандидат, когда бета-версия окажется успешной.

@ blake-newman спасибо за этот быстрый, лаконичный и полный ответ. Это лучшие. :-D

Есть ли способ обхода replace: false в vue 2.0?

Привет, JSX уже можно использовать?

@reohjs - Нет, и я бы лично увидел в этом реальный шаг назад для Vue, если бы он поддерживал JSX.

Скотт

@reohjs Вчера вечером в

Я рада что это не в ядре

👍 👍 👍 👍

Ага должен быть плагин. Однако, как видно, шаблоны имеют много преимуществ для стандартных компонентов.

Компиляция JSX должна быть легко осуществима с помощью этого плагина: https://babeljs.io/docs/plugins/transform-react-jsx/

Я думаю, что функция _h будет заменой React.createElement

Как насчет предоставления интерфейса для создания пользовательских модификаторов v-модели в качестве способа замены двухсторонних фильтров? Похоже, они уже используются для синтаксического анализа пользовательского ввода (например, v-model.trim ). Если синтаксический анализ / форматирование является простым и независимым от определенного свойства данных, использование модификатора позволит повторно использовать синтаксический анализ / форматирование с гораздо меньшим количеством шаблонов, чем путем установки вычисляемого свойства для каждого отдельного свойства данных или создания нового компонента для каждого тип ввода, к которому мы хотим применить синтаксический анализ / форматирование.

Привет, в настоящее время я работаю над плагином для поддержки gettext в Vue.js 1.0 и у меня есть директива, использующая vm.$interpolate .

Мне интересно, как перенести мой код на 2.0 поскольку:

• vm.$interpolate больше не поддерживается
• директивы больше не будут иметь экземпляров в 2.0

Или есть лучший подход, чем директива?

import languages from 'src/plugins/translate/languages'
import translateUtils from 'src/plugins/translate/utils'

const translateDirective = {
  terminal: true,
  params: ['translateN', 'translatePlural'],
  paramWatchers: {
    translateN: function () {
      this.translate()
    },
  },
  isPlural: function () {
    return 'translateN' in this.params && 'translatePlural' in this.params
  },
  bind: function () {
    this.boundTranslate = this.translate.bind(this)
    this.msgid = this.el.innerHTML.trim()
    this.translate()
    languages.eventEmitter.on(languages.languageChangedEventName, this.boundTranslate)
  },
  unbind: function () {
    languages.eventEmitter.removeListener(languages.languageChangedEventName, this.boundTranslate)
  },
  translate: function () {
    let n = this.isPlural() ? parseInt(this.params.translateN) : 1
    let translation = translateUtils.getTranslation(this.msgid, n)
    this.el.innerHTML = this.vm.$interpolate(translation)
  },
}

export default translateDirective

Просто скажу несколько коротких слов, так как я новичок в Vue , просто чтобы сказать, что я рад видеть сокращение API в целом или вспомогательных помощников. JavaScript уже является действительно мощным средством, и с помощью вычисляемых свойств и других реактивных функций фреймворка можно достичь почти всего.

Престижность этой _следующей_ версии! 🎆

@kemar Я не очень знаком с gettext, но я бы просто расширил Vue.prototype с помощью метода $ translate, а затем сделал бы

{{ $translate('some.Key.path') }}

Была ли удалена возможность регистрировать активы с синтаксисом массива в версии 2.0? Не работаю над альфой, просто интересно, намеренно это или нет.
то есть:

components: [compA, compB, compC]

Я знаю, что в ES6 есть сокращение, которое выглядит похожим, но есть несколько сценариев, в которых синтаксис массива был полезен.

Я вижу, вы упоминаете rendering to native interfaces on mobile с weex и мне было интересно, насколько легко было бы заставить Vue и

Что-то более похожее на Nativescript для Vue - это либо Weex, о котором вы упомянули, либо Quasar .

Скотт

Если больше нет dispatch или broadcast как общий дочерний компонент будет информировать своего родителя о событии / изменении? Это не похоже на шаблон глобальной шины или vuex. Пример использования, который мы сейчас используем, - это ползунок диапазона для поисковых фильтров. Компонент ползунка диапазона является общим и является дочерним по отношению к нескольким различным фильтрам поиска. В настоящее время мы используем dispatch когда ползунок диапазона закончил движение, тогда родитель знает, что запускает поиск на основе изменения.

Встроенные слушатели <child @some-event="parentHandler">

Отличная работа, ребята.

С моей точки зрения, все изменения говорят о том, что лучший подход - создать дерево компонентов, основанное только на «одностороннем потоке», что намного проще и легче отлаживать и поддерживать.

Без этого достоверность ваших данных была бы обратно пропорциональна тому, насколько далеко вы находитесь от самого верхнего компонента.

Просто хочу сказать, что:

render (h) {
    return (
    <div>
      {this.things.map(thing => <Thing thing={thing}></Thing>)}
   </div>
 );

Делает меня счастливым

Ожидается ли, что перед выпуском 2.0 в этот список будет добавлено больше? Просто любопытно, так как вопрос все еще открыт.

@zephraph Да, мы постоянно обновляем список по мере обновления API. 😃 Ничего особенного, кроме редких критических изменений по сравнению с предыдущими альфа-версиями.

У меня есть случай, я использовал диспетчеризацию событий в прошлом, и я застрял с vuex: родительский компонент имеет список дочерних компонентов, а дочерний элемент отправляет событие, когда его значение изменяется, поэтому родительский элемент мог делать что-то как реакция на это изменение.
Теперь я попытался иметь массив дочерних значений в хранилище vuex. Дело в том, как дочерний компонент узнает в получателе и в действии, какой элемент этого массива ему необходимо обновить. Насколько я понимаю, vuex не предоставляет функции для динамического получения или запуска изменения значения, или я ошибаюсь в этом?
Как лучше всего справиться с этим случаем без диспетчеризации событий?

Когда $broadcast удаляется, как бы вы сказали прямому потомку что-то делать, когда происходит что-то особенное? Это был бы сценарий, в котором данные фактически не изменились, поэтому реактивные свойства не подходят.

Я мог бы использовать опору и передать метку времени или некоторые случайные данные и наблюдать за этой опорой у ребенка, но это кажется странным. Глобальная шина событий потребует генерации уникальных идентификаторов, чтобы дочерний элемент реагировал только на события от своего родителя, а не на любой другой экземпляр родительского компонента.

В дочернем элементе есть $emit который родитель может слушать с помощью встроенного слушателя, есть ли что-нибудь для обратного?

Я мог бы передать экземпляр эмиттера через опору, а затем emmiter.on в дочернем элементе, это звучит ужасно?

Действия @gwildu могут принимать аргументы, поэтому вы можете передавать идентификатор элемента вместе с действием. И вместо того, чтобы заставлять компонент элемента извлекать соответствующий элемент из магазина, извлеките список в родительском элементе и передайте данные элемента в компонент элемента с помощью свойства.

// Vuex store
state: {
  items: [],
},
mutations: {
  ITEM_REMOVED: function(state, id) {
    var io = state.items.findIndex(item => item.id === id);
    state.items.splice(io, 1);
  },
},

// within the parent component
vuex: {
  getters: {
    items: state => state.items,
  },
  actions: {
    removeItem(store, id) {
      store.dispatch('ITEM_REMOVED', id);
    },
  },
},

<!-- within the parent template -->
<item v-for="item in item"
  :item-data="item.data"
  @removed="removeItem(item.id)"
>
</item>

<!-- within the child template -->
<button @click="$emit('removed')">Remove</button>

Если ваши элементы не имеют локально уникальных идентификаторов, вы можете сгенерировать их при создании или получении элемента из API. В большинстве случаев cuid достаточно для этого.

@fergaldoyle из-за того, что родитель всегда знает своих детей, вы можете поместить v-ref:some-child в дочерний элемент, чтобы получить ссылку на $emit , либо просто вызвать метод напрямую с this.$refs.someChild.<methodName>(...) .

Однако я бы посоветовал переосмыслить архитектуру в этом случае, потому что текущие события делают компонент действительно трудным для размышлений.

Я играл с vuejs 2 и заметил Snabbdom, если вы пройдете

h('div', {style: {color: '#000'}}, [
  h('h1', 'Headline'),
  h('p', 'A paragraph'),
]);

К функции рендеринга вы получите

<div style="color:#000;"><h1>Headline</h1><p>A paragraph</p></div>

Но в vuejs вы получаете

<div style="color:#000;"><h1></h1><p></p></div>

Есть ли способ изменить текстовое содержимое (внутри <h1> )?

@dubcanada, почему бы просто не передать их детям?

Правильно, это имело бы смысл. Спасибо

Привет. У меня есть вопрос о системе перехода в Vue 2.0 или, скорее, о предложении, потому что я не вижу, чтобы это было в планах для Vue 2.0. В Vue 1.0 я часто сталкивался с необходимостью определять, когда закончится какой-то переход / анимация, которые я настроил. Теперь я делаю это с помощью setTimeout, но это очень хакерский и уродливый способ, мы все можем согласиться. Итак, мой вопрос: будет ли в Vue 2.0 каким-то образом обнаруживать конец перехода CSS, когда мы используем переход в сочетании с v-show / v-if, возможно, через событие?

<my-comp v-show="isVisible" @transition-end="onTransitionEnd" transition></my-comp>

я был бы очень рад увидеть что-то подобное в следующем выпуске Vue :) спасибо, что выслушали меня

@sqal, вы можете сделать это с помощью переходов: https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

@dubcanada будет поддерживаться в следующем выпуске (без данных при создании элемента)

Спасибо @fergaldoyle и @simplesmiler за ваш

Я не знал, родитель может прослушивать события, которые были отправлены дочерним элементом. Конечно, тогда имеет смысл прислушиваться к этому событию без пузырей.

Всем привет. Немного предыстории: мы работаем с webgl, и я хотел бы сделать некоторые интерфейсы на трехмерной поверхности. Это означает, что нам нужно визуализировать интерфейс, например, на холст, а затем преобразовать содержимое холста в текстуру.

Я работал с Angular, React и Vue, и для меня Vue имеет наибольший смысл! Читая о React, я наткнулся на проект react-canvas. Интересно то, что вместо того, чтобы преобразовывать виртуальный DOM в реальные узлы DOM, они рисуют его на холсте.

Поскольку Vue 2.0 также использует виртуальную модель DOM, мне было интересно, можно ли сделать что-то подобное?

Привет,

Просто некоторые пояснения по поводу удаления .sync и того, как может выглядеть общий рабочий процесс для обработки реквизитов в универсальном компоненте.

Итак, идя от
<component :value.sync="some.value"></component>
к
<component :value="some.value" @update="updateSomeValue"></component>

Какой рекомендуемый способ отслеживания опоры value ?
В самом простом случае кажется, что

props: ['value'],
computed: {
    _value: {
        get(){
            return this.value;
        },
        set(newVal) {
            this.$emit('update', newVal);
            return newVal;
        }
    }
}

Но, конечно, это зависит от родительского компонента, возвращающего это значение в опору, поэтому, когда компонент снова получает его, оно отражает самое последнее изменение ...

Означает ли это, что теперь нам нужно сделать что-то вроде этого:

props: ['value'],
data() {
    return {
        _val: this.value
    }
},
watch: {
    value(newVal) {
        this._val = newVal;
    }
},
computed: {
    _value: {
        get(){
            return this._val;
        },
        set(newVal) {
            this._val = newVal
            this.$emit('update', newVal);
        }
    }
}

Это похоже на множество шаблонов для обработки передачи (и изменения) значения, уведомления родителя об изменении значения и внутреннего отслеживания изменения на случай, если изменение не распространяется обратно родительским элементом.

Или мне здесь не хватает реактивности vue magic?

Кроме того, есть вероятность, что, если придется обрабатывать много реквизита, это может стать довольно сложным.
Я почти мог представить, как разрабатываю компонент-оболочку, где дети обращаются к this.$parent.value для непосредственного изменения, а компонент-оболочка просто обрабатывает props / computed / watch

@Towerful, что именно вы имеете в виду под «отслеживанием стоимости»? И почему вам нужен стиль сеттера ( this._value = newValue ) вместо явного this.$emit('value-updated', newValue) ?

Сила одностороннего потока заключается в том, что родитель может решить не применять изменение, запрошенное дочерним элементом, или может пометить дочерний элемент как «приостановленный» и применить изменение позже (например, после проверки на сервере).

@simplesmiler, использующий вычисляемое свойство, позволяет вам привязать его к шаблону, не так ли? так что вы можете использовать v-model .
И наличие установщика и получателя, содержащихся в одном месте, позволяет легко перейти и увидеть функциональность при обновлении значения, в отличие от наличия разных способов доступа к значению и изменения значения внутри компонента и разброса по всему коду.
Если вы используете явный способ в модели и не используете сеттеры, кажется, что объект methods будет загроможден методами типа updateValue для шаблона, а не фактическими методами.

Я предполагаю, что это применяется, когда пользователь выбирает параметр в компоненте, и компонент полагается на это значение, чтобы показать, что выбрано.
Вы полагаетесь на то, что родительский компонент передает это обратно в компонент, чтобы он мог это сделать.
За исключением случаев, когда пользователь выбирает параметр, вы запускаете обновление отображения компонента вручную. Кажется, что это уходит от реактивности Vue.
Итак, имея внутреннее значение, отслеживающее, каким оно «должно быть», пусть шаблон отреагирует на это. Используйте сеттеры / геттеры, чтобы обернуть свойство, чтобы отслеживать внутренние изменения и вызывать внешние события, и следите за свойством, чтобы обновлять внутреннее значение при его внешнем изменении.

Возможно, я просто изо всех сил пытаюсь понять, как это сделать по-новому.

@Towerful - Ты не единственный ....

Скотт

@Towerful :

Мне кажется, что то, что вы описываете, по сути, является компонентами, которые действуют как входы с v-model : пользователь изменяет какое-то значение в пользовательском интерфейсе, и вы хотите, чтобы это изменение немедленно отразилось в связанных данных.

Для этих типов компонентов вы можете использовать v-model для компонентов в 2.0:

<my-input v-model="myValue">

// in my-input.vue
<input :value="value" @change="$emit('input', $event.target.value)">

export default {
  props: ['value']  //special prop received from v-model
}

Это делает интерфейс к реальным элементам <input> и настраиваемым компонентам ввода по существу идентичным, а также двустороннюю привязку.

Для более сложных компонентов, которые получают несколько реквизитов (и не являются простыми пользовательскими входными данными, а являются более абстрактными), мы не рекомендуем использовать .sync потому что в большинстве ситуаций становится трудно рассуждать об этом.

Родитель должен решить, что делать со значением, которое он получает от дочернего элемента, его данные не должны изменяться неявно, как это делает .sync .

Можете ли вы привести пример, который _не_ решает проблему с подходом с v-моделью, описанным выше, и все еще выигрывает от использования .sync ? Это может быть лучшим основанием для обсуждения, чем абстрактная теория.

О, как я это пропустил ?! Это определенно есть в OP, и некоторые комментарии назад даже обсуждали это! Теперь чувствую себя немного глупо.
Можно ли обновить исходный пост, чтобы прояснить, что v-model можно использовать в компоненте?
@LinusBorg Совершенно верно , я не могу придумать случая, когда v-model на компоненте не сработает. Я пропустил эту часть в исходном посте.
Даже для сложных объектных компонентов это будет просто вопрос вложенности компонентов. И это усиливает компоненты единой ответственности.
В этом гораздо больше смысла :)

@Towerful

Re: с использованием v-model . Дело в том, что v-model является синхронным (в некотором смысле), в то время как межкомпонентный поток данных по своей сути асинхронен из-за очереди наблюдателя ( демонстрация ). Я видел, как это сбивает с толку многих. Односторонний поток просто делает более явным, что реквизиты не синхронны, и заставляет вас не полагаться на их синхронность (это то, что вы пытаетесь обмануть).

Re: загроможденные методы. В простых случаях всегда можно сделать @value-updated="value = $arguments[0]" . Для сложных случаев хорошо иметь метод, в котором вы можете настроить состояние, чтобы оно оставалось согласованным (например, запускать обновления вручную). Сегвей к следующей точке.

Re: уход от реактивности. Я не согласен с этим утверждением. В простых случаях вам не нужна магия, чтобы заставить ребенка подбирать значение, обновленное value-updated="value = $arguments[0]" .

В сложных случаях с реквизитами .sync вам придется использовать watch , но явное значение watch самом деле не является частью реактивности. Это аварийный выход, с помощью которого вы запускаете ручные обновления, которые нельзя выразить как вычисленные. И он плохой, потому что не может синхронно реагировать на изменения, как вычисленный. Вот почему при интенсивном использовании watch вы можете обнаружить, что ваши обновления данных распространяются за несколько «тиков». Если вы когда-нибудь сталкивались с вложенными напрямую nextTick , вы понимаете, о чем я говорю.

Теперь обработчик -updated обеспечивает лучший выход, позволяя применять сложные изменения модели синхронно (или одновременно асинхронно) после того, как дочерний элемент выражает намерение, гарантируя, что дочерний элемент получит обновленные значения в следующем тике (или не будет получить несогласованное состояние).

@ yyx990803 Можно ли реализовать способ прослушивания $ emits, аналогичный тому, как у нас были события для $ dispatch и $ broadcast в vuejs1?

Чувствует себя более vuejs-esque, что-то вроде этого ('on' или 'listen'):

Vue.component('cart', {
  template: "#cart-template",
  data () {
    return {quantity : 0 }
  },
  watch: {
    'quantity': function (quantity, oldQuantity) {
      console.log('quantity changed from %s to %s', oldQuantity, quantity)

      bus.$emit('cart.quantity-changed', quantity)
    }
  }
});

new Vue({
  el: '.container',
  data : function () {
    return {
      quantity: 0
    };
  },
  on: {
    'cart.quantity-changed': function (newQuantity) {
      console.log('quantity change emitted');

      Vue.set(self, 'quantity', newQuantity);
    }
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

Это в основном автоматически присоединяется к глобальной шине.

Шины событий - это не шаблон, который мы хотим поощрять - он полезен только в некоторых крайних случаях. Как правило, предпочтительнее использовать шаблон магазина, такой как vuex.

Внедрение API, упрощающего использование шины и ощущающего «официальную поддержку», было бы неверным сигналом.

Глядя на ваш пример, если вы сохранили количество в магазине, к которому имеют доступ оба компонента, никаких событий не потребуется. Вычисляемое свойство в компоненте container обновится автоматически.

Простой пример кода без использования реального решения для магазина, такого как vuex:

var store = {
  cart: {
    quantity: 0
  }
}
Vue.component('cart', {
  template: "#cart-template",
  data () {
    return store.cart
  },
});

new Vue({
  el: '.container',
  data : function () {
    return store.cart;
  },
  computed:{
    gold: function(){
      return this.quantity * 100
    }
  }
})

Я бы сказал, что основная идея vue2 - сделать сложнее застрелить себя
в ногу.

В воскресенье, 3 июля 2016 г., в 11:24, Торстен Люнборг [email protected]
написал:

Шины событий - это не шаблон, который мы хотим поощрять - это всего лишь
полезно в некоторых крайних случаях. Как правило, предпочтительнее использовать шаблон магазина, такой как vuex.

Внедрение API, который упрощает использование автобуса и делает его "официальным"
поддержали "было бы неверным сигналом.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -230158828 или отключить звук
нить
https://github.com/notifications/unsubscribe/AACoukCpCgYlDbVej_w_h4NEhQ-imYHBks5qR9QwgaJpZM4IedHC
.

@kharysharpe $emit предназначены для прослушивания с помощью v-on в дочернем экземпляре. Это также дает дополнительное преимущество, заключающееся в возможности подключиться к исходному контексту того, где используется экземпляр:

<list-item v-for="(item, index) in items"
  :title="item.title"
  @remove="items.splice(index, 1)"
>
</list-item>

Есть ли дата выхода 2.0? Я очень рад изменениям. Поздравляю!
Думаю использовать Vue 2.0 + Redux.

@Sendoushi Пока нет даты финального релиза, но бета может быть в течение недели. 😄 Vuex 2.0 также разрабатывается параллельно, и он не только будет иметь гораздо более простой API, чем текущий vuex, но также будет интегрироваться в экосистему Vue намного лучше, чем redux.

Наряду с этим разрабатывается Vuex 2.0, и он не только будет иметь гораздо более простой API, чем текущий vuex, но и гораздо лучше интегрируется в экосистему Vue, чем redux.

@chrisvfritz Замечательно слышать! Мне всегда казалось, что текущий API слишком сложен и излишне сложен. В итоге пришлось делать что-то вроде этого, чтобы компенсировать:

const mutations = {
  LOGIN (state) { state.loggedIn = true },
  LOGOUT (state) { state.loggedIn = false }
}

export const types = Object.keys(mutations)

// For now we dynamically generate all the actions like this.
// It's rare when anything more complicated is needed, but there
// is an example here:
// http://vuex.vuejs.org/en/actions.html
export const actions = types.reduce((o, el) => {
  var action = S(el.toLowerCase()).camelize().s
  o[action] = ({dispatch}, ...args) => dispatch(el, ...args)
  return o
}, {})

Как насчет дорожной карты vue 2 и vuex 2. Планируется ли выпускать их вместе или один за другим, и как насчет совместимости разных версий?

Что касается вопроса выше, каков статус с vue-router - скоро ли он получит поддержку Vue 2 или нужно будет проводить тестирование Vue 2 без маршрутизатора?

@gwildu Они, скорее всего, будут выпущены вместе, и Vuex 2.0 будет поддерживать только Vue 2.0. Vuex до версии 2.0 будет по-прежнему получать поддержку до тех пор, пока Vue 1.x не перестанет поддерживаться.

@Uninen Vue Router получит некоторую любовь в следующий раз, до выпуска Vue 2.0.

Спасибо за nfo @chrisvfritz :)

@chrisvfritz Исправление @Uninen : Vuex 2.0 также работает с Vue 1.x.

Следующая основная версия vue-router будет поддерживать только Vue 2.x.

Сборка только во время выполнения: поскольку она не включает компилятор, вам нужно либо предварительно скомпилировать шаблоны на этапе компиляции, либо вручную написать функции рендеринга.

Будет ли / будет ли способ предварительной компиляции шаблонов без использования vueify / vue-loader и файлов .vue ? Если нет, было бы неплохо иметь плагин babel для преобразования template: свойств в render функции в компонентах?

После обновления до 2.0 можно по-прежнему использовать устаревшие функции. Можете ли вы сначала выполнить обновление до 2.0, а затем постепенно менять устаревшие функции?

Можно ли будет создать терминальный компонент после того, как elementDirective больше не будет?

Как уже упоминалось:

v-model больше не заботится о начальном встроенном значении. Он всегда будет рассматривать данные экземпляра Vue как источник истины.

Считают, что

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value" />
  <label :for="_uid"><slot></slot></label>
</child-component>

Как мне установить флажок с массивами между пользовательскими компонентами?

_Обновлено 1: _
Решено. Передайте опору type="checkbox" дочернему компоненту в родительском компоненте.

<parent-component>
  <child-component type="checkbox" v-model="parentModel" value="apple"  />
  <child-component type="checkbox" v-model="parentModel" value="orange" />
  <child-component type="checkbox" v-model="parentModel" value="banana" />
</parent-component>

Затем вы можете получить встроенное значение с помощью {props: [ 'value' ]} .
Отправьте событие change родительскому компоненту, чтобы сообщить, что значение изменилось.

<child-component>
  <input type="checkbox" :id="_uid" v-model="childModel" :value="value"
    @change="$emit('change', $event)"
  />
  <label :for="_uid"><slot></slot></label>
</child-component>

Это связано с тем, что компилятор компилирует директиву v-model соответствии с ее type . И компилятор сгенерирует опору checked и привяжет к ней событие change .

_Обновлено 2: _
Однако ловушка жизненного цикла updated не срабатывает из-за того, что v-model напрямую изменяет атрибут checked (это означает, что вы не можете получить событие change встроенного компонента флажка html, изменив значение v-model ).
Итак, @ yyx990803 , можете ли вы вызвать событие change после изменений v-model ?

@ YunSun-CN Единственный способ, которым я смог обойти вашу проблему, - это добавить свойство, специфичное для значения, ala val, и использовать его для установки фактического значения, а затем просто отправить изменения во вход v-модели ' событие.

@johnleider Я написал специальную директиву для имитации того, что делает v-model .
Кстати, вы должны создавать модели строго, не только проверяя type prop, но и проверяя tagName элемента. В противном случае другой пользовательский компонент с type prop может перезаписать его поведение модели по умолчанию.

Привет. Мы знаем дату выхода?

@thanosalexander Мы еще не определились с датой, нет. Мы только что внесли несколько серьезных изменений в систему переходов с 2.0.0-bet.2, которые должны быть тщательно протестированы. Так что, на мой взгляд, нам понадобится пара недель, прежде чем мы сможем подумать о выпуске.

хорошо .. я пойду с этим ... не думаю, что шаг в стойло будет слишком большим! Спасибо

А как насчет документов? Одной из причин, по которой Vue был принят раньше времени, была документация, и это единственная причина, по которой я сдерживался сейчас с v2. Я видел проблему, связанную с документами, но не вижу, скоро ли будет закончено. Наверное, я игнорирую так много всего, что происходит под капотом, поэтому возникает вопрос :)

Есть ли планы реализовать переходный режим вне переключения компонентов в 2.0?
https://github.com/vuejs/Discussion/issues/156

@ miljan-aleksic Документы будут готовы, когда будет официально выпущена версия 2.0. Мы все еще находимся в стадии бета-тестирования. ;)

А пока вы можете следить за развитием документации здесь (или даже вносить свой вклад)

@aristidesfl Уже сделано. 🎉

@ miljan-aleksic В дополнение к тому, что упомянул @LinusBorg , большая часть нового руководства уже завершена, и вы даже можете прочитать исходный код здесь, если хотите. Однако имейте в виду, что на момент написания он не был полностью обновлен, чтобы отразить изменения в бета-версии 2 , значительная экспертная оценка еще впереди, и есть некоторые другие незначительные изменения API, которые рассматриваются. Поэтому, если вы не хотите помогать исправлять опечатки и улучшать пояснения, я бы рекомендовал подождать, пока мы официально опубликуем (возможно, на этапе RC).

Мы также согласны с тем, что отличная документация является важной частью Vue. Даже Дэн Абрамов из команды React любит наши документы. 😄 Вот почему это одна из моих личных целей, чтобы документы 2.0 были _ еще лучше_. А пока ...

Для тех, кто хочет узнать о 2.0 раньше, я бы порекомендовал функциональные модульные тесты как самый последний доступный ресурс.

Это один из моих основных ресурсов при написании документации, и они, как правило, вполне читабельны, если вы знакомы с Jasmine.

Спасибо @chrisvfritz , очень полезная информация. Я попробую новую документацию, учитывая ее незавершенную работу и отзывы по мере необходимости. Пришло время серьезно отнестись к Vue 2.0;)

createElement в функции рендеринга, использующей on, похоже, не обрабатывает массивы (как это делает snabbdom), есть ли способ передать данные вызываемым функциям?

Например, в снаббдоме я могу использовать

{on:{click: [function, dataToPass]}}

И function получит dataToPass в качестве первого аргумента. Но это похоже на ошибку в vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function . Есть ли способ передать данные и событие с помощью элемента on from create?

@dubcanada обработка событий в Vue 2.0 отличается от обработки событий snabbdom - вы должны сами каррировать функцию. Синтаксис массива просто присоединяет несколько обработчиков к одному и тому же событию.

Я пытаюсь получить содержимое слотов в виде строки вместо их рендеринга. Со стандартными узлами есть простой обходной путь, но с Vnodes я не нашел способа. Есть ли способ обхода этого?

@ miljan-aleksic Попробуйте отрендерить его, получив содержимое элемента с помощью innerHTML , а затем скройте элемент с помощью display: none в css.

Спасибо за помощь. Если я его визуализирую, окончательный результат будет другим. Я создаю компонент, который будет заключать свое дочернее содержимое в тег pre и кодировать HTML.

В этом случае визуализируйте вывод в элементе, отличном от исходного.

Хотя я отмечу, что создание шаблонов не должно быть вашим способом написания контента. Это должен быть способ описания _как_ пишется контент, а не сам контент. Я бы порекомендовал сохранить текст в виде строки в JS (или в качестве ресурса где-нибудь еще в вашем проекте, особенно_, если это какой-то пользовательский ввод), а затем передать его дочернему элементу как опору, которая должна делать вещи тысячу раз в любом случае проще.

Вы правы, @Kingdaro , лучше не смешивать концепции и сохранять простоту. Хотя было приятно иметь синтаксис hihgligthig :)

При использовании v-on директивы по $arguments переменный больше не доступно. Я не вижу здесь никаких упоминаний об этом изменении. Это ошибка или отсутствует ссылка?

@ miljan-aleksic просто используйте arguments .

Должно быть, разработчик PHP (как и я) ... Я знаю, что вы чувствуете. РЖУ НЕ МОГУ!

Скотт

@ yyx990803 , @smolinari Я ... и теперь смущенный, ха-ха. Я заставил себя поверить, что я уже пробовал это ... кажется, я не достаточно хорошо. Это работает, спасибо и извините за то, что потратили время.

Я собирался открыть тикет о другой «проблеме», но больше не уверен, так ли это ... При использовании ref зарегистрированный компонент или элемент не доступен сразу, поэтому что-то подобное не сработает.

<button ref="button"...></button>
<foo :connect="$refs.button"></foo>

На момент отрисовки Foo $refs.button все еще не определен. В Vue 1 работает как положено. Что мне не хватает на этот раз?

Вам не хватает того, что вы не должны передавать элементы DOM или экземпляры компонентов в качестве свойств ...

Почему это плохая идея? Допустим, у меня есть компонент раскрывающегося списка, который я хочу подключить к кнопке (триггеру). Оба являются независимыми компонентами, и вместо того, чтобы связывать их с помощью запроса, я напрямую передаю ссылку.

@ miljan-aleksic даже лучше соединить через состояние:

• открытое / закрытое состояние поддерживается в их общем родителе
• родитель передает состояние в раскрывающийся список как опора
• родитель прослушивает событие кнопки, чтобы переключить состояние

Таким образом, раскрывающийся список и кнопка полностью разделены, кнопку можно повторно использовать для управления другими типами компонентов, а раскрывающимся списком можно управлять с помощью других типов компонентов ввода.

Избавиться от старых привычек непросто. Должен ли я винить jQuery или в основном меня? : D

Ваш подход, Эван, правильный. Я пойду по этому пути, даже если это будет означать, что интеграция с Dropdown будет более утомительной. Поскольку родительский компонент должен знать о том, как прослушивать различные события, не только об открытии, но и о закрытии раскрывающегося списка при щелчке за пределами раскрывающегося списка, но не о самом раскрывающемся списке и т. Д. Многие события и обходные пути, которые решает раскрывающийся список.

Поскольку родительский компонент должен знать о том, как прослушивать различные события, не только об открытии, но и о закрытии раскрывающегося списка при щелчке за пределами раскрывающегося списка, но не о самом раскрывающемся списке и т. Д. Многие события и обходные пути, которые решает раскрывающийся список.

Еще может? вы можете полностью выполнить addEventListener('body', ... ) из раскрывающегося компонента, чтобы зарегистрировать внешние клики и т. д. Выпадающее меню может просто генерировать событие «закрыть» для родителя, когда кто-то щелкает снаружи, например.

Да да. Пора реорганизовать некоторые компоненты :) Всем спасибо! Замечательное сообщество.

Как применить v-model к компоненту с createElement ? Я посмотрел на сгенерированный код с помощью компилятора шаблонов, и ... это много кода. Я не совсем понял документацию о директивах.

По умолчанию директива времени компиляции извлекает директиву, и директива не будет присутствовать во время выполнения. Если вы хотите, чтобы директива также обрабатывалась определением среды выполнения, верните true в функции преобразования.

@blocka у вас нет доступа к встроенным директивам, если вы используете функцию render . Вам придется самостоятельно обработать эквивалентную логику. Например, v-if - это просто троичное выражение, v-for - это выражение array.map() ... и v-model (для обычного элемента <input> ) переводится в value связывания и input событие слушателя.

@ yyx990803 вот что я подумал. Я, вероятно, закончу обрабатывать это с помощью HOC (я уже передаю условные выражения таким же образом (хотя я думаю об использовании этого )

В vue 1 было заявлено два преимущества vuex и redux.

1. Производительность лучше, поскольку vuex изменяет состояние, что лучше всего работает с vue (замена старого состояния имела производительность, эквивалентную «грязной проверке»)
2. Vuex более "осведомлен" о том, что он находится в приложении vue.

Снижает ли использование виртуального домена частично или полностью 1?

@blocka он

Что изменилось в версии 2.0, так это степень детализации реактивности. Проведем сравнение:

• В Vue 1.x реактивность очень детализирована. У каждой директивы и каждой текстовой привязки есть соответствующий наблюдатель. Это приводит к мелкозернистым обновлениям при изменении данных, но за счет увеличения накладных расходов на отслеживание зависимостей при первоначальном рендеринге и немного большего использования памяти.
• В Redux у реактивности нет никакой детализации. Всякий раз, когда что-то меняется, необходимо заново отрисовать все приложение. В React привязка Redux выполняет некоторую оптимизацию для подключенных контейнеров, но пользователю по-прежнему необходимо широко реализовать shouldComponentUpdate для повышения производительности.
• В Vue 2.0 реактивность имеет среднюю степень детализации. У каждого компонента есть соответствующий наблюдатель, который отслеживает зависимости этого компонента. При изменении данных только компоненты, зависящие от изменения, должны будут повторно визуализировать свою виртуальную DOM. По сути, это лучший сценарий для React, но вам не нужно ничего делать для этого в Vue 2.0.

Обычно с 2.0 вы увидите (по сравнению с 1.x)

• немного более медленные (но все же очень быстрые) обновления для небольших изменений данных
• прилично более быстрые обновления для средних и крупных изменений данных
• значительно более быстрый начальный рендеринг

Привет,
у меня не работают переходы с animated.css.

<transition enterClass="fadeIn" leaveClass="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

Есть у кого-нибудь идея?

Ваши имена реквизитов неправильные.

camelCase vs kebap-case по- прежнему применяется в версии 2.0.

<transition enter-class="fadeIn" leave-class="fadeOut" class="animated" mode="out-in"> 
  <router-view keep-alive></router-view> 
</transition>

@LinusBorg Мне очень жаль, я уже пробовал. Вот и небольшая скрипка. С переходами css и тегом имени он работает нормально.
https://jsfiddle.net/z0nyfba0/

При использовании v-model в компоненте будет ли компонент виден для любых модификаторов, используемых с v-model ?

например, если у меня есть компонент, который генерирует событие input , когда это событие генерируется, зависит от того, используется ли модификатор lazy или нет.

@fergaldoyle Я немного change к вводу, например https://jsfiddle.net/cynhtLty/1/

@calebboyd

https://jsfiddle.net/Linusborg/z0nyfba0/1/

1. Вы должны использовать enter-active-class и leave-active-class
2. Вы должны поместить class="animated" в элемент <router-view> .

@fergaldoyle Согласно документации 1.0, я думаю, что с lazy v-модель просто отреагирует на change вместо input . Вы можете использовать это, чтобы изменить поведение и выдать input или change чтобы дать разные результаты в зависимости от того, задано ли lazy или нет.

Я чесал в затылке, играя с простым примером v-for . По какой-то причине привязка value не работает для элементов select в версии 2.0: https://jsfiddle.net/972eL5fL/

Также, вероятно, следует отметить в документации, что диапазоны v-for, такие как "i in 10" начинаются с 1 вместо 0, как в 1.0.

@lauritzen

Я чесал голову, играя, например, с простой буквой v. По какой-то причине привязка значений не работает для выбранных элементов в 2.0: https://jsfiddle.net/972eL5fL/

Кажется, у меня все работает так, как ожидалось, что не работает у вас?

Объявление государственной службы

Мы рекомендуем вам задавать вопросы в службу поддержки на форуме или в gitter .

Этот вопрос следует оставить для обсуждения нового API. Если здесь мы займемся поддержкой по различным вопросам, это выйдет из-под контроля.

Спасибо.

Почему vm. $ Get устарел?
Почему бы вместо этого не Vue.get?
Это очень полезно для оценки таких вычисленных выражений
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

@iagafonov не так много сценариев, в которых это может быть полезно, поэтому оно не должно быть частью ядра.

Если вам нужна функциональность для одного из немногих сценариев, вы можете очень легко добавить подобное поведение с помощью, например, lodash:

import get from 'lodash/get';
Vue.prototype.$get = get

//in any component
var value = this.$get(this.someObject,'some.path.to.value')

(конечно, вы также можете добавить его как «метод класса» как Vue.get () - или просто импортировать его локально, где он вам нужен - на ваш выбор)

@LinusBorg. Во-первых, я не использую lodash или что-то в этом роде.
Во-вторых, реализация lodash медленная, потому что во время выполнения пытается глубоко проникнуть в структуру выражения. vue соответствует новой указанной функции (parseExpression), привязанной к области видимости.
Это нетривиальная часть, это очень сложно реализовать заново.
Конечно, каждый раз функция компиляции $ get). Было бы неплохо, если бы parseExression был, например, частью api в Vue.util.

@iagafonov this.$get также должен анализировать путь во время выполнения и получать значение динамически. В противном случае вы получите сообщение об ошибке, если путь не существует. Кроме того, в большинстве случаев разница в производительности будет незначительной. Если вам не нужен lodash, существует множество других библиотек для поиска путей. Это больше не является частью заботы Vue.

Какие есть альтернативы устаревшим атрибутам param?

вы говорите о параметрах в директиве? Затем вы можете найти все связанные атрибуты внутри объекта vnode

<button v-test="123" color="red" type="button">click me</button>

bind (el, binding, vnode) {
 // vnode.data.attrs -> { color: 'red' }
}

@sqal , это ответ на мой вопрос? Если это так, я говорю об атрибутах param, таких как lazy, number и debounce. Например, до версии 2.0 я мог сделать это <input type="text" v-model="msg" number> (число здесь является атрибутом параметра). Как я могу получить такие же результаты без использования атрибута param?

@ p-adams упоминается в посте - теперь они модификаторы <input v-model.number="msg">

Я обнаружил, что в Vue 2.0 при изменении реквизита всегда вызывается функция рендеринга, поэтому мне интересно, будет ли 2.0 поддерживать shouldComponentUpdate чтобы решить, нужно ли выполнять повторный рендеринг.

@ yyx990803 Хорошо, теперь я вижу это в посте The lazy and number params are now modifiers .

@HeChenTao Эван немного объяснил это здесь https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

@HeChenTao функция рендеринга вызывается не всегда, а только тогда, когда это необходимо:

• Vue не требует shouldComponentUpdate из-за его реактивности.
• Когда реактивные данные, которые используются в компоненте, изменяются, это запускает функцию рендеринга, vdom diffing и так далее.
• Но если ни одна из этих данных не изменилась, обновление не требуется, и функция рендеринга _не_ будет вызываться.

То же самое можно сделать в реакции с mobx. Я почти уверен, что вам не нужно реализовывать shouldComponentUpdate . Однако, как и vue, mobx настаивает на изменяемом состоянии. Если по какой-то причине вы приняли концепцию неизменяемого состояния. В этом случае у response есть ваша спина shouldComponentUpdate .

Значит ли это, что если кто-то настаивает на неизменном состоянии, vue не подойдет?

Аргумент контекста функциональных компонентов имеет children плюс slots . Меня немного сбивает с толку, зная, что children() и slots().default это одно и то же. Заставляет меня задуматься, каков правильный подход. Возможно, «дети» как игровые автоматы ленивы, но все же зачем поддерживать два разных способа добиться одинакового поведения?

Функциональные компоненты - это просто функции, поэтому у них нет дочерних элементов. IMHO, детские должны быть устаревшими и просто держать слоты как не ленивые.

@blocka, вы можете реализовать реактивные данные в реакции с mobx, правда. Но реактивность лежит в основе функциональности Vue. Так что, если это не его чашка чая, этот человек оказался не на той вечеринке.

@ miljan-aleksic children необработанный (вы получаете каждый узел независимо от того, в какой слот он должен войти), slots будет разрешен на основе имен slot для входящих потомков.

Спасибо @ yyx990803. Возможно, более подробная информация об этом в документации поможет избежать недоразумений, @chrisvfritz.

@ miljan-aleksic Добавлю примечание. 👍

Что касается фильтров, использование вычисляемого свойства кажется достаточно простым, но как справиться со случаем использования фильтра с v-моделью. Если кто-то хочет фильтровать список имен, вводя текст в поле ввода, как это можно сделать в версии 2.0?

Мысли о том, чтобы Vue предупреждал, когда поле данных / вычисляемое свойство не используется в шаблоне? Я предполагаю, что здесь есть некоторые ограничения, но было бы очень полезно знать, где я могу позволить себе вытащить бесполезный импорт из магазинов, где он не нужен.

@ yyx990803 , что вы думаете об установке ссылки $context на прототип компонента? Так же, как с $parent или $root я обнаружил, что часто обращаюсь к контексту, который в настоящее время доступен только через объект $vnode .

На самом деле это не кажется надежным способом доступа к контексту. Как это сделать?

@ miljan-aleksic Можете ли вы поделиться примерами использования, когда вы часто обращаетесь к контексту?

@Kingdaro Можете ли вы задать вопрос по этому поводу? Звучит хорошо, если это будет возможно.

@ p-adams Вы все еще можете использовать вычисленное свойство с Array.prototype.filter .

@chrisvfritz , в основном для обходных путей, например, для установки переменных в контексте, который ожидает ребенок. Или установить ссылку на компонент раньше, чем это делает сам Vue.

Я согласен, что это не является общим для всех, но, по крайней мере, должен быть надежный способ доступа к нему внутри компонента. $ Vnode отсутствует до тех пор, пока компонент не смонтирован при использовании шаблонов (по крайней мере, мой вывод на данный момент).

Я был бы доволен знанием того, как получить к нему доступ должным образом.

Другая ситуация, когда $context может быть полезна, - это повторное использование компонента как корня другого компонента.

<template>
  <Foo>
    <child/>
  </Foo>
</template>
<script>
{ name: 'Bar' ... }
</script>

В примере child.$parent вернет компонент Foo вместо Bar, что правильно, но если родительский и дочерний элементы зависят друг от друга, прямая связь между ними может осуществляться через контекст.

@ miljan-aleksic Я оставлю это @ yyx990803. Я бы сказал, что, как и в случае с $parent , достижение $context , вероятно, будет неправильным способом в 99,9% случаев, и я думаю, что, вероятно, никогда не буду его использовать.

У меня ситуация с v-show и переходами. В этом сценарии есть модальное окно, которое по умолчанию имеет значение «display: none» в CSS. В сочетании с v-show он никогда не будет отображаться, поскольку директива удаляет свойство отображения, а затем сохраняются CSS-свойства. Я не могу изменить CSS (требования к проекту), и я не могу использовать настраиваемую директиву, поскольку, похоже, переходы Vue зависят именно от нее.

Теперь я думаю, что директива, которая выполняет оценку сразу после v-show, может установить свойство display на блокировку. Нужно попробовать это, но в любом случае было бы неплохо добавить модификатор в v-show, чтобы разрешить настройку отображения на блокировку или встроенный блок. Просто мысль.

@chrisvfritz , ожидается, что для функциональных компонентов родительская ссылка будет не непосредственным родительским элементом, где они используются в качестве слотов, а вместо этого контекстным компонентом?

Компиляция шаблона завершается ошибкой, если он содержит «<» (и, возможно, другие символы, чувствительные к HTML) в версии 2.0.0-beta7.

https://jsfiddle.net/x0r59ur1/

Это работало в 1.0.26.

Преобразование «<» в «<» решает проблему.

@GlurG должен правильно экранировать "<".

@ yyx990803 , если я хочу использовать переходы в списке компонентов одного типа и сохранить их состояние, как мне это сделать? Следуя документации, я вижу только то, как компоненты разные.

Допустим, компонент вкладки и переход между его элементами. Я не могу найти способ :(

<tabs>
  <transition>
    <tabs-item>Content 1</tabs-item>
    <tabs-item>Content 2</tabs-item>
    <tabs-item>Content 3</tabs-item>
  <transition>
</tabs>

@ miljan-aleksic <transition> предназначен только для одного элемента. Вам нужно <transition-group> для нескольких элементов.

@ yyx990803 ,

@ yyx990803 , @LinusBorg Я ценю помощь, но решение неочевидно. Я знаю, как применяются переходы, но я не могу понять, как keep-alive переходить компоненты.

Для ясности я создал новую проблему с примером jsfiddle, в котором каждый раз создаются компоненты.

@ yyx990803 , должным образом.

Вы буквально меняете мою жизнь, благодаря своим продуктам и трудовой этике я могу изучать, создавать и поставлять продукты, которые у меня долгое время оставались в резерве. Благодаря вашему простому подходу высокие технологии станут доступны каждому, чтобы их можно было использовать и развивать. За все это и многое другое я бесконечно благодарен.

@ miljan-aleksic Есть кампания Patreon Подмигнуть Подмигнуть .

Вы знаете, что такое @phanan , вы совершенно правы. Я начал поддерживать Эвана лично, и как только продукты компании начнут давать результаты, я сделаю так, чтобы поддержка стала более заметной.

Ловушка жизненного цикла ready устарела в пользу mounted ; но согласно журналу изменений нет никакой гарантии, что компонент будет отрисован до вызова монтирования. Это вызывает спорадические ошибки, когда я хочу инициализировать определенные компоненты jquery (например, selectize) после инициализации компонента. Какой крючок жизненного цикла я должен использовать вместо этого? Можно ли смоделировать "готовый" хук так:

function mounted() {
  Vue.nextTick(() => {
    //...
  });
}

@GlurG Да, это сработает. И, кстати, это тоже было обязательно с ready'() в 1.0 во многих случаях.

Есть ли причина, по которой для этого не может быть крючка? Я также
через это ... даже в 1.0, и прибегал к таким вещам, как цикл с raf для
проверьте, находится ли он в домике и т. д.
10 августа 2016 г., 18:26, «Торстен Люнборг» [email protected]
написал:

@GlurG https://github.com/GlurG Да, это сработает. И кстати,
во многих случаях это также было необходимо с ready '() в 1.0.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -238903012 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AACounAoI8p65soUUrbdaiwteDXKgMGJks5qee25gaJpZM4IedHC
.

При использовании функций рендеринга основные директивы игнорируются, что вполне разумно. Но некоторые из них не так просто воспроизвести с использованием простого js, как v-model который имеет обходные пути для IE9 и, вероятно, решает другие проблемы крайнего случая.

Это заставляет вас пересмотреть решение об использовании шаблона, но это невозможно или лучший вариант в некоторых ситуациях. Документы определенно могли бы предложить больше рекомендаций по этой теме, и, кроме того, было бы неплохо иметь помощника при работе с функциями рендеринга, который помог бы решить эти распространенные ситуации и никому не пропустить шаблон.

@ miljan-aleksic извините, я удалил свой комментарий, потому что заметил, что он работает только для v-show или пользовательских директив, и да, как вы сказали в случае v-модели, необходимо добавить прослушиватель ввода / изменения и обновить наши данные вручную

должен ли вызываться новый хук activated запуске маршрута, который активирует / монтирует router-view ? В настоящее время я не наблюдаю такого поведения.

@wprater нет, это связано исключительно с <keep-alive> и ни с чем другим.

@ yyx990803 Я оборачиваю свой router-view в keep-alive, но я не могу найти зацепку, когда я возвращаюсь к предыдущему виду. mounted или activated . Мне нужно быть уверенным, что дом рендерится.

@wprater, пожалуйста, не используйте эту

Поддерживает ли Vue JSX оператор распространения объекта? Я пробовал, но не работает.

Он работает, и @ yyx990803 приложил много усилий, чтобы заставить его работать.

Я делаю это <Component {...{ props } }></Component> и он работает, как описано в документации.

@blocka Спасибо! Я думал, что имя свойства props не нужно 😂

@ yyx990803
Опции components не поддерживают тип массива, но работают в 1.x.

например

var Parent = Vue.extend({
  name: 'parent',
  template: '<div><slot></slot></div>'
})

var Child = Vue.extend({
  name: 'child',
  template: '<span>hello</span>'
})

new Vue({
  el: '#app',

  components: [
    Parent,
    Child
  ],

  replace: false,

  template: '<parent><child></child></parent>'
})

Это ошибка?

@ QingWei-Li они просто больше не поддерживаются, так как это никогда не было официально задокументированной функцией. Причина в том, что в ES2015 вы можете просто написать components: { Parent, Child } .

просто небольшое предложение,
есть ли шанс для нормальной итерации массива, мы используем v-foreach а для диапазона мы используем v-for .

что будет иметь больше смысла для пользователей, пришедших с php, и даже согласуется с .each в JQ или foreach в JS

@ ctf0 Мы находимся в стадии RC, API больше не будет меняться. И мы не будем вводить альтернативный синтаксис для выполнения того же самого.

Я не думаю, что мысленные накладные расходы, связанные с v-for="item in items" достаточно значительны, чтобы гарантировать это.

С этой новой версией вы бы справились с этим делом.

У меня есть компонент календаря (поступающий из семантического пользовательского интерфейса), который использует классический ввод текста и показывает дату в человеческом формате (например, «10 июля 2016 года»). В версии 1.0 я использовал двусторонний фильтр для преобразования этой строки в правильную дату, чтобы данные моего объекта были непосредственно готовы к отправке. Но поскольку фильтры больше не работают в v-модели, как я могу сделать то же самое сейчас в v2.0?

Спасибо

@shadowRR можно будет увидеть какой-нибудь код?

@ p-adams Конечно. Ну вот.

Во-первых, мой фильтр, который используется в моей v-модели для ввода календаря. Его единственная цель - записать при изменении значения правильный тип даты в мои данные (дата postgres).

Vue.filter( 'formatDate', {
        read( date ) {
            return date;
        },
        write( date ) {
            if( !date ) return null;
            return moment( date, 'D MMMM YYYY' ).format( 'YYYY-MM-DD' );
        }
    } );

И вы бы использовали его вот так на моем компоненте (на входе есть календарная система, которая возвращает мою дату в удобочитаемом формате)

<div class="required field">
        <label>Start date</label>
         <div class="ui calendar">
                 <div class="ui input left icon">
                      <i class="calendar icon"></i>
                      <input v-model="section.start | formatDate" type="text">
                 </div>
         </div>
</div>

Я бы рекомендовал прочитать сообщение @ yyx990803 здесь: https://github.com/vuejs/vue/issues/2756, где он обсуждает двусторонние фильтры для v-model . Кроме того, может быть лучше задать такие вопросы, как здесь: http://forum.vuejs.org/

Я пропустил пост, о котором вы говорите, сейчас посмотрю, спасибо;)

Привет,
Сомневаюсь в новых хуках жизненного цикла.
Если я хочу зарегистрировать обработчик событий при монтировании и отменить его регистрацию перед размонтированием, как мне заставить его работать? Добавить проверки и логику в хуки created и beforeDestroy?
В Vue 1.x я бы использовал прикрепленные и отсоединенные хуки.
Но в версии 2.0 есть навесной крючок, а вот отключаемый - нет. Немного не соответствует ощущениям.
Есть ли причина, по которой не предусмотрен крючок для размонтирования?

@ f15gdsy mounted соответствует destroyed . В 2.0 нет встречных частей attached / detatched - вам нужно выполнить внутреннюю проверку самостоятельно. Если ваши события не интересуют внутреннее / внешнее пространство, тогда подходящие места для этого - mounted и beforeDestroy .

При использовании в пользовательском компоненте v-on теперь слушает только пользовательские события $, генерируемые этим компонентом. (больше не слушает события DOM)

Возможно, я пропустил здесь несколько постов, но какое дизайнерское решение стоит за этим?
Это сделало бы привязку простых событий щелчка к компонентам очень подробным.

1.0:

<foo @click="bar"></foo>

2.0:

<div @click=bar>
  <foo></foo>
<div>

@fnlctrl , используйте собственный модификатор: @click.native="bar" .

@ miljan-aleksic Большое спасибо! Думаю, этот модификатор нужно добавить к Directives -> v-on -> modifiers в этом выпуске

Могу ли я использовать Koa (1.x или 2.x) в качестве сервера? Есть ли проблемы на vue-server-renderer с Коа?

@ yyx990803

import Vue from 'vue'

Vue.component('expanding', {
  functional: true,
  render (createElement, { children }) {
    const data = {
      props: {
        name: 'expanding',
      },
      on: {
        beforeEnter ($el) {
          $el.classList.add('collapse')
          console.log('beforeEnter')
        },
        enter ($el) {
          $el.classList.remove('collapse')
          $el.classList.add('collapsing')
          $el.style.height = `${$el.scrollHeight}px`
          console.log('enter')
        },
        afterEnter ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse', 'in')
          console.log('afterEnter')
        },
        beforeLeave ($el) {
          $el.classList.add('collapsing')
          $el.classList.remove('collapse', 'in')
          $el.style.height = 0
          console.log('beforeLeave')
        },
        leave ($el) {
          console.log('leave')
        },
        afterLeave ($el) {
          $el.classList.remove('collapsing')
          $el.classList.add('collapse')
          $el.style.display = 'none'
          console.log('afterLeave')
        }
      }
    }
    return createElement('transition', data, children)
  }
})

        <a href="#" :aria-expanded="showItem ? 'true' : 'false'" @click="showItem = !showItem">
          <span class="icon is-small"><i class="fa fa-table"></i></span>
          Tables
          <span class="icon is-small is-angle"><i class="fa fa-angle-down"></i></span>
        </a>
        <expanding appear="true">
          <ul v-show="showItem">
            <li>
              <router-link to="/tables/basic">Basic</router-link>
            </li>
            <li>
              <router-link to="/tables/handsontable">Handsontable</router-link>
            </li>
          </ul>
        </expanding>

Почему бы не вызвать ловушку ввода?

@fundon Вы должны задать вопрос на форуме или в чате gitter

Блокировка этой темы, потому что:

1. Сейчас мы находимся в замороженном состоянии API в RC, поэтому этот документ больше не будет обновляться.
2. Слишком много людей используют это как общую ветку часто задаваемых вопросов, а это не то, для чего она предназначена.

Если у вас есть ошибка, пожалуйста, откройте отдельную проблему, следуя руководству по сообщению о проблемах, если у вас есть вопросы, используйте форум или gitter.

Обновление : более полный и подробный список изменений в 2.0 см. В новом руководстве по миграции .