Vue: 2.0 Changements

Je viens de voir que certaines fonctionnalités ne seront disponibles que dans la version autonome . Cela signifie-t-il que cette version et la version NPM sont très différentes ?

@rekateka 2.0 signifie build autonome (compilateur + runtime). L'exportation par défaut du package NPM sera uniquement l'exécution, car si vous installez à partir de NPM, vous pré-compilez probablement les modèles avec un outil de génération.

Merci, @yyx990803. J'ai encore quelques questions concernant le compilateur et d'autres fonctionnalités, mais j'ai utilisé le forum pour cela.

Y a-t-il des modifications inquiétantes apportées aux documents que je devrais examiner par hasard ? Bon travail! Continue comme ça mec. Vous redéfinissez le développement Web. Merci!

Puis-je obtenir this.arg de ma directive ?

Je vois que vnode.data.directives a arg , mais quand j'ai deux directives ou plus, je ne peux pas connaître le 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">

Dois-je utiliser forEach ? Merci!

@banricho bon point, ça a été oublié ! Voir la signature de fonction de directive mise à jour.

Tout d'abord, désolé car je ne suis pas tout à fait sûr que pourrais-je poser ce problème ici, et j'ai quelques exigences à dire.
L'exigence est que j'espère pouvoir concevoir l'utilisation de mon composant comme ceci

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

J'espère que les enfants peuvent être une sorte d'arguments, pas seulement une limite d'attributs
Pour l'instant je peux faire un composant, l'utilisation comme

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

Mais je pense que ce n'est pas tout à fait bon, j'espère qu'il peut aimer celui que j'ai fait avant dans React coverflow

@andyyou - cette question est probablement mieux postée sur le forum, car ce n'est pas un problème, ni une suggestion claire, ni une aide réelle à ce problème.

http://forum.vuejs.org/

Si vous découvrez que vos besoins ne peuvent pas être satisfaits avec Vue dans votre fil de discussion, vous pouvez ouvrir un nouveau problème ici.

Scott

@smolinari Merci

"Mais pour les cas plus complexes, il est recommandé d'introduire une couche de gestion d'état dédiée à l'aide de Vuex." Cela semble impliquer que l'état devrait être utilisé sur les événements. Je les vois comme complètement séparés - un événement est un moment dans le temps, alors que l'état ne change pas. Vous pourriez dire que vous pourriez regarder l'état, mais cela ne traduit pas non plus un moment spécifique, mais à la place à chaque fois que quelque chose change. Je suis intéressé par le sens de cette recommandation.

@jrenton Généralement, nous pouvons considérer le système d'événements simplement comme un composant A disant au composant B de changer son état, ou A disant à B de faire autre chose.
Ainsi, pour le premier cas, nous pouvons utiliser la gestion d'état (gérer un état partagé pour A et B) au lieu d'utiliser un système d'événements pour laisser A dire à B de changer d'état.
Pour le deuxième cas, je pense qu'il peut être assez bien géré avec l'approche « bus événementiel ».

@jrenton au lieu d'une soupe de composants qui se parlent, Vuex suggère un canal unique pour que les composants expriment des "intentions" avec des actions et enregistrent des "faits" avec des mutations.

J'utilise Twig avec Vue.

Jusqu'à présent (vue 1.0), j'ai transmis des données à mes composants comme ceci :

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

(Notez que {{ et }} sont des balises twig - pour vue, j'ai utilisé des délimiteurs personnalisés ${ et } )

Si je comprends bien les choses, dans Vue 2.0, je devrais le faire comme ceci :

<my-component :data=" '{{ DATA }}' "></my-component>
à droite?

@gholol non c'est juste

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

En fait, il semble que votre ancienne utilisation ne devrait pas fonctionner en premier lieu.

Bon ça a bien fonctionné...

Comme je l'ai dit, les données proviennent du moteur de modélisation de brindilles. Maintenant, dans Vue 2.0, cela ne fonctionne pas. J'ai essayé de le transmettre comme vous l'avez dit (sans apostrophes simples) mais la propriété des données n'est pas définie.

Erreur : SyntaxError : } manquant après la liste des propriétés

EDIT : ça marche, j'ai oublié de préciser que la variable DATA est une chaîne

@jrenton Mon idée et ma motivation sont assez simples, il semble que Vue n'aime pas React qui nous oblige à utiliser JSX. Nous pouvons choisir beaucoup de template .

J'espère pouvoir utiliser la syntaxe des éléments enfants comme paramètre (arguments) passer des arguments au parent car dans certains langages de modèles comme slim si vous avez un peu d'attributs ou si vous dites que le nom de l'attr est assez long, nous devons mettre toutes les choses en une seule ligne. il est plus facile de faire du code d'une ligne de plus de 80 caractères.

@yyx990803 Je me sens aventureux aujourd'hui, <input type="text" name="account[categories][{{ category.id }}]"> dans 2.0 ?

Les modèles en ligne ES6 fonctionnent dans des expressions de liaison :

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

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

Si c'est la seule façon de faire fonctionner cela sur 2.0, alors cela ne me dérange pas de dire que c'est une régression dans la jolie syntaxe 1.0 à laquelle nous nous sommes habitués - oui, je sais que c'est juste ES2015.

Je suppose que l'interpolation a été supprimée pour des raisons de performances ? J'espère juste que ça vaut la syntaxe plus laide.

@oskarkrawczyk Je suppose que vous voulez vous retrouver avec quelque chose comme name="account[categories][fruits]" dans votre DOM, car c'est ce que votre expression rendrait.

La version 2.0 (et la 1.0 correcte, en fait) sera :name=" 'account[categories][' + category.id + ']' " .

@simplesmiler Compris. Je pense que {{ }} m'a un peu gâté.

@yyx990803 puis-je insérer dynamiquement un composant, comme celui-ci ?

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

Comment puis-je lier quelques valeurs pour un attribut qui dépendent de l'expression ? Par example:

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

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

J'attends le prochain résultat :

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

@nervgh ce n'est pas le bon endroit pour poser cette question.
Utilisez l'expression ternaire, v-bind:placeholder="flag ? 'test' : 'test2'" .

@simplesmiler , merci pour votre réponse. J'essaie de dire que _Object-Syntax_ sera utile dans ces cas, mais cela ne fonctionne pas comme prévu.

La syntaxe de l'objet class , et pour les composants, il n'y aurait aucun moyen de détecter du côté enfant si vous vouliez envoyer une liste de chaînes ou un objet approprié.

Re : .once et .sync sont obsolètes.

Cela ne brise-t-il pas les modèles de conception vraiment courants ?

Je ne vois pas comment vous pourriez avoir des composants simples pour gérer les champs de formulaire sans ceux-ci.

J'ai des composants simples pour différents types de champs de formulaire, par exemple voici mon modèle de composant "textbox":

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

... et aussi un composant plus complexe pour les listes qui fournit une interface utilisateur pour ajouter et supprimer des éléments de tableaux dans la structure de données

Ensuite, j'utilise ces composants, par exemple comme ceci :

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

Remarque : Tous ces composants ont deux accessoires : data et type . data est le nœud dans la structure de données en cours d'édition dont le composant est responsable de fournir une interface utilisateur pour l'édition, et type est le nœud dans la structure de données (massive, statique) qui contient les types /hiérarchie des champs.

Comment des trucs comme ça peuvent-ils fonctionner sans .sync ?

Il me semble que cela compliquerait gravement les choses de créer une sorte de système de messagerie entre ces composants où les sous-composants peuvent en quelque sorte communiquer au parent de quel sous-composant il s'agit, et le parent peut alors déterminer quelle partie de ses données structure à modifier.

J'espère vraiment qu'il me manque quelque chose... car il semble que vous disiez que l'utilisation de composants pour créer des éditeurs pour des parties de votre structure de données est un anti-modèle. Quoi ? Jusqu'à présent, c'est la seule chose pour laquelle j'ai utilisé Vue. Je suppose que vous pensez que la suppression de cette fonctionnalité encouragera les gens à écrire un code plus propre. Peut-être que cela aura cet effet sur certaines personnes, mais beaucoup de gens écriront du code beaucoup plus méchant pour contourner cette limitation. Modifier l'état est la seule chose utile que font les ordinateurs. Veuillez continuer à rendre cela plus facile.

@JasonWoof v-model en 2.0 peut fonctionner sur des composants personnalisés. Le composant doit simplement :

1. exposer un accessoire nommé value
2. émettre un événement input lorsque la valeur doit être synchronisée avec le parent, par exemple this.$emit('input', value)

Voir exemple .

@yyx990803 Merci pour l'explication et le lien. Maintenant, je suis juste bloqué sur :

Pourquoi supprimer .sync ?

Je ne vois pas l'avantage, seulement les inconvénients. L'exemple que vous avez lié montre que vous pouvez obtenir la même chose avec :selected.sync ou v-model . Je ne vois que des inconvénients pour la méthode v-model :

