Vue: 2.0 cambios

Acabo de ver que ciertas funciones solo estarán disponibles en la versión independiente . ¿Significa eso que esta y la versión de NPM son significativamente diferentes?

@rekateka 2.0 medios de construcción independientes (compilador + tiempo de ejecución). La exportación predeterminada del paquete NPM será solo en tiempo de ejecución, porque si lo instala desde NPM, probablemente precompile las plantillas con una herramienta de compilación.

Gracias, @ yyx990803. Todavía tengo un par de preguntas más sobre el compilador y otras características, pero he usado el foro para eso.

¿Se han realizado cambios preocupantes en los documentos que deba revisar por casualidad? ¡Buen trabajo! Sigue así, hombre. Estás redefiniendo el desarrollo web. ¡Gracias!

¿Puedo obtener this.arg de mi directiva?

Veo que vnode.data.directives tiene arg , pero cuando tengo dos o más directivas, no puedo saber el 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">

¿Debo usar forEach ? ¡Gracias!

@banricho buen punto, ¡eso se ha pasado por alto! Vea la firma de la función directiva actualizada.

En primer lugar, lo siento, no estoy muy seguro de poder plantear este problema aquí, y tengo algunos requisitos que quiero decir.
El requisito es que espero poder diseñar el uso de mi componente de esta manera

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

Espero que los niños puedan ser como una especie de argumentos, no solo limitantes en atributos.
Por ahora puedo hacer un componente, el uso como

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

Pero creo que no es del todo bueno, espero que pueda ser como este que hice antes en React coverflow

@andyyou : esa pregunta probablemente se publique mejor en el foro, ya que no es un problema, ni una sugerencia clara, ni una ayuda real para este problema.

http://forum.vuejs.org/

Si descubre que sus requisitos no se pueden cumplir con Vue en el hilo de su foro, puede abrir un nuevo problema aquí.

Scott

@smolinari Gracias

"Pero para casos más complejos, se recomienda introducir una capa de administración de estado dedicada usando Vuex". Esto parece implicar que el estado debe usarse sobre eventos. Los veo como completamente separados: un evento es un momento en el tiempo, mientras que el estado no cambia. Se podría decir que se puede observar el estado, pero eso tampoco transmite un momento específico, sino cada vez que algo cambia. Me interesa el significado de esta recomendación.

@jrenton Generalmente, podemos considerar el sistema de eventos simplemente como el componente A que le dice al componente B que cambie su estado, o A que le dice a B que haga otra cosa.
Entonces, para el primer caso, podemos usar la administración de estado (administrar un estado compartido para A y B) en lugar de usar un sistema de eventos para permitir que A le diga a B que cambie de estado.
Para el segundo caso, creo que se puede manejar bastante bien con el enfoque de 'bus de eventos'.

@jrenton en lugar de una sopa de componentes que se comunican entre sí, Vuex sugiere un solo canal para que los componentes expresen "intenciones" con acciones y registren "hechos" con mutaciones.

Estoy usando Twig junto con Vue.

Hasta ahora (vue 1.0) he estado pasando datos a mis componentes de esta manera:

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

(Tenga en cuenta que {{ y }} son etiquetas de ramitas; para vue, he estado usando delimitadores personalizados ${ y } )

Si entiendo las cosas correctamente, en Vue 2.0 debería hacerlo así:

<my-component :data=" '{{ DATA }}' "></my-component>
¿derecho?

@gholol no es solo

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

En realidad, parece que su uso anterior no debería funcionar en primer lugar.

Bueno, funcionó bien ...

Como dije, los datos provienen del motor de plantillas twig. Ahora en Vue 2.0 no funciona. He intentado pasarlo como dijiste (sin apóstrofos individuales) pero la propiedad de los datos no está definida.

Error: SyntaxError: missing} después de la lista de propiedades

EDITAR: Funciona, olvidé mencionar que la variable DATOS es una cadena

@jrenton Mi idea y motivación es bastante simple, parece que a Vue no le gusta React que nos obliga a usar JSX. Podemos elegir un montón de template .

Espero poder usar la sintaxis de elementos secundarios como parámetro (argumentos) pasar argumentos a los padres porque en algún lenguaje de plantilla como slim si tiene un poco de muchos atributos o dice que el nombre del atributo es bastante largo, entonces tenemos que poner todas las cosas en una línea. es más fácil hacer un código de una línea de más de 80 caracteres.

@ yyx990803 Sintiéndome aventurero hoy, quería ver cuánto esfuerzo tomaría migrar algo de 1.0 a 2.0a, desafortunadamente, dado que ya no es posible usar la interpolación simple, ¿cómo podría hacer algo simple como <input type="text" name="account[categories][{{ category.id }}]"> en 2.0?

Las plantillas en línea de ES6 funcionan en expresiones vinculantes:

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

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

Si esa es la única forma de hacer que esto funcione en 2.0, entonces no me importa que diga que eso es una regresión en la hermosa sintaxis a la que 1.0 nos acostumbramos, sí, sé que es solo ES2015.

¿Supongo que se eliminó la interpolación por razones de rendimiento? Solo espero que valga la pena la sintaxis más fea.

@oskarkrawczyk Supongo que quieres terminar con algo como name="account[categories][fruits]" en tu DOM, porque esto es lo que representaría tu expresión.

La versión 2.0 (y la 1.0 adecuada, de hecho) será :name=" 'account[categories][' + category.id + ']' " .

@simplesmiler Entendido. Creo que {{ }} me ha echado a perder un poco.

@ yyx990803 ¿puedo insertar dinámicamente un componente, como este?

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

¿Cómo puedo vincular algunos valores para un atributo que depende de la expresión? Por ejemplo:

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

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

Espero el próximo resultado:

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

@nervgh, este no es el lugar adecuado para hacer esta pregunta.
Utilice la expresión ternaria, v-bind:placeholder="flag ? 'test' : 'test2'" .

@simplesmiler , gracias por tu respuesta. Intento decir que _Object-Syntax_ será útil en estos casos, pero no funciona como esperaba.

La sintaxis del objeto class , y para los componentes no habría forma de detectar desde el lado secundario si pretendía enviar una lista de cadenas o un objeto adecuado.

Re: .once y .sync están obsoletos.

¿No rompe esto los patrones de diseño realmente comunes?

No puedo pensar en cómo podría tener componentes simples para manejar campos de formulario sin estos.

Tengo componentes simples para diferentes tipos de campos de formulario, por ejemplo, aquí está mi plantilla de componente "cuadro de texto":

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

... y también un componente más complejo para listas que proporciona una interfaz de usuario para agregar y eliminar elementos de matrices en la estructura de datos

Entonces uso estos componentes, por ejemplo, así:

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

Nota: Todos estos componentes tienen dos accesorios: data y type . data es el nodo en la estructura de datos que se está editando que el componente es responsable de proporcionar y una interfaz de usuario para editar, y type es el nodo en la estructura de datos (masiva, estática) que contiene los tipos / jerarquía de campos.

¿Cómo pueden funcionar cosas así sin .sync ?

Me parece que complicaría mucho las cosas crear algún tipo de sistema de mensajería entre estos componentes donde los subcomponentes puedan de alguna manera comunicar al padre qué subcomponente son, y el padre puede entonces averiguar qué parte de sus datos estructura para modificar.

Realmente espero que me esté perdiendo algo ... porque parece que estás diciendo que usar componentes para crear editores para partes de tu estructura de datos es un anti-patrón. ¿Qué? Hasta ahora, eso es lo único para lo que he usado Vue. Supongo que piensas que eliminar esta función alentará a las personas a escribir un código más limpio. Tal vez tenga ese efecto en algunas personas, pero muchas personas escribirán un código mucho más desagradable para evitar esta limitación. Modificar el estado es lo único útil que hacen las computadoras. Continúe haciéndolo más fácil.

@JasonWoof v-model en 2.0 puede funcionar en componentes personalizados. El componente simplemente necesita:

1. exponer un objeto llamado value
2. Emite un evento input cuando el valor debe sincronizarse con el padre, por ejemplo, this.$emit('input', value)

Ver ejemplo .

@ yyx990803 Gracias por la explicación y el enlace. Ahora estoy atrapado en:

¿Por qué eliminar .sync ?