1. Il nécessite un important passe-partout du côté des sous-composants, est plus compliqué, plus à apprendre, etc.
2. Vous ne pouvez transmettre qu'une seule valeur avec v-model, mais vous pouvez avoir plusieurs accessoires .sync

Je ne vois pas en quoi le passage au modèle v rend quelque chose de plus clair/plus propre. Dans les deux cas, la seule indication dans le parent que le composant enfant peut facilement modifier l'état du parent est la syntaxe de la prop dans le modèle. Je dirais même que .sync est plus clair.

L'autre chose est que lorsque vous transmettez des objets/tableaux/etc en tant qu'accessoires, ils sont mutables à partir du composant enfant. Vous ne pouvez donc pas empêcher les programmeurs de changer l'état des composants enfants dans ce cas (ce qui, je suppose, est très courant.) Il me semble donc que vous introduisez une pierre d'achoppement en supprimant ce qui le rend si le passage de valeurs de chaîne fonctionne de la même manière que le passage de valeurs d'objet. .sync rend mon code plus simple et plus cohérent en ayant toujours mes props "data" accessibles en écriture du côté enfant, quel que soit le type de données.

Je suis nouveau sur Vue.js (il y a 3 jours) mais d'après ce que je peux voir jusqu'à présent, Vue.js est précieux principalement pour deux choses :

1. manipulation de dom facile avec des modèles
2. propagation automatique des modifications de valeurs/données, y compris le déclenchement de modifications de modèles

C'est du moins ce que j'ai découvert jusqu'à présent.

Il me semble que la suppression de .sync rend difficile le fait que Vue.js fasse systématiquement la seconde.

@JasonWoof parce que les effets secondaires explicites et implicites en dehors de la portée des composants font toute la différence dans la maintenabilité à long terme.

... et bien que l'on puisse soutenir que les gens devraient simplement apprendre quand ne pas utiliser .sync , notre expérience jusqu'à présent est différente. les gens ont tendance à trop se fier à cela et à créer du code qu'ils peuvent difficilement déboguer plus tard.

il s'agit donc d'une décision de conception pour forcer les gens à le faire dès le début.

un exemple:

• Nous synchronisons une valeur name entre un parent et un enfant. Tout est bien.
• nous décidons _'hey, quand cette valeur change, nous devons faire quelque chose dans le parent !'_
• Donc, nous créons une fonction watch . Agréable!
• Plus tard, nous réalisons que l'observateur semble tirer quand nous ne le voulons pas. Mais nous ne pouvons pas vraiment dire pourquoi, car nous ne pouvons pas vraiment mettre console.log() n'importe où pour retracer le comportement.
• Après de longues réflexions, nous réalisons que nous voulons _vraiment_ que _quelque chose_ se produise uniquement lorsque la valeur est modifiée chez le parent, pas chez l'enfant ou le "grand-parent".
• Nous essayons maintenant de trouver un moyen de différencier ces scénarios dans la fonction watch une manière ou d'une autre.
• Seulement pour se rendre compte que cela rend une chose simple très compliquée
• et à la fin, quelqu'un nous dit de supprimer la synchronisation, nous jetons donc tout et utilisons un accessoire à sens unique et un événement émis pour gérer la situation - le code devient plus simple et plus explicite, il est donc simple de raisonner sur comment et lorsque les données circulent et qu'il devient plus facile de les déboguer. Le bug est trouvé rapidement et nous pouvons passer à autre chose.

... et cela devient encore plus fou lorsque vous synchronisez plus d'un niveau en profondeur.

C'est un (anti-)modèle que nous avons vu maintes et maintes fois sur les forums et dans le chat gitter.

Supprimer .sync oblige les gens à écrire un code clair, explicite et maintenable dès le départ, car leur code ne restera pas assez simple pour .sync très longtemps, la plupart du temps.

D'ACCORD. Merci d'avoir expliqué.

Il est bon d'entendre quel problème vous essayez de résoudre.

Je doute sérieusement que cela aide cependant... Faites en sorte que les gens ne puissent pas facilement casser les modèles que vous aimez et que les gens fassent des choses bien pires pour contourner les limitations.

Cela me rappelle beaucoup d'abstraction. Les abstractions nous causent tant d'ennuis. Ils rendent le code difficile à lire, difficile à déboguer, etc... Mais vous ne pouvez pas résoudre ce problème en supprimant la possibilité de faire des abstractions... c'est à peu près ce qui rend la programmation possible/utile. La solution à cela n'est pas au niveau de la langue ou du cadre, mais dans l'enseignement, le conseil, l'apprentissage. Nous encourageons les gens à ne pas rendre les choses trop abstraites.

Il me semble que vous parlez d'une telle philosophie de conception. Dans de nombreux cas, c'est une excellente philosophie à garder à l'esprit lors du codage. Mais quand elle est imposée comme une limitation, et que le programmeur pense que cette limitation l'empêche de faire ce qu'elle doit faire, alors elle va contourner cela, ce qui entraînera tous les problèmes que vous essayiez d'éviter et pire encore.

Les gens n'arrêteront pas d'essayer de faire muter l'état parent des enfants. Vous ne pouvez pas forcer les gens à ne pas le faire.

Votre chose v-model est suffisamment compliquée pour que je contourne ce problème en passant l'objet/tableau parent et une clé pour que l'enfant puisse le modifier.

Je suppose que ce dernier coup est au cœur de ce que j'essaie de faire passer : je considère (personnellement) le manque de .sync comme un problème, et je le contournerai ou n'utiliserai pas votre framework. Je parie que beaucoup de gens auront la même approche.

Cela va peut-être sans dire, mais cela me met un peu en colère quand les gens essaient de m'imposer des philosophies de conception. Je préférerais de loin construire des choses qui tournent mal et apprendre à ne plus recommencer que d'utiliser des systèmes qui retiennent volontairement le pouvoir de peur de l'utiliser mal.

PS Désolé, je ne peux pas m'en empêcher, un commentaire de plus, alors je vous laisse tranquille. La plupart des programmeurs écrivent du code qu'ils ne peuvent pas déboguer. Cela arrive à chaque programmeur dans chaque langage avec chaque framework. C'est ainsi que les programmeurs deviennent de meilleurs programmeurs : ils font des erreurs, ils font du code qu'ils ne peuvent pas corriger, ils apprennent à écrire les choses différemment à l'avenir. S'il vous plaît, ne simplifiez pas votre framework pour tout le monde dans le but de faire en sorte que les programmeurs qui s'abstiennent dans le coin puissent rendre leur travail un peu plus confus/complexe avant que cela ne devienne un tel gâchis qu'ils ne puissent pas le déboguer.

@JasonWoof cela n'a rien à voir avec "l'abêtissement", et empêcher les utilisateurs des pièges courants / assurer une meilleure maintenabilité fait par définition partie du travail d'un framework. Nous avons pris la décision sur la base d'une expérience de première main en matière de conception, d'utilisation du cadre lui-même et d'observation du comportement des utilisateurs dans divers cas d'utilisation. S'il s'agit d'un anti-modèle, nous découragerons les utilisateurs de l'utiliser et fournirons des conseils sur la solution idiomatique. Vous êtes libre de ne pas être d'accord avec cela en fonction de votre opinion personnelle, mais je trouve vos arguments peu convaincants.

Les gens n'arrêteront pas d'essayer de faire muter l'état parent des enfants. Vous ne pouvez pas forcer les gens à ne pas le faire.

Sûr. Et nous ne les "forcerons" pas, car il peut y avoir des cas extrêmes où cela pourrait encore être nécessaire. Vous pouvez donc toujours accéder à this.$parent , vous pouvez passer $data via un accessoire, etc., mais franchement, cela ne sera pas beaucoup plus pratique que $emit un événement la plupart des temps, ils ne seront donc pas aussi attrayants que le sucre .sync .

De plus, $parent et.al. ne font pas partie du guide officiel, donc les utilisateurs qui les utilisent travaillent activement autour des meilleures pratiques suggérées - ce qu'ils sont libres de faire, mais nous n'encourageons pas ce comportement.

Par conséquent, le framework ne devrait pas encourager un comportement similaire en fournissant du sucre syntaxique « magique » comme .sync si nous pensons qu'une telle fonctionnalité est mal utilisée dans la plupart des scénarios et opposée aux meilleures pratiques que le framework cherche à établir.

Youda a-t-il une version chinoise ? .

A quoi ressemble la compatibilité pour vue-router ?

@roblav96

Certains changements sont nécessaires pour être compatibles, nous espérons mieux intégrer le routeur dans Vue.

@blake-newman

Pouvons-nous créer un modèle standard sur vue-cli ? Je n'arrive pas à faire fonctionner tout ça 😢

@roblav96