No veo la ventaja, solo desventajas. El ejemplo que vinculó muestra que puede lograr lo mismo con :selected.sync o v-model . Solo veo desventajas para el método del modelo v:

1. Requiere una placa de caldera significativa en el lado del subcomponente, es más complicado, más para aprender, etc.
2. Solo puede pasar un valor con v-model, pero puede tener múltiples .sync props

No veo cómo el cambio al modelo v hace que algo sea más claro / limpio. En ambos casos, la única indicación en el padre de que el componente hijo puede modificar fácilmente el estado del padre es la sintaxis del accesorio en la plantilla. Incluso diría que .sync es más claro.

La otra cosa es que cuando pasa objetos / matrices / etc como accesorios, entonces son mutables desde el componente hijo. Por lo tanto, no puede proteger a los programadores para que no puedan cambiar el estado de los componentes secundarios en este caso (que supongo que es muy común). Por lo tanto, me parece que está introduciendo un obstáculo al eliminar lo que lo hace tan pasar valores de cadena funciona igual que pasar valores de objeto. .sync hace que mi código sea más simple y más consistente al tener siempre mis accesorios de "datos" escribibles desde el lado del niño, sin importar el tipo de datos.

Soy nuevo en Vue.js (hace 3 días) pero por lo que puedo ver hasta ahora, Vue.js es valioso principalmente por dos cosas:

1. fácil manipulación de dom con plantillas
2. Propagación automática de cambio de valor / datos, incluida la activación de cambios de plantilla.

Al menos eso es lo que he descubierto hasta ahora.

Me parece que eliminar .sync hace que sea difícil lograr que Vue.js haga el segundo de manera consistente.

@JasonWoof porque los efectos secundarios explícitos vs. implícitos fuera del alcance de los componentes hacen toda la diferencia en la mantenibilidad a largo plazo.

... y aunque se podría argumentar que la gente simplemente debería aprender cuándo no usar .sync , nuestra experiencia hasta ahora es diferente. la gente tiende a confiar demasiado en esto y crea un código que luego difícilmente pueden depurar.

por lo que esta es una decisión de diseño para obligar a las personas a hacerlo bien desde el principio.

un ejemplo:

• Sincronizamos un valor name entre un padre y un hijo. todo está bien.
• decidimos _'¡Eh, cuando ese valor cambia, tenemos que hacer algo en el padre! '_
• Entonces, creamos una función watch . ¡Bonito!
• Más tarde nos damos cuenta de que el observador parece disparar cuando no queremos que lo haga. Pero realmente no podemos decir por qué, porque realmente no podemos poner console.log() ningún lugar para rastrear el comportamiento.
• Después de pensarlo mucho, nos damos cuenta de que _realmente_ solo queremos que _algo_ suceda cuando se cambia el valor en el padre, no en el hijo o el "abuelo".
• Ahora tratamos de encontrar una manera de diferenciar estos escenarios en la función watch alguna manera.
• Solo para darme cuenta de que esto hace que una cosa simple sea muy complicada.
• y al final, alguien nos dice que eliminemos la sincronización, por lo que lo tiramos todo y usamos un accesorio unidireccional y un evento emitido para manejar la situación: el código se vuelve más simple y más explícito, por lo que es simple razonar sobre cómo y cuando los datos fluyen y es más fácil depurarlos. El error se encuentra rápidamente y podemos seguir adelante.

... y esto se vuelve aún más loco cuando sincroniza más de un nivel de profundidad.

Este es un patrón (anti) que hemos visto una y otra vez en los foros y en el chat de gitter.

Eliminar .sync obliga a las personas a escribir código claro, explícito y fácil de mantener desde el principio, porque su código no será lo suficientemente simple por .sync durante mucho tiempo, la mayor parte del tiempo.

está bien. Gracias por explicarlo.

Es bueno saber qué problema está tratando de resolver.

Sin embargo, dudo seriamente que esto ayude ... Hágalo de manera que la gente no pueda romper fácilmente los patrones que le gustan y que la gente haga cosas mucho peores para sortear las limitaciones.

Esto me recuerda mucho a la abstracción. Las abstracciones nos meten en tantos problemas. Hacen que el código sea difícil de leer, de depurar, etc. Pero no se puede arreglar esto quitando la capacidad de hacer abstracciones ... eso es lo que hace que la programación sea posible / útil. La solución a esto no está en el nivel de lenguaje o marco, sino en la enseñanza, el asesoramiento y el aprendizaje. Alentamos a las personas a no hacer las cosas demasiado abstractas.

Me parece que estás hablando de una filosofía de diseño de este tipo. En muchos casos, es una gran filosofía a tener en cuenta al programar. Pero cuando se impone como una limitación, y el programador piensa que esta limitación le impide hacer lo que tiene que hacer, entonces va a solucionarlo, lo que resultará en todos los problemas que estaba tratando de evitar y cosas peores.

La gente no dejará de intentar mutar el estado padre de los hijos. No se puede obligar a la gente a no hacer eso.

Su cosa v-model es lo suficientemente complicada como para solucionar este problema pasando el objeto / matriz principal y una clave para que el niño pueda modificarlo.

Supongo que este último golpe está en el corazón de lo que estoy tratando de transmitir: yo (personalmente) veo la falta de .sync como un problema, y ​​lo solucionaré o no usaré su marco. Apuesto a que mucha gente tendrá el mismo enfoque.

Quizás esto sea evidente, pero me enoja un poco cuando la gente intenta imponerme filosofías de diseño. Preferiría construir cosas que salieran terriblemente mal y aprender a no hacerlo de nuevo que usar sistemas que retienen el poder a propósito por temor a que pueda usarlo mal.

PD: Lo siento, no puedo evitarlo, un comentario más, luego los dejo en paz. La mayoría de los programadores escriben código que no pueden depurar. Esto le sucede a todos los programadores en todos los lenguajes con cada marco. Así es como los programadores se vuelven mejores programadores: cometen errores, hacen código que no pueden corregir, aprenden a escribir cosas de manera diferente en el futuro. Por favor, no simplifique su marco para todos en un intento de hacerlo para que los programadores que se abstraen en la esquina puedan hacer que sus cosas sean un poco más confusas / complejas antes de que se convierta en un desastre que no puedan depurarlo.

@JasonWoof no tiene nada que ver con "simplificar", y evitar que los usuarios capacidad de mantenimiento es, por definición, parte del trabajo de un marco. Tomamos la decisión basándonos en la experiencia de diseño de primera mano, utilizando el propio marco y observando el comportamiento del usuario en varios casos de uso. Si es un anti-patrón, descartaremos a los usuarios para que no lo utilicen y proporcionaremos una guía sobre la solución idiomática. Puede no estar de acuerdo con eso basándose en su opinión personal, pero sus argumentos me parecen poco convincentes.

La gente no dejará de intentar mutar el estado padre de los hijos. No se puede obligar a la gente a no hacer eso.

Seguro. Y _no_ los 'forzaremos', porque puede haber algunos casos extremos en los que esto aún sea necesario. Así que todavía puede acceder a this.$parent , puede pasar $data través de un accesorio, etc., pero, francamente, hacerlo no será mucho más conveniente que $emit en un evento la mayor parte del tiempo. tiempo, por lo que no serán tan atractivos como .sync azúcar.

Además, $parent et.al. no forman parte de la guía oficial, por lo que los usuarios que las utilizan están trabajando activamente en torno a las mejores prácticas sugeridas, que son libres de hacer, pero no fomentamos ese comportamiento.

En consecuencia, el marco no debe fomentar un comportamiento similar al proporcionar azúcar sintáctico 'mágico' como .sync si creemos que tal característica se usa incorrectamente en la mayoría de los escenarios y se opone a las mejores prácticas que el marco busca establecer.

¿Tiene Youda una versión en chino? .

¿Cómo se ve la compatibilidad para vue-router?

@ roblav96

Hay algunos cambios necesarios para ser compatible, esperamos incorporar mejor el enrutador en Vue.

@ blake-newman

¿Podemos juntar una plantilla repetitiva en vue-cli? Parece que no puedo hacer que nada de esto funcione 😢

@ roblav96