Il y en a actuellement, il y a des changements nécessaires avec vue-loader pour le rendre compatible. Actuellement, la version 2.0 ne doit être utilisée qu'à des fins d'expérimentation jusqu'à ce que toutes les autres dépendances pour les applications à grande échelle soient mises à jour.

Existe-t-il un ETA pour les candidats bêta / release ?

@Evertt Alpha est

@blake-newman merci pour cette réponse rapide, concise et complète. Ce sont les meilleurs. :-RÉ

Une solution de contournement pour replace: false en vue 2.0 ?

Bonjour, JSX est-il déjà utilisable ?

@reohjs - Non et je considérerais personnellement cela comme un réel recul pour Vue, s'il prenait en charge JSX.

Scott

@reohjs Dans le stream d'Evan hier soir, il a mentionné que cela pourrait être fait avec un plugin, donc j'imagine qu'une fois que cela entrera en version bêta, il ne faudrait pas longtemps à quelqu'un pour le créer. Je suis content que ce ne soit pas dans le noyau, mais un plugin JSX semble être une excellente idée.

Je suis content que ce ne soit pas dans le noyau

👍 👍 👍 👍

Ouais devrait être un plugin. Cependant, comme nous l'avons vu, les modèles présentent de nombreux avantages pour les composants standard.

La compilation JSX devrait être facile à réaliser avec ce plugin : https://babeljs.io/docs/plugins/transform-react-jsx/

Je pense que la fonction _h remplacerait React.createElement

Que diriez-vous de fournir une interface pour créer des modificateurs de modèle v personnalisés comme moyen de remplacer les filtres bidirectionnels ? Il semble qu'ils soient déjà utilisés pour analyser les entrées utilisateur (par exemple v-model.trim ). Si l'analyse/le formatage est simple et indépendant d'une propriété de données spécifique, l'utilisation d'un modificateur permettrait de réutiliser l'analyse/le formatage avec beaucoup moins de passe-partout qu'en définissant une propriété calculée pour chaque propriété de données individuelle, ou en créant un nouveau composant pour chaque type d'entrée où nous voulons que l'analyse/formatage soit appliqué.

Salut, je travaille actuellement sur un plugin pour prendre en charge gettext dans Vue.js 1.0 et j'ai une directive qui utilise vm.$interpolate .

Je me demande comment migrer mon code vers 2.0 puisque :

• vm.$interpolate sera obsolète
• les directives n'auront plus d'instances dans 2.0

Ou existe-t-il une meilleure approche qu'une directive ?

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

Je lance juste quelques mots depuis que je suis nouveau chez Vue , juste pour dire que je suis heureux de voir la réduction de l'API en général ou des assistants _sous le capot_. JavaScript est déjà vraiment puissant, et avec des propriétés calculées et d'autres fonctionnalités réactives du framework, presque tout peut être réalisé.

Bravo pour cette _prochaine_ version ! ??

@kemar Je ne connais pas très bien gettext, mais j'étendrais simplement Vue.prototype avec une méthode $translate, puis je le ferais

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

La possibilité d'enregistrer des actifs avec une syntaxe de tableau a-t-elle été supprimée de la version 2.0 ? Je ne travaille pas sur l'alpha, je me demande juste si c'est intentionnel ou non.
c'est à dire:

components: [compA, compB, compC]

Je sais que ES6 a un raccourci qui semble similaire, mais il existe certains scénarios où la syntaxe du tableau était utile.

Je vois que vous mentionnez rendering to native interfaces on mobile avec weex et je me demandais à quel point il serait facile de faire parler vue et Nativescript .

Quelque chose de plus similaire à Nativescript pour Vue serait soit Weex, que vous avez mentionné, soit Quasar .

Scott

S'il n'y a plus de dispatch ou broadcast comment un composant enfant générique informera-t-il son parent d'un événement/changement ? Cela ne semble pas correspondre au modèle d'un bus global ou d'une vuex. Le cas d'utilisation que nous utilisons maintenant est un curseur de plage pour les filtres de recherche. Le composant de curseur de plage est générique et est un enfant de plusieurs filtres de recherche différents. Nous utilisons actuellement dispatch lorsqu'un curseur de plage a fini de glisser, alors le parent sait déclencher une recherche en fonction du changement.

Écouteurs en ligne <child @some-event="parentHandler">

Super boulot les gars.

De mon point de vue, tous les changements indiquent que la meilleure approche est de créer votre arborescence de composants basée uniquement sur un "flux à sens unique", qui est tellement plus simple et facile à déboguer et à maintenir.

Sans cela, la véracité de vos données serait inversement proportionnelle à votre distance par rapport au composant le plus élevé.

Je veux juste dire que :

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

Me rend heureux

Est-il prévu que d'autres seront ajoutés à cette liste avant la sortie de la 2.0 ? Juste curieux car le problème est toujours ouvert.

@zephraph Oui, nous mettons continuellement à jour la liste au fur et à mesure que nous mettons à jour l'API. 😃 Rien d'énorme jusqu'à présent, mais des changements de rupture occasionnels par rapport aux alphas précédents.

J'ai un cas, j'ai utilisé la distribution d'événements dans le passé et où je suis bloqué avec vuex: le composant parent a une liste de composants enfants et l'enfant distribuait un événement lorsque sa valeur a changé afin que le parent puisse faire quelque chose comme une réaction de ce changement.
Maintenant, j'ai essayé d'avoir un tableau des valeurs enfants dans le magasin vuex. Le problème est de savoir comment le composant enfant sait dans le getter et dans l'action quel élément de ce tableau il doit mettre à jour. Autant que je sache, vuex ne fournit pas de fonctionnalité pour obtenir ou déclencher dynamiquement une mutation d'une valeur, ou est-ce que je me trompe?
Quelle serait la meilleure façon de gérer ce cas sans envoi d'événement ?

Avec la suppression de $broadcast , comment diriez-vous à un enfant direct de faire quelque chose lorsqu'une chose particulière se produit ? Ce serait un scénario où aucune donnée n'a réellement changé, donc les accessoires réactifs ne semblent pas s'adapter.

Je pourrais utiliser un accessoire et transmettre un horodatage ou des données aléatoires et regarder cet accessoire chez l'enfant, mais cela semble étrange. Un bus d'événements global nécessiterait la génération d'ID uniques afin que l'enfant ne réagisse qu'aux événements de son parent et à aucune autre instance du composant parent.

Il y a $emit dans un enfant qu'un parent peut écouter à l'aide d'un écouteur en ligne, y a-t-il quelque chose pour l'inverse ?

Je pourrais transmettre une instance d'un émetteur via un accessoire, puis emmiter.on dans l'enfant, est-ce que cela semble terrible ?

Les actions

// 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>

Si vos articles n'ont pas d'identifiants localement uniques, vous pouvez en générer un lorsque l'article est créé ou reçu de l'API. La plupart du temps, cuid est assez bon pour ça.

@fergaldoyle car le parent sait toujours qu'il s'agit d'enfants, vous pouvez mettre v-ref:some-child sur l'enfant pour obtenir la référence à la machine virtuelle de l'enfant, puis soit $emit dessus, soit simplement appeler une méthode directement avec this.$refs.someChild.<methodName>(...) .

Cependant, je conseillerais de repenser l'architecture dans ce cas, car les événements qui se déroulent rendent le composant vraiment difficile à raisonner.

Je jouais avec vuejs 2 et j'ai remarqué pour Snabbdom si tu passes

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

À la fonction de rendu que vous obtenez

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

Mais dans vuejs vous obtenez

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

Existe-t-il un moyen de modifier le contenu du texte (à l'intérieur de <h1> ) ?

@dubcanada pourquoi ne pas simplement les transmettre comme des enfants?

Exact, cela aurait du sens. Merci

Salut. J'ai une question sur le système de transition dans Vue 2.0 ou plutôt une proposition car je ne le vois pas dans les plans de Vue 2.0. Dans Vue 1.0, j'ai souvent rencontré le besoin de détecter quand une transition/animation que j'ai configurée se terminerait. Maintenant, je le fais en utilisant setTimeout, mais c'est une manière très bidon et moche, nous pouvons tous être d'accord. Ma question est donc la suivante : sera-t-il dans Vue 2.0 un moyen de détecter la fin de la transition CSS lorsque nous utiliserons une transition combinée avec v-show/v-if, éventuellement via un événement ?

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

je serais très heureux de voir quelque chose comme ça dans la prochaine version de Vue :) merci de m'avoir écouté

@sqal, vous pouvez le faire avec des crochets de transition : https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

@dubcanada, il sera pris en charge dans la prochaine version (en omettant les données lors de la création de l'élément)

Merci @fergaldoyle et @simplesmiler pour votre indice à émettre.

Je n'étais pas au courant, le parent est capable d'écouter les événements qui ont été émis par l'enfant. Bien sûr, il est alors plus logique d'écouter cet événement non bouillonnant.

Salut tout le monde. Un peu de contexte : nous travaillons avec webgl et j'aimerais faire quelques interfaces sur une surface 3D. Cela signifie que nous devons restituer une interface vers un canevas, par exemple, puis convertir le contenu du canevas en une texture.

J'ai travaillé avec Angular, React et Vue et pour moi, Vue a tout simplement le plus de sens ! En lisant à propos de React, je suis tombé sur le projet React-Canvas. La chose intéressante est qu'au lieu de transformer le DOM virtuel en nœuds DOM réels, ils le dessinent sur un canevas.

Parce que Vue 2.0 utilise également un DOM virtuel, je me demandais si quelque chose comme ça pouvait aussi être fait ?

Bonjour,

Juste quelques éclaircissements sur la suppression de .sync et à quoi pourrait ressembler un workflow générique pour la gestion des accessoires sur un composant générique.

donc, allant de
<component :value.sync="some.value"></component>
à
<component :value="some.value" @update="updateSomeValue"></component>

Quelle est la méthode recommandée pour suivre l'accessoire value ?
Dans le cas le plus élémentaire, il semble

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

Mais, cela dépend sûrement du composant parent qui renvoie cette valeur à l'accessoire, donc lorsque le composant la récupère, il reflète le changement le plus récent ...

Cela signifie-t-il que nous devons maintenant faire quelque chose comme ceci :

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);
        }
    }
}

Cela semble être beaucoup de passe-partout pour gérer la transmission (et la modification) d'une valeur, notifier le parent que la valeur a changé et suivre le changement en interne, au cas où le changement ne serait pas propagé par le parent.

Ou est-ce que je manque un peu de réactivité magique de vue ici?

De plus, il est possible que s'il y a beaucoup d'accessoires à gérer, cela puisse devenir assez compliqué.
Je me voyais presque travailler sur un composant wrapper, où les enfants accèdent à this.$parent.value afin de muter directement, et le composant wrapper ne gère que les accessoires/calculés/montres

@Towerful, qu'entendez-vous exactement par "suivre la valeur" ? Et pourquoi voulez-vous un style setter ( this._value = newValue ) au lieu d'un this.$emit('value-updated', newValue) explicite ?

Le pouvoir du flux unidirectionnel est que le parent peut décider de ne pas appliquer la modification demandée par l'enfant, ou peut marquer l'enfant comme « en attente » et appliquer la modification plus tard (par exemple après avoir vérifié auprès du serveur).

@simplesmiler utilisant une propriété calculée vous permet de la lier dans le modèle, non ? vous pouvez donc utiliser v-model .
Et le fait d'avoir le setter & getter contenu à 1 endroit permet d'aller facilement voir la fonctionnalité lorsque la valeur est mise à jour, par opposition à avoir différentes manières d'accéder à la valeur et de muter la valeur dans le composant, et dispersées dans tout le code.
Si vous utilisez la manière explicite dans un modèle et que vous n'utilisez pas de setters, il semble que l'objet methods va être encombré de méthodes de type updateValue pour le modèle, par opposition aux méthodes réelles.

Je suppose que cela s'applique lorsque l'utilisateur sélectionne une option dans un composant, et le composant s'appuie sur cette valeur pour afficher ce qui est sélectionné.
Vous comptez sur le composant parent qui le renvoie au composant pour qu'il puisse le faire.
A moins que, lorsque l'utilisateur sélectionne une option, vous déclenchiez manuellement la mise à jour de l'affichage des composants. Ce qui semble s'éloigner de la réactivité de Vue.
Donc, avoir une valeur interne pour suivre ce qu'elle « devrait être », faire réagir le modèle à cela. Utilisez des setters/getters pour envelopper la propriété afin de suivre les modifications internes et déclencher des événements externes, et une surveillance de la propriété pour mettre à jour la valeur interne lorsqu'elle est modifiée en externe.

Peut-être que j'ai juste du mal à comprendre la nouvelle façon de le faire.

@Towerful - Vous n'êtes pas le seul....

Scott

@Towerful :

Il me semble que ce que vous décrivez sont essentiellement des composants qui agissent comme des entrées avec un v-model : l'utilisateur modifie une valeur dans l'interface utilisateur et vous souhaitez que ce changement se reflète immédiatement dans les données liées.

Pour ces types de composants, vous pouvez utiliser v-model sur les composants en 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
}

Cela rend l'interface aux éléments <input> réels et aux composants d'entrée personnalisés essentiellement identiques, et une liaison bidirectionnelle.

Pour les composants plus complexes qui reçoivent plusieurs accessoires (et ne sont pas de simples entrées personnalisées, mais plus abstraits), nous déconseillons d'utiliser .sync car il devient difficile de raisonner dans la plupart des situations.

Le parent doit décider quoi faire avec une valeur qu'il reçoit de l'enfant, ses données ne doivent pas être implicitement modifiées comme le fait .sync .

Pouvez-vous fournir un exemple qui n'est _pas_ solvabel avec l'approche du modèle v ci-dessus et qui bénéficie toujours de l'utilisation de .sync ? Cela peut être une meilleure base de discussion que la théorie abstraite.

Oh, comment j'ai raté ça ?! C'est définitivement là dans l'OP, et il y a même une discussion à ce sujet il y a quelques commentaires ! Maintenant, je me sens un peu stupide.
Le message d'origine pourrait-il être mis à jour pour qu'il soit un peu plus clair que v-model peut être utilisé sur un composant ?
@LinusBorg Du haut de ma tête, je ne peux pas penser à un cas où v-model sur un composant ne fonctionnerait pas. J'ai raté cette partie dans le message d'origine.
Même pour les composants d'objets complexes, il s'agirait simplement d'imbriquer des composants. Et cela renforce les composants de responsabilité unique.
C'est beaucoup plus logique :)

@Towerful

Re : utiliser v-model . Le fait est que v-model est synchrone (d'une certaine manière), tandis que le flux de données inter-composants est intrinsèquement asynchrone en raison de la file d'attente de l'observateur ( demo ). J'ai vu cela dérouter beaucoup de gens. Le flux à sens unique rend simplement plus explicite le fait que les accessoires ne sont pas synchrones et vous oblige à ne pas compter sur leur synchronisme (c'est ce que vous essayez de contourner).

Re: méthodes encombrées. Pour les cas simples, vous pouvez toujours faire @value-updated="value = $arguments[0]" . Pour les cas compliqués, c'est une bonne chose d'avoir une méthode, où vous pouvez ajuster l'état pour le garder cohérent (par exemple, déclencher les mises à jour manuellement). Segway jusqu'au point suivant.

Re: s'éloigner de la réactivité. Je ne suis pas d'accord avec cette affirmation. Pour les cas simples, vous n'avez pas besoin de magie pour que l'enfant récupère la valeur, mise à jour par le value-updated="value = $arguments[0]" .

Pour les cas compliqués, avec les accessoires .sync vous devrez utiliser watch , mais explicite watch ne fait pas vraiment partie de la réactivité. C'est une trappe de sortie, où vous déclenchez vos mises à jour manuelles qui ne peuvent pas être exprimées comme calculées. Et ce n'est pas le bon, car il ne peut pas réagir aux changements de manière synchrone, comme le calcul le peut. C'est pourquoi, lorsque vous utilisez massivement watch , vous pouvez constater que vos mises à jour de données prennent quelques « ticks » pour se propager. Si vous êtes déjà tombé sur des nextTick directement imbriqués, vous savez de quoi je parle.

Maintenant, le gestionnaire -updated fournit une meilleure trappe d'échappement, permettant aux modifications de modèle compliquées d'être appliquées de manière synchrone (ou simultanément de manière asynchrone) après que l'enfant exprime l'intention, en s'assurant que l'enfant recevra les valeurs mises à jour dans la prochaine tick (ou ne recevoir un état incohérent).

@yyx990803 Pourrions-nous implémenter un moyen d'écouter $emits, de la même manière que nous avions des événements pour $dispatch et $broadcast dans vuejs1 ?

Se sent plus vuejs-esque, quelque chose du genre de ceci (un "on" ou "écouter") :

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
    }
  }
})

Cela s'attacherait fondamentalement automatiquement au bus global.

Les bus d'événements ne sont pas un modèle que nous voulons encourager - ils ne sont utiles que dans certains cas extrêmes. Généralement, un modèle de magasin, comme vuex, est préféré.

Implémenter une API qui facilite l'utilisation d'un bus et se sent "officiellement prise en charge" serait un mauvais signal.

En regardant votre exemple, si vous stockiez la quantité dans un magasin accessible par les deux composants, aucun événement ne serait nécessaire. La propriété calculée dans le composant container serait mise à jour automatiquement.

Exemple de code simple sans utiliser une vraie solution de magasin comme 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
    }
  }
})

Je dirais que l'idée générale de vue2 est de rendre plus difficile de se tirer dessus
dans le pied.

Le dimanche 3 juillet 2016 à 11h24, Thorsten Lünborg [email protected]
a écrit:

Les bus d'événement ne sont pas un modèle que nous voulons encourager - c'est seulement
utile certains cas de bord. Généralement, un modèle de magasin, comme vuex, est préféré.

Implémenter une API qui facilite l'utilisation d'un bus et se sent "officiellement
pris en charge" serait le mauvais signal.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -230158828, ou couper le son
le fil
https://github.com/notifications/unsubscribe/AACoukCpCgYlDbVej_w_h4NEhQ-imYHBks5qR9QwgaJpZM4IedHC
.

Les @kharysharpe $emit sont destinées à être écoutées avec v-on sur l'instance enfant. Cela présente également l'avantage supplémentaire de pouvoir puiser dans le contexte d'origine de l'endroit où l'instance est utilisée :

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

Y a-t-il une date pour la sortie 2.0 ? Je suis assez excité par les changements. Félicitations!
Je pense utiliser Vue 2.0 + Redux.

@Sendoshi Pas encore de date sur la version finale, mais la bêta pourrait être dans une semaine. 😄 Vuex 2.0 est également développé parallèlement et il comportera non seulement une API beaucoup plus simple que vuex actuelle, mais s'intégrera également dans l'écosystème Vue beaucoup plus bien que redux.

Vuex 2.0 est également développé parallèlement et il comportera non seulement une API beaucoup plus simple que vuex actuelle, mais s'intégrera également dans l'écosystème Vue beaucoup plus bien que redux.

@chrisvfritz C'est fantastique à entendre ! J'ai toujours pensé que l'API actuelle est un peu trop compliquée et inutilement. J'ai fini par devoir faire des choses comme ça pour compenser :

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
}, {})

Quid de la roadmap de vue 2 et vuex 2. Est-il prévu de les sortir ensemble ou l'un avant l'autre et qu'en est-il des compatibilités des différentes versions ?

En ce qui concerne la question ci-dessus, quel est l'état de vue-router - ?

@gwildu Ils seront probablement publiés un peu ensemble et Vuex 2.0 ne prendra en charge que Vue 2.0. Pre 2.0 Vuex bénéficiera toujours du support jusqu'à ce que Vue 1.x ne soit plus pris en charge.

@Uninen Vue Router recevra un peu d'amour ensuite, avant la sortie de Vue 2.0.

Merci pour l' info @chrisvfritz :)

@chrisvfritz @Uninen correction : Vuex 2.0 fonctionne également pour Vue 1.x.

La prochaine version majeure de vue-router ne prendra en charge que Vue 2.x.

Runtime only build : puisqu'il n'inclut pas le compilateur, vous devez soit des modèles pré-compilés dans une étape de compilation, soit des fonctions de rendu écrites manuellement.

Existe-t-il / y aura-t-il un moyen de précompiler des modèles sans utiliser vueify/vue-loader et les fichiers .vue ? Dans le cas contraire, serait - il une bonne idée d'avoir un plugin babel pour transformer template: propriétés à render fonctions dans les composants?

Après la mise à niveau vers la version 2.0, les fonctionnalités obsolètes peuvent-elles toujours être utilisées. Pouvez-vous d'abord passer à la version 2.0, puis modifier progressivement les fonctionnalités obsolètes ?

Sera-t-il possible de créer un composant terminal, maintenant que elementDirective n'est plus ?

Comme mentionné:

v-model ne se soucie plus de la valeur en ligne initiale. Il traitera toujours les données d'instance Vue comme la source de vérité.

Considérez que

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

Comment puis-je gérer la case à cocher avec des tableaux entre des composants personnalisés ?

_Mise à jour 1:_
Résolu. Transférez la prop type="checkbox" au composant enfant dans le composant parent.

<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>

Ensuite, vous pouvez obtenir une valeur en ligne via {props: [ 'value' ]} .
Émettez un événement change au composant parent pour indiquer que la valeur a changé.

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

C'est parce que le compilateur compile la directive v-model fonction de son type . Et le compilateur générera la prop checked et lui liera un événement change .

_Mise à jour 2:_
Cependant, le crochet de cycle de vie updated ne se déclenche pas car v-model modifie directement l'attribut checked (cela signifie que vous ne pouvez pas obtenir un événement change d'un composant de case à cocher html natif en modifiant la valeur de v-model ).
Donc, @yyx990803 , pouvez-vous déclencher un événement change après des modifications de v-model ?

@YunSun-CN La seule façon dont j'ai pu contourner votre problème était d'ajouter une propriété spécifique à la valeur, ala val, et de l'utiliser pour définir la valeur réelle, puis d'émettre simplement des modifications à l'entrée du modèle v ' un événement.

@johnleider J'ai écrit une directive personnalisée pour simuler ce que fait v-model .
Soit dit en passant, vous devez générer des modèles de manière stricte, non seulement en vérifiant la prop type mais en vérifiant le tagName de l'élément. Sinon, un autre composant personnalisé avec type prop peut écraser son comportement de modèle par défaut.

Salut. Connaît-on une date de sortie ?

@thanosalexander Nous n'avons pas encore décidé de date, non. Nous venons d'introduire des changements majeurs dans le système de transition avec la 2.0.0-bet.2, qui doivent être testés de manière approfondie. Il faudra donc encore quelques semaines avant que nous puissions penser à une sortie, à mon avis.

ok..j'irai avec ça alors ..je ne pense pas que le pas vers l'écurie sera trop grand ! Je vous remercie

Et les docs ? L'une des raisons pour lesquelles Vue a été adopté tôt était la documentation et c'est la seule raison qui me retient maintenant avec la v2. J'ai vu le problème de suivi de la documentation, mais je ne vois pas que c'est bientôt terminé. J'ignore probablement tellement de choses qui se passent sous le capot, raison pour laquelle la question se pose :)

Envisagez-vous d'implémenter le mode de transition en dehors de la commutation de composants dans 2.0 ?
https://github.com/vuejs/Discussion/issues/156

@miljan-aleksic Docs sera prêt lorsque 2.0 sera officiellement publié. Nous sommes encore en bêta. ;)

D'ici là, vous pouvez suivre l'avancement de la documentation ici (ou même contribuer)

@aristidesfl Déjà fait. ??

@miljan-aleksic En plus de ce que @LinusBorg a mentionné, la plupart du nouveau guide est déjà terminé et vous pouvez même lire la source ici si vous le souhaitez. Gardez cependant à l'esprit qu'au moment de la rédaction, il n'a pas été entièrement mis à jour pour refléter les changements dans la version bêta.2 , une évaluation importante par les pairs est encore à venir et d'autres modifications mineures de l'API sont envisagées. Donc, à moins que vous ne vouliez aider à corriger les fautes de frappe et à améliorer les explications, je vous recommande d'attendre la publication officielle (peut-être au stade RC).

Nous convenons également que l'excellente documentation est une partie vitale de Vue. Même Dan Abramov de l'équipe React adore nos docs. 😄 C'est pourquoi c'est l'un de mes objectifs personnels que les docs 2.0 soient _encore meilleurs_. En attendant cependant...

Pour tous ceux qui souhaitent en savoir plus tôt sur la 2.0, je recommanderais les tests unitaires de fonctionnalités comme la ressource la plus à jour disponible.

C'est l'une de mes principales ressources pour rédiger de la documentation et elles sont généralement assez lisibles si vous connaissez bien Jasmine.

Merci @chrisvfritz , information très utile. Je vais essayer les nouveaux documents, en tenant compte de son WIP, et des commentaires si nécessaire. Il est temps de passer au sérieux avec Vue 2.0 ;)

createElement dans la fonction de rendu utilisant on ne semble pas gérer les tableaux (comme le fait snabbdom) existe-t-il un moyen de transmettre des données aux fonctions appelées ?

Par exemple dans snabbdom je peux utiliser

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

Et le function obtiendra dataToPass comme premier argument. Mais cela semble être une erreur dans vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function . Existe-t-il un moyen de transmettre les données et l'événement à l'aide de l'élément on from create ?

@dubcanada, la gestion des événements dans Vue 2.0 est différente de celle de snabbdom - vous devez configurer la fonction vous-même. La syntaxe du tableau attache simplement plusieurs gestionnaires au même événement.

J'essaie d'obtenir le contenu des emplacements sous forme de chaîne au lieu de les rendre. Avec les nœuds standard, il existe une solution de contournement facile, mais avec Vnodes, je n'ai pas trouvé de moyen. Existe-t-il une solution de contournement?

@miljan-aleksic Essayez de le rendre, d'obtenir le contenu de l'élément avec innerHTML , puis de masquer l'élément avec display: none en css.

Merci pour l'aide. Si je le rends, la sortie finale serait différente. Je crée un composant qui enveloppera son contenu enfant avec une balise pre et encodera le code HTML.

Dans ce cas, rendez la sortie dans un élément différent de l'original.