Actualmente hay algunos, hay algunos cambios necesarios con vue-loader para que sea compatible. Actualmente 2.0 debe usarse para experimentación solo hasta que se actualicen todas las dependencias adicionales para aplicaciones a gran escala.

¿Existe una ETA para las versiones beta / candidatas?

@Evertt Alpha

@ blake-newman gracias por esa respuesta rápida, concisa y completa. Ésos son los mejores. :-D

¿Alguna solución para replace: false en vue 2.0?

Hola, ¿JSX ya se puede usar?

@reohjs - No y personalmente lo vería como un paso atrás real para Vue, si fuera compatible con JSX.

Scott

@reohjs En la transmisión de Evan anoche, mencionó que podría hacerse con un complemento, así que imagino que una vez que esto entre en beta, no tomará mucho tiempo para que alguien lo cree. Estoy feliz de que no esté en el núcleo, pero un complemento JSX parece una gran idea.

Estoy feliz de que no esté en el centro

👍 👍 👍 👍

Sí, debería ser un complemento. Sin embargo, como se ve, las plantillas tienen muchos beneficios para los componentes estándar.

La compilación JSX debería ser fácil de lograr con este complemento: https://babeljs.io/docs/plugins/transform-react-jsx/

Creo que la función _h sería el reemplazo de React.createElement

¿Qué hay de proporcionar una interfaz para crear modificadores de modelo v personalizados como una forma de reemplazar los filtros de 2 vías? Parece que ya se están utilizando para analizar la entrada del usuario (por ejemplo, v-model.trim ). Si el análisis / formato es simple e independiente de una propiedad de datos específica, el uso de un modificador permitiría que el análisis / formato se reutilizara con mucho menos texto repetitivo que estableciendo una propiedad calculada para cada propiedad de datos individual, o creando un nuevo componente para cada tipo de entrada donde queremos que se aplique el análisis / formato.

Hola, actualmente estoy trabajando en un complemento para admitir gettext en Vue.js 1.0 y tengo una directiva que usa vm.$interpolate .

Me pregunto cómo migrar mi código a 2.0 desde:

• vm.$interpolate quedará obsoleto
• las directivas ya no tendrán instancias en 2.0

¿O hay un enfoque mejor que una directiva?

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

Solo lanzo algunas palabras cortas ya que soy nuevo en Vue , solo para decir que estoy feliz de ver la reducción de la API en general o los ayudantes _bajo-el-capó_. JavaScript ya es realmente poderoso, y con propiedades computadas más otras características reactivas del marco, casi todo se puede lograr.

¡Felicitaciones por esta _próxima_ versión! 🎆

@kemar No estoy tan familiarizado con gettext, pero simplemente extendería Vue.prototype con un método $ translate, y luego lo haría

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

¿Se ha eliminado de 2.0 la capacidad de registrar activos con sintaxis de matriz? No estoy trabajando en alfa, solo me pregunto si es intencional o no.
es decir:

components: [compA, compB, compC]

Sé que ES6 tiene taquigrafía que se ve similar, pero hay algunos escenarios en los que la sintaxis de la matriz fue útil.

Veo que mencionas rendering to native interfaces on mobile con weex y me preguntaba qué tan fácil sería hacer que vue y Nativescript hablen.

Algo más parecido a Nativescript para Vue sería Weex, que mencionaste, o Quasar .

Scott

Si ya no hay dispatch o broadcast ¿cómo informará un componente hijo genérico a su padre de un evento / cambio? Esto no parece ajustarse al patrón de un bus global o vuex. El caso de uso que usamos ahora es un control deslizante de rango para filtros de búsqueda. El componente del control deslizante de rango es genérico y es un elemento secundario de varios filtros de búsqueda diferentes. Actualmente usamos dispatch cuando un control deslizante de rango ha terminado de deslizarse, entonces el padre sabe que debe activar una búsqueda basada en el cambio.

@jrenton oyentes en línea <child @some-event="parentHandler">

Buen trabajo chicos.

En mi punto de vista, todos los cambios dicen que el mejor enfoque es crear su árbol de componentes basado solo en un "flujo unidireccional", que es mucho más simple y fácil de depurar y mantener.

Sin esto, la veracidad de sus datos sería inversamente proporcional a lo lejos que se encuentra del componente superior.

Solo quiero decir eso:

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

Me hace feliz

¿Se espera que se agreguen más a esta lista antes del lanzamiento de 2.0? Simplemente curioso, ya que el tema aún está abierto.

@zephraph Sí, estamos actualizando continuamente la lista a medida que hacemos actualizaciones a la API. 😃 Nada enorme hasta ahora, pero cambios importantes ocasionales de los alfas anteriores.

Tengo un caso, utilicé el envío de eventos en el pasado y estoy atascado con vuex: el componente principal tiene una lista de componentes secundarios y el niño estaba enviando un evento cuando su valor cambió, por lo que el padre pudo hacer algo como una reacción de ese cambio.
Ahora intenté tener una matriz de valores secundarios en la tienda vuex. La cuestión es cómo sabe el componente hijo en el captador y en la acción qué elemento de esa matriz necesita actualizar. Por lo que veo, vuex no proporciona la funcionalidad para obtener o activar dinámicamente una mutilación de un valor, ¿o estoy equivocado en eso?
¿Cuál sería la mejor manera de manejar este caso sin el envío de eventos?

Con la eliminación de $broadcast , ¿cómo le diría a un niño directo que haga algo cuando sucede algo en particular? Este sería un escenario en el que los datos no han cambiado, por lo que los accesorios reactivos no parecen encajar.

Podría usar un accesorio y pasar una marca de tiempo o algunos datos aleatorios y ver ese accesorio en el niño, pero eso parece extraño. Un bus de eventos global requeriría la generación de ID únicos para que el hijo solo reaccione a los eventos de su padre y no a ninguna otra instancia del componente padre.

Hay $emit en un niño que un padre puede escuchar usando un oyente en línea, ¿hay algo al revés?

Podría transmitir una instancia de un emisor a través de un accesorio, luego emmiter.on en el niño, ¿suena terrible?

Las acciones de

// 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 sus artículos no tienen un ID único localmente, puede generar uno cuando el artículo se crea o se recibe de la API. La mayoría de las veces, el cuid es lo suficientemente bueno para eso.

@fergaldoyle debido a que el padre siempre sabe que son los niños, puede poner v-ref:some-child en el niño para obtener la referencia a la máquina virtual del niño, y luego $emit en él, o simplemente llamar a un método directamente con this.$refs.someChild.<methodName>(...) .

Sin embargo, recomendaría repensar la arquitectura en ese caso, porque los eventos que fluyen hacia abajo hacen que el componente sea realmente difícil de razonar.

Estaba jugando con vuejs 2 y noté para Snabbdom si pasas

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

A la función de renderización obtienes

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

Pero en vuejs obtienes

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

¿Hay alguna forma de modificar el contenido del texto (dentro de <h1> )?

@dubcanada, ¿

Correcto, eso tendría sentido. Gracias

Hola. Tengo alguna pregunta sobre el sistema de transición en Vue 2.0 o más bien una propuesta porque no veo que esté en los planes para Vue 2.0. En Vue 1.0, a menudo encontré la necesidad de detectar cuándo terminaría alguna transición / animación que configuré. Ahora hago esto usando setTimeout, pero esta es una forma muy hacky y fea, todos estamos de acuerdo. Entonces, mi pregunta es, ¿habrá en Vue 2.0 alguna forma de detectar el final de la transición de CSS cuando usemos la transición combinada con v-show / v-if, posiblemente a través de un evento?

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

Me alegraría mucho ver algo como esto en el próximo lanzamiento de Vue :) gracias por escucharme

@sqal puedes hacer eso con ganchos de transición: https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

@dubcanada será compatible en la próxima versión (omitiendo datos al crear el elemento)

Gracias @fergaldoyle y @simplesmiler por tu pista para emitir.

No sabía, el padre puede escuchar los eventos que emitió el niño. Por supuesto, entonces tiene más sentido escuchar ese evento no burbujeante.

Hola a todos. Un poco de trasfondo: estamos trabajando con webgl y me gustaría hacer algunas interfaces en una superficie 3D. Esto significa que necesitamos renderizar una interfaz, por ejemplo, en un lienzo y luego convertir el contenido del lienzo en una textura.