Bien que je fasse remarquer que la création de modèles ne devrait pas être votre façon d'écrire votre contenu. Ce devrait être la façon de décrire _comment_ le contenu est écrit, et non le contenu lui-même. Je recommanderais de stocker le texte sous forme de chaîne dans JS (ou en tant que ressource ailleurs dans votre projet, _surtout_ s'il s'agit d'une entrée utilisateur quelconque), puis de le transmettre à l'enfant en tant qu'accessoire, ce qui devrait faire mille fois les choses plus facile en tout cas.

Tu as raison @Kingdaro , le mieux est de ne pas mélanger les concepts et de rester simple. C'était bien d'avoir la syntaxe hihgligthig, cependant :)

Lorsque vous utilisez le v-on directive le $arguments variable est plus disponible. Je ne vois aucune référence à ce changement ici. Est-ce un bug ou une référence manquante ?

@ miljan-aleksic utilise simplement arguments .

Doit être un développeur PHP (comme moi)... Je sais ce que vous ressentez. MDR!

Scott

@yyx990803 , @smolinari Je suis... et je suis gêné maintenant haha. Je me suis fait croire que j'avais déjà essayé ça... il semble que je n'ai pas assez bien réussi. Cela fonctionne, merci et désolé d'avoir gaspillé votre temps.

J'étais sur le point d'ouvrir un ticket sur un autre "problème" mais je ne sais plus si c'est le cas... Lors de l'utilisation de ref le composant ou l'élément enregistré n'est pas disponible immédiatement, donc quelque chose comme ça ne fonctionnerait pas.

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

Au moment où Foo est rendu, $refs.button n'est toujours pas défini. Dans Vue 1 fonctionne comme prévu. Qu'est-ce que je rate cette fois ?

Il vous manque que vous ne devez pas transmettre d'éléments DOM ou d'instances de composants en tant qu'accessoires ...

Pourquoi est-ce une mauvaise idée ? Disons que j'ai un composant Dropdown que je veux connecter à un bouton (le déclencheur). Les deux sont des composants indépendants et au lieu de les connecter via une requête, je transmets directement la référence.

@miljan-aleksic c'est encore mieux de les connecter via l'état :

• l'état ouvert/fermé est maintenu dans leur parent commun
• le parent passe l'état à la liste déroulante en tant qu'accessoire
• le parent écoute l'événement du bouton pour basculer l'état

De cette façon, la liste déroulante et le bouton sont complètement découplés, le bouton peut être réutilisé pour contrôler d'autres types de composants et la liste déroulante peut être contrôlée par d'autres types de composants d'entrée.

Il n'est pas facile de se débarrasser des vieilles habitudes. Dois-je blâmer jQuery ou principalement moi ? :RÉ

Votre approche, Evan, est correcte. J'irai dans ce sens même si cela signifie que l'intégration de Dropdown serait plus fastidieuse. Comme le composant parent devrait savoir comment écouter les différents événements, non seulement sur l'ouverture mais la fermeture du menu déroulant lorsque vous cliquez à l'extérieur, mais pas sur le menu déroulant lui-même, etc. De nombreux événements et solutions de contournement que le menu déroulant résolvait.

Comme le composant parent devrait savoir comment écouter les différents événements, non seulement sur l'ouverture mais la fermeture du menu déroulant lorsque vous cliquez à l'extérieur, mais pas sur le menu déroulant lui-même, etc. De nombreux événements et solutions de contournement que le menu déroulant résolvait.

C'est encore possible ? vous pouvez tout à fait faire addEventListener('body', ... ) partir du composant déroulant pour enregistrer les clics extérieurs, etc.

Oui oui. Il est temps de refactoriser certains composants :) Merci à tous ! Super communauté.

Comment appliquer v-model à un composant avec createElement ? J'ai jeté un œil au code généré à l'aide du compilateur de modèles, et... c'est beaucoup de code. Je n'ai pas bien compris la documentation sur les directives.

Par défaut, une directive de compilation extraira la directive et la directive ne sera pas présente à l'exécution. Si vous souhaitez que la directive soit également gérée par une définition d'exécution, renvoyez true dans la fonction transform.

@blocka, vous n'avez pas accès aux directives intégrées si vous utilisez la fonction render . Vous devrez gérer vous-même la logique équivalente. Par exemple, v-if est juste une expression ternaire, v-for est une expression array.map() ... et v-model (sur un élément <input> normal ) se traduit par une liaison value et un écouteur d'événement input .

@yyx990803 c'est ce que je pensais. Je vais probablement liquider avec un traité qui HOC (je suis déjà remettant conditionals de la même façon (bien que je pense à l' aide de ce )

Avec vue 1, il y avait deux avantages déclarés de vuex vs redux.

1. Les performances sont meilleures car vuex modifie l'état, ce qui fonctionne mieux avec vue (le remplacement de l'ancien état avait des performances équivalentes à une "vérification sale")
2. Vuex est plus "conscient" qu'il est dans une application vue

L'utilisation du dom virtuel atténue-t-elle tout ou partie de 1 ?

@blocka, cela en atténue une partie, mais les performances globales seront toujours bien meilleures qu'avec Redux.

Ce qui a changé en 2.0, c'est la granularité de la réactivité. Faisons une comparaison :

• Dans Vue 1.x, la réactivité est très fine. Chaque directive et chaque liaison de texte a un observateur correspondant. Cela se traduit par des mises à jour précises lorsque les données changent, mais au prix d'une surcharge de suivi des dépendances plus importante lors du rendu initial et d'une utilisation de la mémoire légèrement plus élevée.
• Avec Redux, la réactivité n'a aucune granularité. Chaque fois que quelque chose change, l'ensemble de l'application doit être restitué. Dans React, la liaison Redux effectue une certaine optimisation sur les conteneurs connectés, mais l'utilisateur doit encore implémenter largement shouldComponentUpdate pour obtenir de meilleures performances.
• Dans Vue 2.0, la réactivité a une granularité moyenne. Chaque composant a un observateur correspondant qui garde une trace des dépendances de ce composant. Lorsque les données changent, seuls les composants qui dépendent de la modification devront restituer leur DOM virtuel. C'est essentiellement le meilleur scénario pour React, mais vous n'avez rien à faire pour y parvenir dans Vue 2.0.

Généralement avec 2.0, vous verrez (par rapport à 1.x)

• mises à jour légèrement plus lentes (mais toujours très rapides) pour les petites modifications de données
• mises à jour décemment plus rapides pour les modifications de données moyennes à importantes
• rendu initial beaucoup plus rapide

Hey,
Je ne fais pas fonctionner les transitions avec animée.css.

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

Quelqu'un a-t-il une idée ?

Vos noms d'accessoires sont erronés.

camelCase vs kebap-case s'applique toujours en 2.0.

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

@LinusBorg Je suis désolé, j'ai déjà essayé ça. Ici, j'ai un petit violon. Avec les transitions CSS et la balise de nom, cela fonctionne bien.
https://jsfiddle.net/z0nyfba0/

Lors de l'utilisation de v-model sur un composant, le composant aura-t-il une visibilité sur les modificateurs utilisés avec v-model ?

Par exemple, si j'ai un composant qui émet un événement input , le moment où cet événement est émis dépend de l'utilisation ou non du modificateur lazy .

@fergaldoyle j'ai joué un peu avec cela et je pense que vous ne pouvez pas utiliser de modificateurs de modèle v sur un élément personnalisé car vous devez émettre manuellement un événement d'entrée. Si vous souhaitez obtenir un comportement paresseux, vous devez lier l'événement change à l'entrée, par exemple https://jsfiddle.net/cynhtLty/1/

@calebboyd

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

1. Vous devez utiliser enter-active-class et leave-active-class
2. Vous devez mettre class="animated" sur l'élément <router-view> .

@fergaldoyle D'après la documentation 1.0, je pense qu'avec lazy , le v-model réagirait simplement à change au lieu de input . Vous pouvez l'utiliser pour changer le comportement et émettre input ou change pour donner des résultats différents selon que lazy est donné ou non.

Je me suis gratté la tête en jouant avec un exemple simple de v-for . Pour une raison quelconque, la liaison value ne fonctionne pas pour les éléments select en 2.0 : https://jsfiddle.net/972eL5fL/

De plus, il convient probablement de noter dans la documentation que les plages v-for telles que "i in 10" commencent à partir de 1 au lieu de 0 comme dans 1.0.

@lauritzen

Je me suis gratté la tête en jouant avec un simple v par exemple. Pour une raison quelconque, la liaison de valeur ne fonctionne pas pour les éléments sélectionnés dans 2.0 : https://jsfiddle.net/972eL5fL/

Cela semble fonctionner comme prévu pour moi, qu'est-ce qui ne fonctionne pas pour vous ?

Message d'intéret public

Nous vous encourageons à poser des questions d'assistance sur le forum ou sur gitter .

Ce problème doit être réservé aux discussions sur la nouvelle API. Si nous gérons le support pour diverses questions ici, cela deviendra incontrôlable.

Merci.

Pourquoi vm.$get a été déprécié ?
Pourquoi pas Vue.get à la place ?
Il est très utile pour évaluer des expressions calculées comme celle-ci
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

@iagafonov, il n'y a pas beaucoup de scénarios où cela est utile, donc cela ne devrait pas faire partie du noyau.

Si vous avez besoin de la fonctionnalité pour l'un des rares scénarios, vous pouvez très facilement ajouter un comportement similaire à l'aide de lodash, par exemple :

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

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

(bien sûr, vous pouvez également l'ajouter en tant que "méthode de classe" comme Vue.get() - ou simplement l'importer localement là où vous en avez besoin - votre choix)

@LinusBorg. Tout d'abord, je n'utilise pas de lodash ou quelque chose comme ça.
Deuxièmement, la mise en œuvre de lodash est lente, car elle essaie au cours de l'exécution d'approfondir la structure d'expression. vue est conforme à la nouvelle fonction spécifiée (par parseExpression), liée à la portée.
Ce n'est pas une partie triviale, il est très difficile de réimplémenter cela.
Bien sûr, la fonction $get compile à chaque fois). Ce serait bien si parseExression faisait partie de l'api dans Vue.util, par exemple.

@iagafonov this.$get doit également analyser le chemin lors de l'exécution et récupérer la valeur de manière dynamique. Sinon, vous obtiendrez une erreur si le chemin n'existe pas. De plus, la différence de perf sera négligeable dans la plupart des cas. Si vous ne voulez pas de lodash, il existe de nombreuses autres bibliothèques de récupération de chemin. Cela ne fait plus partie des préoccupations de Vue.

Quelles sont les alternatives aux attributs de paramètre désormais obsolètes ?

tu parles de params dans une directive ? Ensuite, vous pouvez trouver tous les attributs liés à l'intérieur de l'objet vnode

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

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

@sqal , est-ce en réponse à ma question ? Si c'est le cas, je parle des attributs de paramètre tels que paresseux, nombre et anti-rebond. Par exemple, avant la 2.0, je pouvais faire ceci <input type="text" v-model="msg" number> (le nombre étant un attribut de paramètre ici). Comment puis-je obtenir les mêmes résultats sans utiliser l'attribut param ?

@p-adams, c'est mentionné dans le message - ce sont maintenant des modificateurs <input v-model.number="msg">

Je trouve que dans Vue 2.0, lorsque les accessoires changent, la fonction de rendu est toujours appelée, donc je me demande si la 2.0 prendra en charge shouldComponentUpdate pour décider s'il faut effectuer un nouveau rendu.

@yyx990803 D'accord, je le vois maintenant dans le message The lazy and number params are now modifiers .

@HeChenTao Evan a expliqué cela un peu ici https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

@HeChenTao, la fonction de rendu n'est pas "toujours" appelée, uniquement lorsqu'elle est requise :

• Vue n'a pas besoin de shouldComponentUpdate , en raison de sa réactivité.
• Lorsque les données réactives utilisées dans un composant sont modifiées, cela déclenchera la fonction de rendu, la différence vdom et ainsi de suite.
• Mais si aucune de ces données n'a changé, aucune mise à jour n'est nécessaire et la fonction de rendu ne sera _pas_ appelée.

La même chose peut être faite en réaction avec mobx. Je suis à peu près certain que vous n'avez pas à implémenter shouldComponentUpdate . Cependant, comme vue, mobx insiste sur un état mutable. Si, pour une raison quelconque, vous avez adhéré au concept d'état immuable. Dans ce cas, réagissez à vos côtés avec shouldComponentUpdate .

Cela signifie-t-il que si quelqu'un insiste sur un état immuable, la vue ne sera pas un bon match ?

L'argument de contexte des composants fonctionnels a children plus slots . Je trouve cela un peu déroutant sachant que children() et slots().default exactement la même chose. Je me demande quelle est la bonne approche. Probablement « enfants » car les machines à sous sont paresseuses, mais pourquoi soutenir deux manières différentes d'obtenir le même comportement ?

Les composants fonctionnels ne sont que des fonctions et n'ont donc pas d'enfants. À mon humble avis, les enfants devraient être dépréciés et garder les machines à sous comme non paresseuses.

@blocka, vous pouvez implémenter des données réactives en réaction avec mobx, vrai. Mais la réactivité est au cœur des fonctionnalités de Vue. Donc, si ce n'est pas sa tasse de thé, cette personne est à la mauvaise partie.