¡He estado trabajando con Angular, React y Vue y para mí Vue tiene más sentido! Mientras leía sobre React, me encontré con el proyecto react-canvas. Lo interesante es que en lugar de transformar el DOM virtual en nodos DOM reales, lo dibujan en un lienzo.

Debido a que Vue 2.0 también está utilizando un DOM virtual, me preguntaba si también se puede hacer algo como esto.

Hola,

Solo una aclaración sobre la eliminación de .sync y cómo se vería un flujo de trabajo genérico para manejar accesorios en un componente genérico.

entonces, pasando de
<component :value.sync="some.value"></component>
a
<component :value="some.value" @update="updateSomeValue"></component>

¿Cuál es la forma recomendada de rastrear la propiedad value ?
En el caso más básico, parece ser

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

Pero, seguramente esto se basa en que el componente padre devuelve ese valor a la propiedad, por lo que cuando el componente lo obtiene nuevamente, refleja el cambio más reciente ...

¿Eso significa que ahora debemos hacer algo como esto?

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

Esto parece un montón de repetición para manejar la transferencia (y cambio) de un valor, notificar al padre que el valor ha cambiado y rastrear el cambio internamente, en caso de que el padre no propague el cambio.

¿O me falta un poco de reactividad mágica vue aquí?

Además, existe la posibilidad de que si hay muchos accesorios que manejar, esto podría complicarse bastante.
Casi podía verme trabajando en un componente de envoltura, donde los niños acceden a this.$parent.value para mutar directamente, y el componente de envoltura solo maneja los accesorios / calculados / relojes

@Towerful, ¿qué quieres decir exactamente con "rastrear el valor"? ¿Y por qué quieres un estilo de establecimiento ( this._value = newValue ) en lugar de this.$emit('value-updated', newValue) explícito?

El poder del flujo unidireccional es que el padre puede decidir no aplicar el cambio solicitado por el niño, o puede marcar al niño como "en espera" y aplicar el cambio más tarde (por ejemplo, después de verificar con el servidor).

@simplesmiler usando una propiedad calculada le permite v-model .
Y tener el setter & getter en 1 lugar hace que sea más fácil ir y ver la funcionalidad cuando el valor se actualiza, en lugar de tener diferentes formas de acceder al valor y mutar el valor dentro del componente, y dispersas por todo el código.
Si usa la forma explícita dentro de un modelo, y no usa establecedores, parece que el objeto methods va a estar desordenado con métodos de tipo updateValue para la plantilla, a diferencia de los métodos reales.

Supongo que se aplica cuando el usuario selecciona una opción en un componente, y el componente se basa en ese valor para mostrar lo que está seleccionado.
Está confiando en que el componente principal lo devuelva al componente para que pueda hacer eso.
A menos que, cuando el usuario seleccione una opción, active la actualización de la pantalla del componente manualmente. Lo que parece alejarse de la reactividad de Vue.
Entonces, al tener un valor interno para rastrear lo que 'debería ser', haga que la plantilla reaccione a eso. Use setters / getters para envolver la propiedad para rastrear cambios internos y generar eventos externos, y un reloj en la propiedad para actualizar el valor interno cuando se cambia externamente.

Quizás solo estoy luchando por entender la nueva forma de hacerlo.

@Towerful - No eres el único ...

Scott

@Towerful :

A mí me parece que lo que describe son esencialmente componentes que actúan como entradas con un v-model : el usuario cambia algún valor en la interfaz de usuario y desea que ese cambio se refleje en los datos vinculados de inmediato.

Para estos tipos de componentes, puede usar v-model en componentes 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
}

Esto hace que la interfaz con los elementos <input> reales y con los componentes de entrada personalizados sean esencialmente idénticos y un enlace bidireccional.

Para componentes más complejos que reciben múltiples accesorios (y no son simples entradas personalizadas, sino más abstractas), desaconsejamos usar .sync porque se vuelve difícil razonar en la mayoría de las situaciones.

El padre debe decidir qué hacer con un valor que recibe del niño, sus datos no deben cambiarse implícitamente como lo hace .sync .

¿Puede proporcionar un ejemplo que _no_ sea solvabel con el enfoque del modelo v anterior y aún así se beneficie del uso de .sync ? Esa puede ser una mejor base para la discusión que la teoría abstracta.

¡¿Cómo me perdí eso ?! Definitivamente está allí en el OP, ¡e incluso hay una discusión sobre esto hace algunos comentarios! Ahora me siento un poco estúpido.
¿Podría actualizarse la publicación original para dejar un poco más claro que v-model se puede usar en un componente?
@LinusBorg Fuera de mi cabeza, no puedo pensar en un caso en el que v-model en un componente no funcione. Me perdí esa parte de la publicación original.
Incluso para componentes de objetos complicados, sería solo una cuestión de anidar componentes. Y esto refuerza los componentes de responsabilidad única.
Tiene mucho más sentido :)

@Toroso

Re: usando v-model . La cuestión es que v-model es sincrónico (en cierto modo), mientras que el flujo de datos entre componentes es inherentemente asincrónico debido a la cola del observador ( demostración ). He visto que esto confunde a mucha gente. El flujo unidireccional solo hace que sea más explícito que los accesorios no son sincrónicos y te obliga a no confiar en que sean sincrónicos (esto es lo que estás tratando de engañar a tu manera).

Re: métodos desordenados. Para casos simples, siempre puede hacer @value-updated="value = $arguments[0]" . Para casos complicados, es bueno tener un método, donde puede ajustar el estado para mantenerlo consistente (por ejemplo, activar actualizaciones manualmente). Segway hasta el siguiente punto.

Re: alejarse de la reactividad. No estoy de acuerdo con esta afirmación. Para casos simples, no necesita magia para hacer que el niño recoja el valor, actualizado por value-updated="value = $arguments[0]" .

Para casos complicados, con .sync accesorios tendrías que usar watch , pero watch explícito no es realmente una parte de la reactividad. Es una trampilla de escape, donde activa sus actualizaciones manuales que no se pueden expresar como calculadas. Y no es bueno, porque no puede reaccionar a los cambios de forma sincrónica, como lo hace el cálculo. Esta es la razón por la que cuando se usa mucho watch , es posible que las actualizaciones de datos necesiten algunos "tics" para propagarse. Si alguna vez te has topado con nextTick directamente anidados, sabes de lo que estoy hablando.

Ahora, -updated handler proporciona una mejor escotilla de escape, permitiendo que los complicados cambios del modelo se apliquen sincrónicamente (o simultáneamente de forma asincrónica) después de que el niño exprese la intención, asegurándose de que el niño reciba valores actualizados en el siguiente tick (o no lo hará). recibir estado inconsistente).

@ yyx990803 ¿Podríamos implementar una forma de escuchar $ emits, similar a cómo teníamos eventos para $ dispatch y $ broadcast en vuejs1?

Se siente más vuejs-esque, algo como esto (un 'encendido' o 'escucha'):

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

Básicamente, esto se conectaría automáticamente al bus global.

Los Event Busses no son un patrón que queramos fomentar, solo son útiles en algunos casos extremos. Generalmente, se prefiere un patrón de tienda, como vuex.

Implementar una API que facilite el uso de un bus y se sienta "oficialmente respaldado" sería una señal incorrecta.

Mirando su ejemplo, si almacenó la cantidad en una tienda a la que acceden ambos componentes, no sería necesario ningún evento. La propiedad calculada en el componente container se actualizaría automáticamente.

Código de ejemplo simple sin usar una solución de tienda real como 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
    }
  }
})

Yo diría que la idea general de vue2 es hacer que sea más difícil dispararse
en el pie.

El domingo, 3 de julio de 2016 a las 11:24 a. M., Thorsten Lünborg [email protected]
escribió:

Los autobuses de eventos no son un patrón que queremos fomentar, es solo
útiles algunos casos extremos. Generalmente, se prefiere un patrón de tienda, como vuex.

Implementar una API que facilite el uso de un bus y se sienta "oficialmente
admitido "sería la señal incorrecta.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -230158828, o silenciar
la amenaza
https://github.com/notifications/unsubscribe/AACoukCpCgYlDbVej_w_h4NEhQ-imYHBks5qR9QwgaJpZM4IedHC
.

@kharysharpe $emit s están pensados ​​para ser escuchados con v-on en la instancia secundaria. Esto también tiene la ventaja adicional de poder acceder al contexto original de dónde se usa la instancia:

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

¿Hay una fecha para el lanzamiento 2.0? Estoy bastante emocionado con los cambios. ¡Felicitaciones!
Estoy pensando en usar Vue 2.0 + Redux.

@Sendoushi Aún no hay fecha para el lanzamiento final, pero la versión beta puede estar dentro de una semana. 😄 Vuex 2.0 también se está desarrollando en paralelo y no solo contará con una API mucho más simple que la actual vuex, sino que también se integrará en el ecosistema Vue mucho mejor que redux.

Vuex 2.0 también se está desarrollando en paralelo y no solo contará con una API mucho más simple que la actual vuex, sino que también se integrará en el ecosistema Vue mucho mejor que redux.

@chrisvfritz ¡ Es fantástico escucharlo! Siempre sentí que la API actual es un poco excesiva e innecesariamente complicada. Terminé teniendo que hacer cosas como esta para compensar:

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

¿Qué pasa con la hoja de ruta de vue 2 y vuex 2. Está planeado lanzarlos juntos o uno antes que el otro y qué pasa con las compatibilidades de las diferentes versiones?

En relación con la pregunta anterior, ¿cuál es el estado con vue-router? ¿Va a recibir compatibilidad con Vue 2 pronto o será necesario realizar las pruebas de Vue 2 sin el enrutador?

@gwildu Es probable que se publiquen algo juntos y Vuex 2.0 solo admitirá Vue 2.0. Pre 2.0 Vuex seguirá recibiendo soporte hasta que Vue 1.x ya no sea compatible.

@Uninen Vue Router recibirá algo de amor a continuación, antes del lanzamiento de Vue 2.0.

Gracias por el nfo @chrisvfritz :)

@chrisvfritz @Uninen corrección: Vuex 2.0 también funciona para Vue 1.x.

La próxima versión principal de vue-router solo admitirá Vue 2.x.

Compilación solo en tiempo de ejecución: dado que no incluye el compilador, necesita plantillas precompiladas en un paso de compilación o funciones de renderización escritas manualmente.

¿Hay / habrá alguna forma de precompilar plantillas sin usar vueify / vue-loader y .vue files? Si no es así, ¿sería una buena idea tener un plugin Babel para transformar template: propiedades a render funciones de los componentes?

Después de actualizar a 2.0, se pueden seguir utilizando las funciones obsoletas. ¿Puede actualizar primero a 2.0 y luego cambiar lentamente las funciones obsoletas?

¿Será posible crear un componente de terminal, ahora que elementDirective se ha ido?

Como se mencionó:

v-model ya no se preocupa por el valor en línea inicial. Siempre tratará los datos de la instancia de Vue como la fuente de la verdad.

Considere eso

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

¿Cómo puedo lidiar con la casilla de verificación con matrices entre componentes personalizados?

_Actualizado 1: _
Resuelto. Transfiera prop type="checkbox" al componente secundario en el componente principal.

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

Entonces puede obtener valor en línea a través de {props: [ 'value' ]} .
Emite un evento change al componente principal para indicar que el valor ha cambiado.

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

Esto se debe a que el compilador compila la directiva v-model acuerdo con su type . Y el compilador generará el checked prop y le vinculará un evento change .

_Actualizado 2: _
Sin embargo, el enlace del ciclo de vida updated no se activa debido a que v-model cambia directamente el atributo checked (Eso significa que no puede obtener un evento change de un componente de casilla de verificación html nativo modificando el valor de v-model ).
Entonces, @ yyx990803 , ¿puedes activar un evento change después de los cambios de v-model ?

@ YunSun-CN La única forma en que pude solucionar su problema fue agregar una propiedad específica para el valor, ala val, y usarla para establecer el valor real, y luego simplemente emitir cambios en la entrada del modelo v 'evento.

@johnleider Escribí una directiva personalizada para simular lo que hace v-model .
Por cierto, debe generar modelos de una manera estricta, no solo verificando type prop, sino también verificando el tagName del elemento. De lo contrario, otro componente personalizado con type prop puede sobrescribir su comportamiento de modelo predeterminado.

Hola. ¿Conocemos una fecha de lanzamiento?

@thanosalexander Aún no hemos decidido una fecha, no. Acabamos de introducir algunos cambios importantes en el sistema de transición con 2.0.0-bet.2, que deben probarse a fondo. Así que todavía pasarán un par de semanas hasta que podamos pensar en un lanzamiento, en mi opinión.

ok ... iré con esto entonces ... ¡no creo que el paso hacia el establo sea demasiado grande! gracias

¿Qué pasa con los docs? Una de las razones por las que Vue se adoptó temprano fue la documentación y es la única razón por la que me está frenando ahora con v2. Vi el problema al seguir los documentos, pero no veo que se acerque para terminar pronto. Probablemente estoy ignorando tantas cosas que suceden bajo el capó, por lo que surgió la pregunta :)

¿Algún plan para implementar el modo de transición fuera del cambio de componentes en 2.0?
https://github.com/vuejs/Discussion/issues/156

@ miljan-aleksic Docs estará listo cuando 2.0 se lance oficialmente. Todavía estamos en beta. ;)

Hasta entonces, puede seguir el progreso de la documentación aquí (o incluso contribuir)

@aristidesfl Ya hecho. 🎉

@ miljan-aleksic Además de lo que mencionó @LinusBorg , la mayor parte de la nueva guía ya está completa e incluso puede leer la fuente aquí si lo desea. Sin embargo, tenga en cuenta que, al momento de escribir este artículo, no se ha actualizado por completo para reflejar los cambios en la versión beta.2 , aún

También estamos de acuerdo en que la excelente documentación es una parte vital de Vue. Incluso Dan Abramov del equipo React ama nuestros documentos. 😄 Es por eso que uno de mis objetivos personales es que los documentos 2.0 sean _incluso mejores_. Mientras tanto, aunque ...

Para cualquiera que quiera aprender sobre 2.0 con anticipación, recomendaría las pruebas de unidades de funciones como el recurso más actualizado disponible.

Ese es uno de mis principales recursos para escribir documentación y, por lo general, son bastante legibles si está familiarizado con Jasmine.

Gracias @chrisvfritz , información muy útil. Daré una oportunidad a los nuevos documentos, teniendo en cuenta que es un WIP y los comentarios que sean necesarios. Es hora de tomar en serio Vue 2.0;)

createElement en la función de renderizado usando on no parece manejar matrices (como lo hace snabbdom) ¿hay alguna manera de pasar datos a las funciones llamadas?

Por ejemplo, en snabbdom puedo usar

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

Y function obtendrá dataToPass como primer argumento. Pero esto parece ser un error en vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function . ¿Hay alguna manera de pasar datos y el evento usando el elemento on from create?

@dubcanada, el manejo de eventos en Vue 2.0 es diferente al de snabbdom: debe realizar la función usted mismo. La sintaxis de la matriz simplemente adjunta varios controladores al mismo evento.

Estoy tratando de obtener el contenido de las tragamonedas como una cadena en lugar de representarlas. Con los nodos estándar hay una solución fácil, pero con Vnodes no encontré la manera. ¿Existe alguna solución alternativa?

@ miljan-aleksic Intenta renderizarlo, obteniendo el contenido del elemento con innerHTML , luego ocultando el elemento con display: none en css.

Gracias por la ayuda. Si lo renderizo, el resultado final sería diferente. Estoy creando un componente que envolverá su contenido secundario con una etiqueta pre y codificará el HTML.

En ese caso, renderice la salida en un elemento diferente del original.

Aunque señalaré que las plantillas no deberían ser su forma de escribir su contenido. Debe ser la forma de describir _cómo_ está escrito el contenido, y no el contenido en sí. Recomendaría almacenar el texto como una cadena en JS (o como un recurso en algún otro lugar de su proyecto, _especialmente_ si es una entrada del usuario de algún tipo), y luego pasarlo al niño como un accesorio, lo que debería hacer las cosas mil veces más fácil de todos modos.

Tienes razón @Kingdaro , lo mejor es no mezclar conceptos y hacerlo simple. Sin embargo, fue bueno tener la sintaxis hihgligthig :)