@miljan-aleksic children est brut (vous obtenez chaque nœud quel que soit l'emplacement dans lequel ils doivent aller), slots sera résolu en fonction des noms slot des enfants entrants.

Merci @yyx990803. Peut-être que plus de détails à ce sujet dans la documentation éviteraient les confusions, @chrisvfritz.

@ miljan-aleksic Je vais ajouter une note. ??

En ce qui concerne les filtres, l'utilisation d'une propriété calculée semble assez simple, mais comment gérer le cas de l'utilisation d'un filtre avec v-model. Si l'on veut filtrer une liste de noms en tapant dans le champ de saisie, comment faire en 2.0 ?

Vous pensez à ce que Vue avertisse lorsqu'un champ de données/une propriété calculée n'est pas utilisé dans un modèle ? J'imagine qu'il y a quelques limitations ici, mais il serait très utile de savoir où je pourrais me permettre de retirer des importations de magasins inutiles là où elles ne sont pas nécessaires.

@yyx990803 , que pensez-vous de la définition $context référence $parent ou $root Je me suis retrouvé à accéder souvent au contexte qui n'est actuellement disponible que via l'objet $vnode .

En fait, cela ne semble pas être un moyen fiable d'accéder au contexte. Comment faut-il faire ?

@miljan-aleksic Pouvez-vous partager les cas d'utilisation où vous accédez fréquemment au contexte ?

@Kingdaro Pouvez-vous ouvrir un problème pour cela? Ça a l'air bien si c'est faisable.

@p-adams Vous pouvez toujours utiliser une propriété calculée avec Array.prototype.filter .

@chrisvfritz , essentiellement pour des solutions de contournement, par exemple pour définir des variables dans le contexte attendu par l'enfant. Ou pour définir une référence au composant plus tôt que Vue lui-même.

Je suis d'accord que ce n'est pas commun à tous, mais au moins il devrait y avoir un moyen fiable d'y accéder dans le composant. Le $vnode n'est pas présent tant que le composant n'est pas monté lors de l'utilisation de modèles (du moins ma conclusion jusqu'à présent).

Je me contenterais de savoir comment y accéder de manière appropriée.

Une autre situation où $context serait utile est lors de la réutilisation d'un composant en tant que racine d'un autre composant.

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

Dans l'exemple, child.$parent renverrait le composant Foo au lieu de Bar, ce qui est correct, mais si le parent et l'enfant dépendent l'un de l'autre, une communication directe entre eux pourrait se faire via le contexte.

@miljan-aleksic Je laisse celui-ci à @yyx990803. Je dirais que tout comme avec $parent , atteindre $context sera probablement dans le mauvais sens 99,9% du temps et je pense que je ne l'utiliserais probablement jamais.

J'ai une situation avec v-show et transitions. Dans ce scénario, il existe un modal qui par défaut est « afficher : aucun » dans le CSS. Lorsqu'il est combiné avec v-show il ne serait jamais affiché car la directive supprime la propriété d'affichage, les CSS persistent alors. Je ne peux pas modifier le CSS (exigences du projet) et je ne peux pas utiliser une directive personnalisée car il semble que les transitions Vue s'appuient spécifiquement dessus.

Je pense maintenant qu'une directive qui évalue juste après v-show pourrait définir la propriété display sur block. Besoin d'essayer cela, mais de toute façon, ce pourrait être une bonne idée d'ajouter un modificateur à v-show pour permettre de régler l'affichage sur block ou inline-block. Juste une pensée.

@chrisvfritz , il est prévu que pour les composants fonctionnels, la référence parent ne soit pas le parent immédiat où ils sont utilisés comme emplacements, mais le composant de contexte à la place ?

La compilation du modèle échoue s'il contient "<" (et éventuellement d'autres caractères html sensibles) dans 2.0.0-beta7

https://jsfiddle.net/x0r59ur1/

Cela a fonctionné dans 1.0.26.

Échapper "<" avec "<" résout le problème.

@GlurG, on s'attend à ce que "<" s'échappe correctement.

@yyx990803 , si je veux utiliser des transitions sur une liste de composants du même type et conserver leur état, comment dois-je faire ? En suivant les docs, je ne vois comment lorsque les composants sont différents.

Disons un composant Tab et transférons ses éléments. je ne trouve pas de moyen :(

<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> est pour un seul élément uniquement. Vous avez besoin de <transition-group> pour plusieurs articles.

@yyx990803 ,

@yyx990803 , @LinusBorg J'apprécie l'aide mais la solution n'est pas évidente. Je sais comment les transitions sont appliquées, ce que je ne peux pas comprendre, c'est comment keep-alive les composants transitionnés.

J'ai créé un nouveau problème pour plus de clarté avec un exemple jsfiddle sur la façon dont les composants sont créés à chaque fois.

@yyx990803 , merci beaucoup d'avoir amélioré la fonction de maintien en vie, maintenant cela fonctionne comme prévu.

Vous changez littéralement ma vie, avec vos produits et votre éthique de travail, je suis capable d'apprendre, de construire et de livrer des produits que j'avais longtemps en veille. Avec votre approche simple, la haute technologie est disponible pour tout le monde à utiliser et à développer. Pour tout cela et plus, je suis éternellement reconnaissant.

@ miljan-aleksic Il y a un clin d'oeil à la campagne Patreon .

Vous savez quoi @phanan , vous avez tout à fait raison. J'ai commencé à soutenir personnellement Evan et dès que les produits de l'entreprise commenceront à donner des résultats, le soutien deviendra plus visible.

Le crochet de cycle ready vie mounted ; mais selon le journal des modifications, il n'y a aucune garantie que le composant sera rendu avant que mount ne soit appelé. Cela provoque des erreurs sporadiques lorsque je souhaite initialiser certains composants jquery (comme selectize) après l'initialisation du composant. Quel hook de cycle de vie dois-je utiliser à la place ? Le crochet "prêt" peut-il être émulé comme ceci :

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

@GlurG Oui, cela fonctionnera. Et au fait, c'était aussi nécessaire avec ready'() en 1.0 dans de nombreux cas.

Y a-t-il une raison pour laquelle il ne peut pas y avoir de crochet pour cela de toute façon? J'ai également
à travers cela ... même en 1.0, et a eu recours à des choses comme la boucle avec raf pour
vérifiez si c'est dans le dom, etc.
Le 10 août 2016 18:26, "Thorsten Lünborg" [email protected]
a écrit:

@GlurG https://github.com/GlurG Oui, cela fonctionnera. Et d'ailleurs,
c'était également nécessaire avec ready'() dans 1.0 dans de nombreux cas.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -238903012, ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AACounAoI8p65soUUrbdaiwteDXKgMGJks5qee25gaJpZM4IedHC
.

Lors de l'utilisation des fonctions de rendu, les directives principales sont ignorées, ce qui est raisonnable. Mais certains ne sont pas si faciles à reproduire en utilisant plain js, comme le v-model qui a des solutions de contournement pour IE9 et résout probablement d'autres problèmes de cas extrêmes.

Cela vous fait reconsidérer l'utilisation d'un modèle à la place, mais ce n'est pas possible ou la meilleure option dans certaines situations. Les documents pourraient certainement offrir plus de conseils sur ce sujet et en outre, il pourrait être judicieux d'avoir de l'aide lorsque vous travaillez avec des fonctions de rendu, ce qui aiderait à résoudre ces situations courantes et à ne faire manquer un modèle à personne.

@miljan-aleksic désolé, j'ai supprimé mon commentaire car j'ai remarqué que cela ne fonctionne que pour les directives v-show ou personnalisées, et oui, comme vous l'avez dit dans le cas du v-model, il est nécessaire d'ajouter un écouteur d'entrée/modification et de mettre à jour nos données manuellement

le nouveau hook activated censé être appelé lorsqu'une route est déclenchée qui active/monte un router-view ? Je ne vois pas ce comportement actuellement.

@wprater non, c'est uniquement lié à <keep-alive> et rien d'autre.

@ yyx990803 J'enveloppe ma vue de routeur dans un keep-alive, mais je n'arrive pas à trouver un crochet pour le retour à la vue précédente. mounted ni activated sont appelés. J'ai besoin d'être certain que le dom est rendu.

@wprater s'il vous plaît éviter d'utiliser ce fil pour des questions sans rapport. S'il y a un bogue, déposez le problème dans le référentiel correspondant avec reproduction.

Est-ce que Vue JSX prend en charge l'opérateur de propagation d'objets ? J'ai essayé mais ça ne marche pas.

C'est le cas et @yyx990803 a fait beaucoup d'efforts pour le faire fonctionner.

Je fais cela <Component {...{ props } }></Component> et cela fonctionne comme documenté.

@blocka Merci ! Je pensais que le nom props la propriété

@yyx990803
components options

par exemple

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>'
})

C'est un bug ?

@QingWei-Li, ils ne sont tout simplement plus pris en charge, car cela n'a jamais été une fonctionnalité officiellement documentée. La raison en est qu'avec ES2015, vous pouvez simplement écrire components: { Parent, Child } .

juste une petite suggestion,
y a-t-il une chance pour l'itération normale du tableau que nous utilisons v-foreach et pour la plage, nous utilisons v-for .

ce qui aura plus de sens pour les utilisateurs venant de php et même cohérent avec .each en JQ ou foreach en JS

@ctf0 Nous sommes en phase RC, l'API ne changera plus. Et nous n'introduirons pas non plus de syntaxe alternative pour faire la même chose.

Je ne pense pas que la surcharge mentale de v-for="item in items" soit suffisamment importante pour le justifier.

Avec cette nouvelle version, je voudrais vous gérer ce cas.

J'ai un composant calendrier (issu de l'interface utilisateur sémantique), qui utilise une saisie de texte classique, et affiche la date au format humain (comme "10 juillet 2016" par exemple). Avec la v1.0, j'utilisais un filtre bidirectionnel pour convertir cette chaîne en une date appropriée afin que mes données d'objet soient directement prêtes à être soumises. Mais comme les filtres ne fonctionneront plus en v-model, comment pourrais-je faire la même chose maintenant en v2.0 ?

Merci

@shadowRR serait-il possible de voir du code ?

@p-adams Bien sûr. Voici.

Tout d'abord, mon filtre, qui est utilisé sur mon v-model pour l'entrée de mon calendrier. Son seul but est d'écrire, lorsque la valeur change, un type de date approprié à mes données (date postgres).

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

Et je l'utiliserais comme ça sur mon composant (l'entrée a un système de calendrier qui renvoie ma date dans un format lisible par l'homme)

<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>

Je recommanderais de lire le message de @yyx990803 ici : https://github.com/vuejs/vue/issues/2756 où il discute des filtres bidirectionnels sur v-model . Aussi, il peut être préférable de poser des questions comme celle-ci ici : http://forum.vuejs.org/

J'ai raté le post dont tu parles, je vais voir ça, merci ;)

Salut,
J'ai quelques doutes sur les nouveaux crochets de cycle de vie.
Si je veux enregistrer un gestionnaire d'événements une fois monté et le désenregistrer avant le démontage, comment dois-je le faire fonctionner ? Ajouter des contrôles et des logiques dans les hooks créés et avant de détruire ?
Dans Vue 1.x, j'utiliserais des crochets attachés et détachés.
Mais en 2.0, il y a un crochet monté mais pas de crochet de démontage. Se sent un peu ne pas correspondre.
Y a-t-il une raison pour laquelle aucun crochet de démontage n'est fourni ?

@f15gdsy mounted correspond à destroyed . Il n'y a pas attached pièces de comptoir detatched dans la version 2.0 - vous devez faire vous-même le contrôle interne. Si vos événements ne se soucient pas de l'in-dom/off-dom, alors mounted et beforeDestroy sont les endroits appropriés pour le faire.

Lorsqu'il est utilisé sur un composant personnalisé, v-on n'écoute désormais que les événements personnalisés $ émis par ce composant. (n'écoute plus les événements DOM)

J'ai peut-être raté quelques messages ici, mais quelle est la décision de conception derrière cela ?
Cela rendrait les événements de clic simples sur les composants très verbeux.

1.0 :

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

2.0 :

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

@fnlctrl , utilisez le modificateur natif : @click.native="bar" .

@miljan-aleksic Merci beaucoup ! Je pense que ce modificateur devrait être ajouté à Directives -> v-on -> modifiers dans ce numéro

Puis-je utiliser Koa (1.x ou 2.x) comme serveur ? Y a-t-il un problème sur vue-server-renderer avec Koa ?

@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>

Pourquoi ne pas appeler le crochet d'entrée ?

@fundon Vous devriez poser la question sur les forums ou le chat gitter

Verrouillage de ce fil car :

1. Nous sommes maintenant en gel de l'API en RC donc ce document ne sera plus mis à jour.
2. Trop de gens l'utilisent comme un fil de FAQ général, ce n'est pas pour cela qu'il est destiné.

Si vous avez un bogue, veuillez ouvrir un problème séparé en suivant le guide de rapport de problème, si vous avez une question, veuillez utiliser le forum ou gitter.

Mise à jour : Pour une liste plus définitive et détaillée des modifications apportées à la 2.0, consultez le nouveau guide de migration .