Cuando se utiliza el v-on Directiva, la $arguments variable no está disponible. No veo ninguna referencia sobre ese cambio aquí. ¿Hay un error o falta una referencia?

@ miljan-aleksic solo usa arguments .

Debe ser un desarrollador de PHP (como yo) ... Sé cómo te sientes. ¡JAJAJA!

Scott

@ yyx990803 , @smolinari yo soy ... y una avergonzada ahora jaja. Me hice creer a mí mismo que ya lo había intentado ... parece que no lo hice lo suficientemente bien. Está funcionando, gracias y perdón por perder su tiempo.

Estaba a punto de abrir un ticket sobre otro "problema" pero ya no estoy seguro de si es ... Al usar ref el componente o elemento registrado no está disponible de inmediato, por lo que algo como esto no funcionaría.

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

En el momento en que Foo se está renderizando, $refs.button aún no está definido. En Vue 1 está funcionando como se esperaba. ¿Qué me estoy perdiendo esta vez?

Le falta que no debe pasar elementos DOM o instancias de componentes como accesorios ...

¿Por qué es una mala idea? Digamos que tengo un componente desplegable que quiero conectar a un botón (el disparador). Ambos son componentes independientes y en lugar de conectarlos a través de una consulta, paso la referencia directamente.

@ miljan-aleksic es incluso mejor conectarlos a través del estado:

• el estado abierto / cerrado se mantiene en su padre común
• el padre pasa el estado al menú desplegable como apoyo
• el padre escucha el evento del botón para alternar el estado

De esta manera, el menú desplegable y el botón están completamente desacoplados, el botón se puede reutilizar para controlar otros tipos de componentes y el menú desplegable puede ser controlado por otros tipos de componentes de entrada.

No es fácil deshacerse de los viejos hábitos. ¿Debería culpar a jQuery o principalmente a mí? :D

Tu enfoque, Evan, es correcto. Iré por ese camino incluso si eso significa que la integración del menú desplegable sería más tediosa. Como el componente principal tendría que saber cómo escuchar los diferentes eventos, no solo sobre abrir sino cerrar el menú desplegable cuando se hace clic en el exterior, pero no el menú desplegable en sí mismo, etc. Muchos eventos y soluciones alternativas que el menú desplegable estaba resolviendo.

Como el componente principal tendría que saber cómo escuchar los diferentes eventos, no solo sobre abrir sino cerrar el menú desplegable cuando se hace clic en el exterior, pero no el menú desplegable en sí mismo, etc. Muchos eventos y soluciones alternativas que el menú desplegable estaba resolviendo.

¿Todavía puede? puede hacer totalmente addEventListener('body', ... ) desde el componente desplegable para registrar clics externos, etc. El menú desplegable puede simplemente emitir un evento de "cierre" para el padre cuando alguien hace clic en el exterior, por ejemplo.

Si si. Es hora de refactorizar algunos componentes :) ¡Gracias a todos! Comunidad impresionante.

¿Cómo se aplica v-model a un componente con createElement ? Eché un vistazo al código generado usando el compilador de plantillas y ... es mucho código. No entendí muy bien la documentación allí sobre directivas.

De forma predeterminada, una directiva en tiempo de compilación extraerá la directiva y la directiva no estará presente en tiempo de ejecución. Si desea que la directiva también sea manejada por una definición de tiempo de ejecución, devuelva verdadero en la función de transformación.

@blocka , no tiene acceso a las directivas integradas si está utilizando la función render . Tendrá que manejar la lógica equivalente usted mismo. Por ejemplo, v-if es solo una expresión ternaria, v-for es una expresión array.map() ... y v-model (en un elemento <input> normal ) se traduce en un enlace value y un detector de eventos input .

@ yyx990803 eso es lo que pensé. Probablemente terminaré manejando eso con un HOC (ya estoy entregando condicionales de la misma manera (aunque estoy pensando en usar esto )

Con vue 1, hubo dos ventajas declaradas de vuex frente a redux.

1. El rendimiento es mejor a medida que vuex muta el estado, que funciona mejor con vue (reemplazar el estado anterior tenía un rendimiento equivalente a "verificación sucia")
2. Vuex es más "consciente" de que está en una aplicación vue

¿El uso del dom virtual mitiga parte o la totalidad de 1?

@blocka mitiga algo, pero el rendimiento general seguirá siendo mucho mejor que con Redux.

Lo que cambió en 2.0 es la granularidad de la reactividad. Hagamos una comparación:

• En Vue 1.x, la reactividad es muy fina. Cada directiva y cada enlace de texto tiene un observador correspondiente. Esto da como resultado actualizaciones detalladas cuando cambian los datos, pero a costa de una mayor sobrecarga de seguimiento de dependencias en el procesamiento inicial y un uso de memoria ligeramente mayor.
• Con Redux, la reactividad no tiene granularidad en absoluto. Siempre que algo cambie, es necesario volver a renderizar toda la aplicación. En React, el enlace de Redux realiza alguna optimización en los contenedores conectados, pero el usuario aún necesita implementar ampliamente shouldComponentUpdate para obtener un mejor rendimiento.
• En Vue 2.0, la reactividad tiene una granularidad media. Cada componente tiene un observador correspondiente que realiza un seguimiento de las dependencias de ese componente. Cuando los datos cambian, solo los componentes que dependen del cambio necesitarán volver a renderizar su DOM virtual. Este es esencialmente el mejor escenario para React, pero no necesitas hacer nada para lograrlo en Vue 2.0.

Generalmente con 2.0, verá (en comparación con 1.x)

• Actualizaciones ligeramente más lentas (pero aún muy rápidas) para pequeños cambios de datos
• Actualizaciones decentemente más rápidas para cambios de datos medianos a grandes
• render inicial significativamente más rápido

Oye,
No consigo que las transiciones con animated.css funcionen.

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

¿Alguien tiene una idea?

Tus nombres de utilería están equivocados.

camelCase vs kebap-case todavía se aplica en 2.0.

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

@LinusBorg Lo siento, ya lo intenté. Aquí tengo un pequeño violín. Con las transiciones CSS y la etiqueta de nombre, funciona bien.
https://jsfiddle.net/z0nyfba0/

Al usar v-model en un componente, ¿el componente tendrá visibilidad de los modificadores que se usen con v-model ?

por ejemplo, si tengo un componente que emite un evento input , cuándo se emite ese evento depende de si se usa o no el modificador lazy .

@fergaldoyle jugué un poco con esto y creo que no puedes usar modificadores de v-model en un elemento personalizado ya que necesitas emitir manualmente un evento de entrada. Si desea lograr un comportamiento perezoso, debe vincular el evento change a la entrada, por ejemplo, https://jsfiddle.net/cynhtLty/1/

@calebboyd

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

1. Tienes que usar enter-active-class y leave-active-class
2. Tienes que poner class="animated" en el elemento <router-view> .

@fergaldoyle De acuerdo con los documentos 1.0, creo que con lazy , v-model simplemente reaccionaría a change lugar de input . Puede usar esto para cambiar el comportamiento y emitir input o change para dar los diferentes resultados dependiendo de si se da lazy o no.

Me he estado rascando la cabeza mientras jugaba con un simple ejemplo de v-for . Por alguna razón, el enlace value no funciona para los elementos select en 2.0: https://jsfiddle.net/972eL5fL/

Además, probablemente debería tenerse en cuenta en los documentos que los rangos de v-for como "i in 10" comienzan desde 1 en lugar de 0 como en 1.0.

@lauritzen

Me he estado rascando la cabeza mientras jugaba con una v simple, por ejemplo. Por alguna razón, el enlace de valores no funciona para elementos seleccionados en 2.0: https://jsfiddle.net/972eL5fL/

Parece funcionar como se esperaba para mí, ¿qué no funciona para ti?

Anuncio de servicio publico

Le recomendamos que haga preguntas de soporte en el foro o en gitter .

Este problema debe reservarse para las discusiones sobre la nueva API. Si manejamos el soporte para varias preguntas aquí, esto se saldrá de control.

Gracias.

¿Por qué vm. $ Get ha quedado obsoleto?
¿Por qué no Vue.get en su lugar?
Es muy útil para evaluar exresiones calculadas como esta.
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

@iagafonov no hay muchos escenarios en los que esto sea útil, por lo tanto, no debería ser parte del núcleo.

Si necesita la funcionalidad para uno de los pocos escenarios, puede agregar muy fácilmente un comportamiento similar con la ayuda de, por ejemplo, lodash:

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

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

(por supuesto, también puede agregarlo como "método de clase" como Vue.get (), o simplemente importarlo localmente donde lo necesite, su elección)

@LinusBorg. En primer lugar, no uso lodash o algo como esto.
En segundo lugar, la implementación de lodash es lenta, porque está en tiempo de ejecución y trata de profundizar en la estructura de expresión. vue cumple la nueva función especificada (por parseExpression), enlazada al alcance.
No es una parte trivial, es muy difícil volver a implementar esto.
Por supuesto, $ get compile la función cada vez). Sería bueno si parseExression fuera parte de api en Vue.util, por ejemplo.

@iagafonov this.$get también tiene que analizar la ruta en tiempo de ejecución y recuperar el valor dinámicamente. De lo contrario, obtendría un error si la ruta no existe. Además, la diferencia de rendimiento será insignificante en la mayoría de los casos. Si no desea lodash, existen muchas otras bibliotecas de recuperación de rutas. Simplemente ya no es parte de la preocupación de Vue.

¿Cuáles son algunas alternativas a los atributos param ahora obsoletos?

¿Estás hablando de parámetros en una directiva? Luego puede encontrar todos los atributos enlazados dentro del objeto vnode

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

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

@sqal , ¿es esto en respuesta a mi pregunta? Si es así, estoy hablando de atributos param como lazy, number y debounce. Por ejemplo, antes de 2.0, podía hacer esto <input type="text" v-model="msg" number> (el número es un atributo param aquí). ¿Cómo puedo obtener los mismos resultados sin usar el atributo param?

@ p-adams se menciona en la publicación; ahora son modificadores <input v-model.number="msg">

Encuentro en Vue 2.0, cuando los accesorios cambian, la función de renderizado siempre se llama, así que me pregunto si 2.0 será compatible con shouldComponentUpdate para decidir si volver a renderizar.

@ yyx990803 Bien, lo veo ahora en la publicación The lazy and number params are now modifiers .

@HeChenTao Evan explicó esto un poco aquí https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

@HeChenTao la función de renderizado no es "siempre" llamada, solo cuando es requerida:

• Vue no necesita shouldComponentUpdate , debido a su reactividad.
• Cuando se cambian los datos reactivos que se utilizan en un componente, esto activará la función de render, vdom diffing y así sucesivamente.
• Pero si ninguno de esos datos cambió, la actualización no es necesaria y la función de renderización _no_ será llamada.

Lo mismo se puede hacer reaccionando con mobx. Estoy bastante seguro de que no es necesario implementar shouldComponentUpdate . Sin embargo, como vue, mobx insiste en un estado mutable. Si, por alguna razón, ha comprado el concepto de estado inmutable. En ese caso, reaccionar te respalda con shouldComponentUpdate .

Entonces, ¿eso significa que si alguien insiste en un estado inmutable, vue no va a ser una buena combinación?

El argumento de contexto de los componentes funcionales tiene children más slots . Me resulta un poco confuso saber que children() y slots().default exactamente lo mismo. Me hace preguntarme cuál es el enfoque correcto. Probablemente 'niños' como tragamonedas es vago, pero aún así, ¿por qué apoyar dos formas diferentes de obtener el mismo comportamiento?

Los componentes funcionales son solo funciones y, por lo tanto, no tienen hijos. En mi humilde opinión, los niños deberían estar en desuso y mantener las tragamonedas como no perezosos.

@blocka puede implementar datos reactivos en reaccionar con mobx, cierto. Pero la reactividad es el núcleo de la funcionalidad de Vue. Entonces, si esa no es la taza de té de uno, esa persona está en la fiesta equivocada.

@ miljan-aleksic children está en bruto (obtienes cada nodo sin importar en qué ranura deben ingresar), slots se resolverá en función de slot nombres en los hijos entrantes.

Gracias @ yyx990803. Quizás más detalles sobre esto en los documentos evitarían confusiones, @chrisvfritz.

@ miljan-aleksic Agregaré una nota. 👍

Con respecto a los filtros, usar una propiedad calculada parece bastante sencillo, pero cómo manejar el caso de usar un filtro con el modelo v. Si uno quiere filtrar a través de una lista de nombres escribiendo en el campo de entrada, ¿cómo se puede hacer esto en 2.0?

¿Piensa que Vue advierte cuando un campo de datos / propiedad calculada no se está utilizando en una plantilla? Imagino que hay algunas limitaciones aquí, pero sería muy útil saber dónde podría permitirme sacar algunas importaciones inútiles de la tienda donde no son necesarias.

@ yyx990803 , ¿qué opinas sobre la configuración de $context referencia al prototipo de componente? Al igual que con $parent o $root me encontré accediendo a menudo al contexto que actualmente solo está disponible a través del objeto $vnode .

En realidad, esa no parece ser una forma confiable de acceder al contexto. ¿Cómo se debe hacer?

@ miljan-aleksic ¿Puede compartir los casos de uso en los que accede con frecuencia al contexto?

@Kingdaro ¿Puedes abrir un problema para eso? Suena bien si es factible.

@ p-adams Aún puede usar una propiedad calculada con Array.prototype.filter .

@chrisvfritz , básicamente para soluciones como, por ejemplo, establecer variables en el contexto que espera el niño. O para establecer una referencia al componente antes de lo que hace Vue.

Estoy de acuerdo que no es común para todos, pero al menos debería haber una forma confiable de acceder a él dentro del componente. El $ vnode no está presente hasta que el componente se monta cuando se usan plantillas (al menos mi conclusión hasta ahora).

Me contentaría con saber cómo acceder a él de manera adecuada.

Otra situación en la que $context sería útil es cuando se reutiliza un componente como raíz de otro componente.

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

En el ejemplo child.$parent devolvería el componente Foo en lugar de Bar, lo cual es correcto, pero si el padre y el hijo son dependientes el uno del otro, una comunicación directa entre ellos podría ser a través del contexto.

@ miljan-aleksic Dejaré este a @ yyx990803. Yo diría que al igual que con $parent , llegar a $context probablemente será incorrecto el 99,9% de las veces y creo que probablemente nunca lo usaría.

Tengo una situación con v-show y transiciones. En este escenario, hay un modal que de forma predeterminada es 'mostrar: ninguno' en el CSS. Cuando se combina con v-show , nunca se mostrará porque la directiva elimina la propiedad de visualización, las de CSS persisten. No puedo cambiar el CSS (requisitos del proyecto) y no puedo usar una directiva personalizada, ya que parece que las transiciones de Vue se basan específicamente en ella.

Ahora estoy pensando que una directiva que se evalúe justo después de v-show podría establecer la propiedad de visualización en bloque. Necesito probar eso, pero de todos modos podría ser una buena idea agregar un modificador a v-show para permitir configurar la pantalla para bloquear o inline-block. Solo un pensamiento.

@chrisvfritz , ¿se espera que para los componentes funcionales la referencia principal no sea la principal inmediata donde se utilizan como ranuras, sino el componente de contexto?

La compilación de la plantilla falla si contiene "<" (y posiblemente otros caracteres sensibles a html) en 2.0.0-beta7

https://jsfiddle.net/x0r59ur1/

Esto funcionó en 1.0.26.

Escapar "<" con "<" resuelve el problema.

@GlurG se espera que escape "<" correctamente.

@ yyx990803 , si quiero usar transiciones en una lista de componentes del mismo tipo y mantener su estado, ¿cómo debo hacerlo? Siguiendo los documentos solo veo cómo cuando los componentes son diferentes.

Digamos un componente Tab y la transición de sus elementos. No puedo encontrar una manera :(

<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> es solo para un elemento. Necesita <transition-group> para varios elementos.

@ yyx990803 , probé ese también, pero todavía no veo cómo lograrlo. El grupo de transición funciona agregando / eliminando elementos, pero mientras lo hace, los componentes se iniciarían nuevamente, perdiendo el estado. Además de la idea de una pestaña es mostrar solo un componente a la vez, no es exactamente una lista :)

@ yyx990803 , @LinusBorg Agradezco la ayuda pero la solución no es obvia. Sé cómo se aplican las transiciones, lo que no puedo imaginar es cómo keep-alive los componentes de transición.

He creado un nuevo problema en aras de la claridad con el ejemplo de jsfiddle sobre cómo se crean los componentes cada vez.

@ yyx990803 , muchas gracias por mejorar la función Keep-

Literalmente estás cambiando mi vida, con tus productos y la ética laboral puedo aprender, construir y entregar productos que tenía mucho tiempo en espera. Con su enfoque simple, la alta tecnología está disponible para que todos la usen y la aprovechen. Por todo eso y más estoy eternamente agradecido.

@ miljan-aleksic Hay un guiño guiño de campaña de Patreon .

Sabes lo que @phanan , tienes toda la razón. Comencé a apoyar a Evan personalmente y tan pronto como los productos de la compañía comiencen a dar resultados, me aseguraré de que el apoyo sea más notorio.

El gancho del ciclo ready vida mounted ; pero de acuerdo con el registro de cambios, no hay garantía de que el componente se procese antes de llamar a mount. Esto causa errores esporádicos cuando quiero inicializar ciertos componentes de jquery (como selectize) después de que el componente se haya inicializado. ¿Qué gancho de ciclo de vida debería usar en su lugar? ¿Se puede emular el gancho "listo" así:

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

@GlurG Sí, eso funcionará. Y, por cierto, eso también fue necesario con ready'() en 1.0 en muchos casos.

¿Hay alguna razón por la que no pueda haber un gancho para esto independientemente? Yo tambien
a través de esto ... incluso en 1.0, y recurrió a cosas como bucle con raf para
compruebe si está en el dom, etc.
El 10 de agosto de 2016 a las 6:26 p. M., "Thorsten Lünborg" [email protected]
escribió:

@GlurG https://github.com/GlurG Sí, eso funcionará. Y por cierto,
eso también fue necesario con ready '() en 1.0 en muchos casos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -238903012, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AACounAoI8p65soUUrbdaiwteDXKgMGJks5qee25gaJpZM4IedHC
.

Cuando se usan las funciones de renderizado, se ignoran las directivas centrales, lo cual es razonable. Pero algunos no son tan fáciles de reproducir usando js simples, como v-model que tiene soluciones para IE9 y probablemente resuelve otros problemas de casos extremos.

Te hace reconsiderar el uso de una plantilla en su lugar, pero eso no es posible o es la mejor opción en algunas situaciones. Los documentos definitivamente podrían ofrecer más orientación sobre este tema y, además, podría ser una buena idea tener algún ayudante al trabajar con funciones de renderizado que ayudaría a resolver estas situaciones comunes y hacer que nadie se pierda una plantilla.

@ miljan-aleksic lo siento, eliminé mi comentario porque noté que solo funciona para v-show o directivas personalizadas, y sí, como dijiste en el caso de v-model, es necesario agregar entrada / cambiar oyente y actualizar nuestros datos manualmente

¿Se supone que se debe llamar al nuevo gancho activated cuando se activa una ruta que activa / monta un router-view ? No veo este comportamiento actualmente.

@wprater no, está relacionado únicamente con <keep-alive> y nada más.

@ yyx990803 Estoy envolviendo mi vista de enrutador en un mantener vivo, pero parece que no puedo encontrar un gancho para cuando vuelvo a la vista anterior. mounted ni activated son llamados. Necesito estar seguro de que se renderiza el dom.

@wprater , evite usar este hilo para preguntas no relacionadas. Si hay un error, archive el problema en el repositorio correspondiente con la reproducción.

¿Vue JSX admite el operador de propagación de objetos? Lo he probado pero no funciona.

Lo hace y @ yyx990803 hizo un gran esfuerzo para que funcione.

Estoy haciendo esto <Component {...{ props } }></Component> y funciona como está documentado.

@blocka ¡Gracias! Pensé que el nombre de la propiedad props no era necesario 😂

@ yyx990803
components opciones

p.ej

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

¿Es un error?

@ QingWei-Li simplemente ya no son compatibles, ya que nunca fue una característica documentada oficialmente. La razón es que con ES2015 solo puede escribir components: { Parent, Child } .

solo una pequeña sugerencia,
¿Hay alguna posibilidad de que la iteración de matriz normal use v-foreach y para el rango usamos v-for ?

que tendrá más sentido para los usuarios provenientes de php e incluso consistente con .each en JQ o foreach en JS

@ ctf0 Estamos en etapa RC, la API ya no cambiará. Y tampoco introduciremos una sintaxis alternativa para hacer lo mismo.

No creo que la sobrecarga mental de v-for="item in items" sea ​​lo suficientemente significativa como para justificar eso.

Con esta nueva versión, manejaría este caso.

Tengo un componente de calendario (procedente de la interfaz de usuario semántica), que utiliza una entrada de texto clásica y muestra la fecha en un formato humano (como "10 de julio de 2016", por ejemplo). Con v1.0, estaba usando un filtro bidireccional para convertir esa cadena en una fecha adecuada para que los datos de mi objeto estuvieran directamente listos para enviar. Pero dado que los filtros ya no funcionarán en v-model, ¿cómo podría hacer lo mismo ahora en v2.0?

Gracias

@shadowRR ¿sería posible ver algún código?

@ p-adams Seguro. Aqui tienes.

Primero, mi filtro, que se usa en mi modelo v para la entrada de mi calendario. Su único propósito es escribir, cuando el valor cambia, un tipo de fecha adecuado para mis datos (fecha de postgres).

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

Y lo usaría así en mi componente (la entrada tiene un sistema de calendario que devuelve mi fecha en el formato legible por humanos)

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

Recomendaría leer la publicación de @ yyx990803 aquí: https://github.com/vuejs/vue/issues/2756 donde analiza los filtros bidireccionales en v-model . Además, puede ser mejor hacer preguntas como esta aquí: http://forum.vuejs.org/

Me perdí la publicación de la que estás hablando, lo veré, gracias;)

Hola,
Tengo algunas dudas sobre los nuevos ganchos del ciclo de vida.
Si quiero registrar un controlador de eventos cuando está montado y anular el registro antes de desmontarlo, ¿cómo debo hacerlo funcionar? Agregar controles y lógicas en los ganchos creados y anteriores.
En Vue 1.x, usaría ganchos adjuntos y separados.
Pero en 2.0 hay un gancho montado pero no un gancho desmontable. Se siente un poco no correspondiente.
¿Hay alguna razón por la que no se proporciona un gancho de desmontaje?

@ f15gdsy mounted corresponde a destroyed . No hay attached / detatched contrapartes en 2.0; debe hacer la verificación interna usted mismo. Si sus eventos no se preocupan por in-dom / off-dom, entonces mounted y beforeDestroy son los lugares apropiados para hacerlo.

Cuando se usa en un componente personalizado, v-on ahora solo escucha los eventos personalizados $ emitidos por ese componente. (ya no escucha eventos DOM)

Es posible que me haya perdido algunas publicaciones aquí, pero ¿cuál es la decisión de diseño detrás de esto?
Haría que la vinculación de eventos de clic simple en componentes sea muy detallada.

1.0:

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

2.0:

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

@fnlctrl , usa el modificador nativo: @click.native="bar" .

@ miljan-aleksic ¡Muchas gracias! Creo que este modificador debería agregarse a Directives -> v-on -> modifiers en este número

¿Puedo usar Koa (1.xo 2.x) como servidor? ¿Hay algún problema en vue-server-renderer con 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>

¿Por qué no llamar al gancho de entrada?

@fundon Debes hacer la pregunta en los foros o en el chat de gitter

Bloqueando este hilo porque:

1. Ahora estamos en la congelación de API en RC, por lo que este documento ya no se actualizará.
2. Demasiada gente está usando esto como un hilo de preguntas frecuentes generales, que no es para lo que es.

Si tiene un error, abra un problema por separado siguiendo la guía de informes de problemas; si tiene alguna pregunta, utilice el foro o gitter.

Actualización : para obtener una lista más definitiva y detallada de los cambios en 2.0, consulte la nueva guía de migración .