Vue: 2.0 Mudanças

Acabei de ver que certos recursos só estarão disponíveis na versão autônoma . Isso significa que esta e a versão do NPM são significativamente diferentes?

@rekateka 2.0 significa compilar autônomo (compilador + tempo de execução). A exportação padrão do pacote NPM será apenas em tempo de execução, porque se estiver instalando a partir do NPM, você provavelmente irá pré-compilar os modelos com uma ferramenta de construção.

Obrigado, @ yyx990803. Ainda tenho mais algumas perguntas sobre o compilador e outros recursos, mas usei o fórum para isso.

Há alguma alteração preocupante feita nos documentos que devo revisar por acaso? Ótimo trabalho! Continue assim, cara. Você está redefinindo o desenvolvimento web. Obrigada!

Posso obter this.arg da minha diretiva?

Vejo que vnode.data.directives tem arg , mas quando tenho duas ou mais diretivas, não posso saber a 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">

Devo usar forEach ? Obrigada!

@banricho bom ponto, isso foi esquecido! Consulte a assinatura da função de diretiva atualizada.

Em primeiro lugar, desculpe, não tenho certeza se poderia perguntar esse problema aqui, e tenho alguns requisitos que gostaria de dizer.
O requisito é que eu possa projetar o uso do meu componente assim

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

Espero que as crianças possam ser como algum tipo de argumento, não apenas limite em atributos
Por enquanto posso fazer um componente, o uso como

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

Mas acho que não é muito bom, espero que goste deste que fiz antes no coverflow do React

@andyyou - essa questão provavelmente é melhor postada no fórum, já que não é um problema, nem uma sugestão clara, nem qualquer ajuda real para esse problema.

http://forum.vuejs.org/

Se você descobrir que seus requisitos não podem ser atendidos com o Vue em seu tópico de fórum, você pode abrir um novo problema aqui.

Scott

@smolinari Obrigado

"Mas para casos mais complexos, é recomendável introduzir uma camada de gerenciamento de estado dedicada usando o Vuex." Isso parece implicar que o estado deve ser usado sobre os eventos. Eu os vejo como completamente separados - um evento é um momento no tempo, ao passo que o estado não muda. Você poderia dizer que poderia observar o estado, mas isso também não transmite um momento específico, mas sim sempre que algo muda. Estou interessado no significado por trás desta recomendação.

@jrenton Geralmente, podemos considerar o sistema de eventos simplesmente como o componente A dizendo ao componente B para mudar seu estado, ou A dizendo a B para fazer outra coisa.
Portanto, para o primeiro caso, podemos usar o gerenciamento de estado (gerenciamento de um estado compartilhado para A e B) em vez de usar o sistema de eventos para permitir que A diga a B para mudar de estado.
Para o segundo caso, acho que pode ser tratado muito bem com a abordagem de 'barramento de eventos'.

@jrenton em vez de uma sopa de componentes conversando entre si, a Vuex sugere um único canal para que os componentes expressem "intenções" com ações e registrem "fatos" com mutações.

Estou usando o Twig junto com o Vue.

Até agora (vue 1.0), passei dados para meus componentes assim:

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

(Observe que {{ e }} são tags de galho - por enquanto, estou usando delimitadores personalizados ${ e } )

Se estou entendendo as coisas corretamente, no Vue 2.0 devo fazer assim:

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

@gholol não é só

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

Na verdade, parece que seu uso antigo não deveria funcionar.

Bem, funcionou bem ...

Como eu disse, os dados vêm do mecanismo de modelagem de galhos. Agora, no Vue 2.0, ele não funciona. Tenho tentado passar como você disse (sem apóstrofos simples), mas a propriedade de dados fica indefinida.

Erro: SyntaxError: missing} após a lista de propriedades

EDIT: Funciona, esqueci de mencionar que a variável DATA é uma string

@jrenton Minha ideia e motivação são bastante simples, parece que a Vue não gosta do React que nos obriga a usar JSX. Podemos escolher muito template .

Espero poder usar a sintaxe do elemento filho como parâmetro (argumentos) para passar args para o pai, porque em alguma linguagem de modelo como slim se você tiver muitos atributos ou dizer que o nome do attr é muito longo, temos que colocar todas as coisas em uma linha. é mais fácil criar código de uma linha com mais de 80 caracteres.

@ yyx990803 Me sentindo aventureiro hoje, queria ver quanto esforço seria necessário para migrar alguns 1.0 para 2.0a, infelizmente, uma vez que não é mais possível usar interpolação simples, como eu faria algo simples como <input type="text" name="account[categories][{{ category.id }}]"> em 2.0?

Os modelos inline ES6 funcionam em expressões de ligação:

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

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

Se essa é a única maneira de fazer isso funcionar no 2.0, então não se importe que eu diga que isso é uma regressão na adorável sintaxe 1.0 com a qual nos acostumamos - sim, eu sei que é apenas ES2015.

Presumo que a interpolação foi removida por motivos de desempenho. Só espero que valha a pena usar a sintaxe mais feia.

@oskarkrawczyk Presumo que você queira terminar com algo como name="account[categories][fruits]" em seu DOM, porque isso é o que sua expressão renderizaria.

A versão 2.0 (e a própria 1.0, na verdade) será :name=" 'account[categories][' + category.id + ']' " .

@simplesmiler Entendido. Acho que {{ }} me estragou um pouco.

@ yyx990803 posso inserir componentes dinamicamente, assim?

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

Como posso vincular alguns valores para um atributo que depende da expressão? Por exemplo:

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

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

Espero o próximo resultado:

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

@nervgh, este não é o lugar certo para fazer essa pergunta.
Use a expressão ternária, v-bind:placeholder="flag ? 'test' : 'test2'" .

@simplesmiler , obrigado pela sua resposta. Tento dizer que _Object-Syntax_ será útil nesses casos, mas não funciona como eu esperava.

A sintaxe do objeto class , e para os componentes não haveria maneira de detectar do lado filho se você pretendia enviar uma lista de strings ou um objeto apropriado.

Re: .once e .sync estão obsoletos.

Isso não quebra os padrões de design realmente comuns?

Não consigo imaginar como você seria capaz de ter componentes simples para lidar com campos de formulário sem eles.

Eu tenho componentes simples para diferentes tipos de campos de formulário, por exemplo, aqui está o meu modelo de componente "caixa de texto":

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

... e também um componente mais complexo para listas que fornece uma interface do usuário para adicionar e remover elementos de matrizes na estrutura de dados

Então eu uso esses componentes, por exemplo:

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

Observação: todos esses componentes têm dois adereços: data e type . data é o nó na estrutura de dados que está sendo editado que o componente é responsável por fornecer uma IU para edição, e type é o nó na estrutura de dados (massiva, estática) que contém os tipos hierarquia de / campos.

Como coisas assim funcionam sem .sync ?

Parece-me que complicaria muito as coisas criar algum tipo de sistema de mensagens entre esses componentes, onde os subcomponentes podem de alguma forma comunicar ao pai qual subcomponente eles são, e o pai pode então descobrir que parte de seus dados estrutura para modificar.

Eu realmente espero que esteja faltando alguma coisa ... porque parece que você está dizendo que usar componentes para criar editores para partes de sua estrutura de dados é um antipadrão. O quê? Até agora, foi a única coisa para a qual usei o Vue. Suponho que você pense que a remoção desse recurso encorajará as pessoas a escrever um código mais limpo. Talvez tenha esse efeito em algumas pessoas, mas muitas pessoas escreverão um código muito mais desagradável para contornar essa limitação. Modificar o estado é a única coisa útil que os computadores fazem. Continue para tornar isso mais fácil.

@JasonWoof v-model em 2.0 pode funcionar em componentes personalizados. O componente simplesmente precisa:

1. expor um objeto chamado value
2. emite um evento input quando o valor precisa ser sincronizado com o pai, por exemplo, this.$emit('input', value)

Veja o exemplo .

@ yyx990803 Obrigado pela explicação e link. Agora estou preso em:

Por que remover .sync ?

Não vejo vantagem, apenas desvantagens. O exemplo que você vinculou mostra que você pode conseguir a mesma coisa com :selected.sync ou v-model . Só vejo desvantagens para o método do modelo v:

1. Requer uma placa de caldeira significativa no lado do subcomponente, é mais complicado, mais para aprender, etc.
2. Você só pode passar um valor com o modelo v, mas pode ter vários .sync props

Não vejo como mudar para o modelo V torna as coisas mais claras / limpas. Em ambos os casos, a única indicação no pai de que o componente filho pode modificar facilmente o estado do pai é a sintaxe do prop no modelo. Eu até diria que .sync é mais claro.

A outra coisa é que quando você passa objetos / arrays / etc como props, eles são mutáveis ​​do componente filho. Portanto, você não pode impedir que os programadores sejam capazes de alterar o estado dos componentes filhos neste caso (o que eu suponho ser muito comum). Então, parece-me que você está introduzindo um obstáculo ao remover o que o torna tão comum. passar valores de string funciona da mesma forma que passar valores de objeto. .sync torna meu código mais simples e mais consistente, sempre tendo meus props de "dados" graváveis ​​do lado filho, não importa o tipo de dados.

Eu sou novo no Vue.js (3 dias atrás), mas pelo que posso ver até agora, o Vue.js é valioso principalmente por causa de duas coisas:

1. fácil manipulação de dom com modelos
2. propagação automática de valor / mudança de dados, incluindo o acionamento de mudanças de modelo

Pelo menos é o que descobri até agora.

Parece-me que remover .sync torna difícil fazer com que o Vue.js faça o segundo consistentemente.

@JasonWoof porque os efeitos colaterais explícitos vs. implícitos fora do escopo dos próprios componentes fazem toda a diferença na capacidade de manutenção de longo prazo.

... e embora se possa argumentar que as pessoas simplesmente deveriam aprender quando não usar .sync , nossa experiência até agora é diferente. as pessoas tendem a confiar muito nisso e a criar códigos que dificilmente poderão depurar posteriormente.

portanto, esta é uma decisão de design para forçar as pessoas a fazerem tudo certo desde o início.

um exemplo:

• Sincronizamos um valor name entre um pai e um filho. tudo está bem.
• nós decidimos _'hey, quando esse valor muda, precisamos fazer algo no pai! '_
• Portanto, criamos uma função watch . Agradável!
• Mais tarde, percebemos que o observador parece atirar quando não queremos. Mas não podemos realmente dizer o porquê, porque não podemos realmente colocar console.log() qualquer lugar para rastrear o comportamento.
• Depois de muito pensar, percebemos que _realmente_ só queremos que _algo_ aconteça quando o valor é alterado no pai, não no filho ou no "avô".
• Agora tentamos encontrar uma maneira de diferenciar esses cenários na função watch alguma forma.
• Só para perceber que isso torna uma coisa simples muito complicada
• e no final, alguém nos diz para remover a sincronização, então jogamos tudo fora e usamos um suporte unilateral e um evento emitido para lidar com a situação - o código se torna mais simples e explícito, então é simples raciocinar sobre como e quando os dados fluem e fica mais fácil depurá-los. O bug é encontrado rapidamente e podemos seguir em frente.

... e isso se torna ainda mais louco quando você sincroniza mais de um nível de profundidade.

Este é um (anti) padrão que vimos repetidamente nos fóruns e no gitter chat.

A remoção de .sync força as pessoas a escrever um código claro, explícito e sustentável desde o início, porque seu código não permanecerá simples o suficiente para .sync por muito tempo, na maioria das vezes.

OK. Obrigado por explicar.

É bom saber qual é o problema que você está tentando resolver.

Eu duvido seriamente que isso vá ajudar ... Faça com que as pessoas não possam quebrar facilmente os padrões que você gosta e as pessoas façam coisas muito piores para contornar as limitações.

Isso me lembra muito a abstração. As abstrações nos colocam em muitos problemas. Eles tornam o código difícil de ler, difícil de depurar, etc ... Mas você não pode consertar isso tirando a capacidade de fazer abstrações ... isso é basicamente o que torna a programação possível / útil. A solução para isso não está no nível de linguagem ou estrutura, mas no ensino, aconselhamento, aprendizagem. Encorajamos as pessoas a não tornar as coisas excessivamente abstratas.

Parece-me que você está falando sobre essa filosofia de design. Em muitos casos, é uma ótima filosofia para se manter em mente durante a codificação. Mas quando isso é imposto como uma limitação, e o programador pensa que essa limitação o impede de fazer o que precisa fazer, então ele vai contornar isso, o que resultará em todos os problemas que você estava tentando evitar e pior.

As pessoas não vão parar de tentar transformar o estado dos pais dos filhos. Você não pode forçar as pessoas a não fazerem isso.

Sua v-model coisa é complicada o suficiente para que eu pudesse contornar esse problema passando o objeto / matriz pai e uma chave para que o filho possa modificá-lo.

Acho que essa última parte é o cerne do que estou tentando transmitir: Eu (pessoalmente) vejo a falta de .sync como um problema e irei contorná-lo ou não usarei sua estrutura. Aposto que muitas pessoas terão a mesma abordagem.

Talvez nem seja preciso dizer, mas fico um pouco zangado quando as pessoas tentam me impor filosofias de design. Prefiro construir coisas que vão terrivelmente erradas e aprender a não fazer isso de novo do que usar sistemas que retêm o poder propositalmente por medo de que eu possa usá-lo mal.

PS Desculpe, não posso evitar, mais um comentário, depois vou deixar vocês em paz. A maioria dos programadores escreve código que não pode depurar. Isso acontece com todos os programadores em todas as linguagens com todos os frameworks. É assim que os programadores se tornam melhores programadores: eles cometem erros, fazem códigos que não podem consertar, aprendem a escrever coisas de maneira diferente no futuro. Por favor, não empurre o seu framework para todos na tentativa de fazê-lo de forma que os programadores que se abstraem no canto possam tornar suas coisas um pouco mais confusas / complexas antes que se tornem uma bagunça que eles não possam depurar.

@JasonWoof não tem nada a ver com "emburrecimento" e prevenir os usuários de armadilhas comuns / garantir uma melhor capacidade de manutenção é, por definição, parte do trabalho de um framework. Tomamos a decisão com base na experiência de design em primeira mão, usando o próprio framwork e observando o comportamento do usuário em vários casos de uso. Se for um antipadrão, impediremos os usuários de usá-lo e forneceremos orientação sobre a solução idiomática. Você é livre para discordar disso com base em sua opinião pessoal, mas acho seus argumentos pouco convincentes.

As pessoas não vão parar de tentar transformar o estado dos pais dos filhos. Você não pode forçar as pessoas a não fazerem isso.

Certo. E nós não os 'forçaremos', porque pode haver alguns casos extremos em que isso ainda pode ser necessário. Então você ainda pode acessar this.$parent , você pode passar $data por meio de um prop etc, mas francamente fazer isso não será muito mais conveniente que $emit ing um evento a maior parte do tempo, então eles não serão tão atraentes quanto .sync açúcar.

Além disso, $parent et.al. não fazem parte do guia oficial, portanto, os usuários que os utilizam trabalham ativamente em torno das práticas recomendadas sugeridas - o que eles podem fazer gratuitamente, mas não incentivamos esse comportamento.

Conseqüentemente, a estrutura não deve encorajar comportamento semelhante ao fornecer açúcar sintático 'mágico' como .sync se acharmos que tal recurso é mal utilizado na maioria dos cenários e se opõe às melhores práticas que a estrutura busca estabelecer.

Youda tem uma versão chinesa? .

Como é a compatibilidade do vue-router?

@ roblav96

Existem algumas mudanças necessárias para ser compatível. Esperamos incorporar melhor o Roteador ao Vue.

@ blake-newman

Podemos obter um modelo padrão juntos no vue-cli? Não consigo fazer nada disso funcionar 😢

@ roblav96

Existem alguns atualmente, existem algumas mudanças necessárias com o vue-loader para torná-lo compatível. Atualmente 2.0 deve ser usado para experimentação apenas até que todas as dependências adicionais para aplicativos de grande escala sejam atualizadas.

Existe um ETA para os candidatos beta / lançamento?

@Evertt Alpha é devido esta semana. A versão Beta seguirá com a documentação concluída e talvez mais suporte das bibliotecas de extensão principais (Vue-router ect). Candidato a lançamento quando o Beta for comprovado como bem-sucedido.

@blake-newman obrigado por sua resposta rápida, concisa e completa. Esses são os melhores. :-D

Alguma solução alternativa para replace: false no vue 2.0?

Olá, o JSX já pode ser usado?

@reohjs - Não e eu pessoalmente consideraria isso um verdadeiro retrocesso para o Vue, se ele suportasse JSX.

Scott

@reohjs No stream de Evan ontem à noite, ele mencionou que poderia ser feito com um plugin, então imagino que uma vez que isso vá para a versão beta, não demorará muito para alguém criá-lo. Estou feliz que não esteja no núcleo, mas um plug-in JSX parece uma ótima ideia.

Estou feliz que não esteja no centro

👍 👍 👍 👍

Sim, deve ser um plugin. No entanto, como visto, os modelos têm muitos benefícios para os componentes padrão.

A compilação JSX deve ser fácil de conseguir com este plugin: https://babeljs.io/docs/plugins/transform-react-jsx/

Acho que a função _h seria a substituição de React.createElement

Que tal fornecer uma interface para criar modificadores de modelo v personalizados como uma forma de substituir os filtros bidirecionais? Parece que eles já estão sendo usados ​​para analisar a entrada do usuário (por exemplo v-model.trim ). Se a análise / formatação for simples e independente de uma propriedade de dados específica, o uso de um modificador permitiria que a análise / formatação fosse reutilizada com muito menos clichê do que definindo uma propriedade computada para cada propriedade de dados individual ou criando um novo componente para cada tipo de entrada onde queremos que a análise / formatação seja aplicada.

Olá, estou atualmente trabalhando em um plug-in para oferecer suporte a gettext no Vue.js 1.0 e tenho uma diretiva que está usando vm.$interpolate .

Estou me perguntando como migrar meu código para 2.0 pois:

• vm.$interpolate será descontinuado
• as diretivas não terão mais instâncias em 2.0

Ou existe uma abordagem melhor do que uma diretiva?

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

Apenas jogando algumas palavras, já que sou novo no Vue , apenas para dizer que estou feliz em ver a redução da API em geral ou dos ajudantes _entros do capô_. JavaScript já é realmente poderoso, e com propriedades computadas além de outros recursos reativos do framework, quase tudo pode ser alcançado.

Parabéns por esta _próxima_ versão! 🎆

@kemar Não estou familiarizado com gettext, mas simplesmente estenderia Vue.prototype com um método $ translate e, em seguida,

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

A capacidade de registrar ativos com sintaxe de array foi removida do 2.0? Não estou trabalhando em alfa, apenas me perguntando se é intencional ou não.
ie:

components: [compA, compB, compC]

Eu sei que o ES6 tem uma abreviação que parece semelhante, mas existem alguns cenários em que a sintaxe de array foi útil.

Vejo que você mencionou rendering to native interfaces on mobile com weex e eu estava me perguntando como seria fácil fazer vue e Nativescript falarem.

Algo mais parecido com Nativescript for Vue seria Weex, que você mencionou, ou Quasar .

Scott

Se não houver mais dispatch ou broadcast como um componente filho genérico informará seu pai sobre um evento / mudança? Isso não parece se encaixar no padrão de um ônibus global ou vuex. O caso de uso que usamos agora é um controle deslizante de intervalo para filtros de pesquisa. O componente do controle deslizante de intervalo é genérico e é filho de vários filtros de pesquisa diferentes. Atualmente usamos dispatch quando um controle deslizante de intervalo termina de deslizar, então o pai sabe como iniciar uma pesquisa com base na mudança.

ouvintes @jrenton inline <child @some-event="parentHandler">

Bom trabalho, pessoal.

No meu ponto de vista, todas as mudanças dizem que a melhor abordagem é criar sua árvore de componentes baseada apenas em um "fluxo unilateral", que é muito mais simples e fácil de depurar e manter.

Sem isso, a veracidade de seus dados seria inversamente proporcional a quão longe você está do componente superior.

Só quero dizer que:

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

Me faz feliz

É esperado que mais coisas sejam adicionadas a esta lista antes do lançamento do 2.0? Só por curiosidade, pois o assunto ainda está em aberto.

@zephraph Sim, estamos continuamente atualizando a lista conforme fazemos atualizações na API. 😃 Nada muito grande até agora, mas mudanças de quebra ocasionais de alfas anteriores.

Eu tenho um caso em que usei o despacho de evento no passado e onde estou preso com vuex: o componente pai tem uma lista de componentes filhos e o filho estava despachando um evento quando seu valor mudou, então o pai foi capaz de fazer algo como uma reação a essa mudança.
Agora tentei ter uma matriz dos valores filho no armazenamento vuex. A questão é, como o componente filho sabe no getter e na ação, qual elemento desse array ele precisa atualizar. Pelo que vejo, o vuex não fornece funcionalidade para obter ou acionar dinamicamente a mutação de um valor, ou estou errado sobre isso?
Qual seria a melhor maneira de lidar com esse caso sem despacho de evento?

Com $broadcast sendo removido, como você diria a uma criança direta para fazer algo quando uma coisa específica acontecer? Este seria um cenário em que nenhum dado realmente mudou, então os adereços reativos não parecem se encaixar.

Eu poderia usar um adereço e passar um carimbo de data / hora ou alguns dados aleatórios e observar esse adereço na criança, mas isso parece estranho. Um barramento de evento global exigiria a geração de IDs exclusivos para que o filho só reaja aos eventos de seu pai e não a qualquer outra instância do componente pai.

Há $emit em uma criança que um pai pode ouvir usando um ouvinte in-line, há algo para o contrário?

Eu poderia transmitir uma instância de um emissor por meio de um suporte e, em seguida, emmiter.on na criança, isso parece terrível?

As ações

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

Se seus itens não tiverem ids exclusivos localmente, você pode gerar um quando o item for criado ou recebido da API. Na maioria das vezes cuid é bom o suficiente para isso.

@fergaldoyle devido ao pai sempre saber que são filhos, você pode colocar v-ref:some-child no filho para obter a referência para a VM da criança e, em seguida, $emit nela ou apenas chamar um método diretamente com this.$refs.someChild.<methodName>(...) .

No entanto, eu aconselharia repensar a arquitetura nesse caso, porque o fluxo de eventos torna o componente realmente difícil de raciocinar.

Eu estava brincando com vuejs 2 e notei Snabbdom se você passar

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

Para a função de renderização, você obtém

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

Mas em vuejs você consegue

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

Existe uma maneira de modificar o conteúdo do texto (dentro de <h1> )?

@dubcanada porque não apenas passar isso por crianças?

Isso faria sentido. Obrigado

Oi. Tenho algumas dúvidas sobre o sistema de transição no Vue 2.0 ou melhor, uma proposta porque não vejo isso nos planos para o Vue 2.0. No Vue 1.0, muitas vezes encontrei a necessidade de detectar quando alguma transição / animação que configurei terminaria. Agora eu faço isso usando setTimeout, mas esta é uma forma muito hackeada e feia, todos podemos concordar. Então, minha pergunta é: no Vue 2.0 haverá alguma maneira de detectar o fim da transição CSS quando usarmos a transição combinada com v-show / v-if, possivelmente via evento?

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

Eu ficaria muito feliz em ver algo assim no próximo lançamento do Vue :) obrigado por me ouvir

@sqal, você pode fazer isso com ganchos de transição: https://jsfiddle.net/simplesmiler/Lrk9sxjf/97/

@dubcanada será suportado na próxima versão (omitindo dados ao criar o elemento)

Obrigado @fergaldoyle e @simplesmiler pela sua dica de emitir.

Eu não sabia, o pai é capaz de ouvir os eventos que foram emitidos pela criança. É claro que faz mais sentido ouvir esse evento não borbulhante então.

Olá a todos. Um pouco de contexto: estamos trabalhando com o webgl e gostaria de fazer algumas interfaces em uma superfície 3D. Isso significa que precisamos renderizar uma interface para, por exemplo, uma tela e, em seguida, converter o conteúdo da tela em uma textura.

Tenho trabalhado com Angular, React e Vue e, para mim, o Vue faz mais sentido! Enquanto lia sobre o React, me deparei com o projeto da tela react. O interessante é que, em vez de transformar o DOM virtual em nós DOM reais, eles o desenham em uma tela.

Como o Vue 2.0 também está usando um DOM virtual, eu queria saber se algo assim também pode ser feito.

Olá,

Apenas alguns esclarecimentos sobre a remoção de .sync e como pode ser um fluxo de trabalho genérico para lidar com adereços em um componente genérico.

então, indo de
<component :value.sync="some.value"></component>
para
<component :value="some.value" @update="updateSomeValue"></component>

Qual é a forma recomendada de rastrear a proposta value ?
No caso mais básico, parece ser

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

Mas, certamente, isso depende do componente pai retornar esse valor para o prop, então, quando o componente o receber novamente, ele refletirá a mudança mais recente ...

Isso significa que agora precisamos fazer algo assim:

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

Isso parece muito clichê para lidar com a passagem (e alteração) de um valor, notificando o pai de que o valor foi alterado e rastreando a alteração internamente, caso a alteração não seja propagada de volta pelo pai.

Ou estou perdendo um pouco da reatividade mágica vue aqui?

Além disso, há uma chance de que, se houver muitos acessórios para controlar, isso possa se tornar bastante complicado.
Eu quase podia me ver trabalhando em um componente de invólucro, onde as crianças acessam this.$parent.value para sofrer mutação direta, e o componente de invólucro apenas manipulando os adereços / computados / relógios

@Towerful, o que exatamente você quer dizer com "rastrear o valor"? E por que você quer um estilo setter ( this._value = newValue ) em vez de this.$emit('value-updated', newValue) explícito?

O poder do fluxo unilateral é que o pai pode decidir não aplicar a alteração solicitada pela criança ou pode marcar a criança como "em espera" e aplicar a alteração mais tarde (por exemplo, após verificar novamente com o servidor).

@simplesmiler usando uma propriedade computada permite vinculá-la ao template, não? então você pode usar v-model .
E ter o setter e o getter contidos em um único lugar torna mais fácil ver a funcionalidade quando o valor é atualizado, em vez de ter diferentes maneiras de acessar o valor e alterar o valor dentro do componente e espalhado por todo o código.
Se estiver usando a maneira explícita dentro de um modelo, e não usando setters, parece que o objeto methods vai ser entulhado com métodos do tipo updateValue para o modelo, ao contrário dos métodos reais.

Eu acho que se aplica onde o usuário seleciona uma opção em um componente, e o componente depende desse valor para mostrar o que está selecionado.
Você está contando com o componente pai passando isso de volta para o componente para que ele seja capaz de fazer isso.
A menos que, quando o usuário seleciona uma opção, você acione a atualização de exibição do componente manualmente. O que parece estar se afastando da reatividade de Vue.
Portanto, tendo um valor interno rastreando o que "deveria ser", faça com que o modelo reaja a isso. Use setters / getters para envolver a propriedade para rastrear mudanças internas e gerar eventos externos, e uma observação na propriedade para atualizar o valor interno quando ele é alterado externamente.

Talvez eu esteja apenas lutando para entender a nova maneira de fazer isso.

@Towerful - Você não é o único ....

Scott

@Towerful :

Para mim, parece que o que você descreve são essencialmente componentes que agem como entradas com um v-model : o usuário altera algum valor na IU e você deseja que essa alteração seja refletida nos dados vinculados imediatamente.

Para esses tipos de componentes, você pode usar v-model nos componentes em 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
}

Isso torna a interface para elementos <input> reais e para componentes de entrada personalizados essencialmente idênticos, e uma ligação bidirecional.

Para componentes mais complexos que recebem vários adereços (e não são entradas personalizadas simples, mas mais abstratos), desencorajamos o uso de .sync porque se torna difícil raciocinar a respeito na maioria das situações.

O pai deve decidir o que fazer com um valor que recebe do filho, seus dados não devem ser alterados implicitamente como .sync faz.

Você pode fornecer um exemplo que _não_ seja solucionado com a abordagem do modelo v acima e ainda se beneficie do uso de .sync ? Essa pode ser uma base melhor para a discussão do que a teoria abstrata.

Oh, como eu perdi isso ?! Está definitivamente lá no OP, e há até uma discussão sobre isso alguns comentários atrás! Agora me sinto um pouco estúpido.
A postagem original poderia ser atualizada para deixar um pouco mais claro que v-model pode ser usado em um componente?
@LinusBorg Pensando bem , não consigo pensar em um caso em que v-model em um componente não funcionasse. Eu perdi essa parte do post original.
Mesmo para componentes de objeto complicados, seria apenas uma questão de aninhamento de componentes. E isso reforça os componentes de responsabilidade única.
Faz muito mais sentido :)

@Towerful

Re: usando v-model . A questão é que v-model é síncrono (de certa forma), enquanto o fluxo de dados entre componentes é inerentemente assíncrono por causa da fila do observador ( demo ). Já vi isso confundir muita gente. O fluxo unilateral apenas torna mais explícito que os props não são síncronos e força você a não confiar que eles sejam síncronos (é isso que você está tentando enganar).

Re: métodos desordenados. Para casos simples, você sempre pode fazer @value-updated="value = $arguments[0]" . Para casos complicados, é uma boa coisa ter um método, onde você pode ajustar o estado para mantê-lo consistente (por exemplo, acionar atualizações manualmente). Segway para o próximo ponto.

Re: afastando-se da reatividade. Não concordo com esta afirmação. Para casos simples você não precisa de mágica para fazer a criança pegar o valor, atualizado pelo value-updated="value = $arguments[0]" .

Para casos complicados, com .sync props, você teria que usar watch , mas watch explícito não é realmente uma parte da reatividade. É uma saída de emergência, onde você aciona as atualizações manuais que não podem ser expressas como calculadas. E não é bom, porque não pode reagir às mudanças de forma síncrona, como o computador pode. É por isso que, ao usar watch pesadamente, você pode notar que as atualizações de dados demoram alguns "tiques" para se propagar. Se você já se deparou com nextTick diretamente aninhado, sabe do que estou falando.

Agora, -updated handler fornece uma saída de escape melhor, permitindo que as alterações complicadas do modelo sejam aplicadas de forma síncrona (ou simultaneamente assíncrona) após a criança expressar a intenção, garantindo que a criança receberá valores atualizados no próximo tique (ou não receber estado inconsistente).

@ yyx990803 Podemos implementar uma maneira de ouvir $ emits, semelhante a como tínhamos eventos para $ dispatch e $ broadcast em vuejs1?

Parece mais vuejs-esque, algo parecido com isto (um 'on' ou 'listen'):

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

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

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

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

Basicamente, isso se ligaria automaticamente ao barramento global.

Os barramentos de eventos não são um padrão que queremos encorajar - são úteis apenas em alguns casos extremos. Geralmente, um padrão de armazenamento, como vuex, é preferido.

Implementar uma API que torne o uso de um barramento mais fácil e pareça "oficialmente compatível" seria o sinal errado.

Olhando seu exemplo, se você armazenou a quantidade em uma loja acessada por ambos os componentes, nenhum evento seria necessário. A propriedade computada no componente container seria atualizada automaticamente.

Exemplo de código simples sem usar uma solução de loja real como a 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
    }
  }
})

Eu diria que a ideia geral do vue2 é tornar mais difícil atirar em si mesmo
no pé.

No domingo, 3 de julho de 2016 às 11h24, Thorsten Lünborg [email protected]
escreveu:

Os ônibus de eventos não são um padrão que queremos encorajar - são apenas
útil em alguns casos extremos. Geralmente, um padrão de armazenamento, como vuex, é preferido.

Implementar uma API que torne o uso de um barramento mais fácil e pareça "oficialmente
suportado "seria o sinal errado.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -230158828 ou mudo
o segmento
https://github.com/notifications/unsubscribe/AACoukCpCgYlDbVej_w_h4NEhQ-imYHBks5qR9QwgaJpZM4IedHC
.

@kharysharpe $emit s devem ser ouvidos com v-on na instância filha. Isso também tem a vantagem de poder acessar o contexto original de onde a instância é usada:

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

Existe uma data para o lançamento do 2.0? Estou muito animado com as mudanças. Parabéns!
Estou pensando em usar o Vue 2.0 + Redux.

@Sendoushi Ainda não há data para o lançamento final, mas o beta pode estar dentro de uma semana. 😄 O Vuex 2.0 também está sendo desenvolvido paralelamente e não só apresentará uma API muito mais simples do que o vuex atual, mas também se integrará ao ecossistema Vue muito mais bem do que o redux.

O Vuex 2.0 também está sendo desenvolvido paralelamente e não só apresentará uma API muito mais simples do que o vuex atual, mas também se integrará ao ecossistema Vue muito mais bem do que o redux.

@chrisvfritz Isso é fantástico de se ouvir! Sempre achei que a API atual é um pouco excessivamente e desnecessariamente complicada. Acabou tendo que fazer coisas assim 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
}, {})

E sobre o roteiro de vue 2 e vuex 2. É planejado lançá-los juntos ou um antes do outro e quanto às compatibilidades de diferentes versões?

Em relação à pergunta acima, qual é o status com o vue-router - ele obterá suporte para o Vue 2 em breve ou o teste do Vue 2 precisará ser feito sem o roteador?

@gwildu Eles provavelmente serão lançados juntos e o Vuex 2.0 oferecerá suporte apenas ao Vue 2.0. O Pre 2.0 Vuex ainda receberá suporte até que o Vue 1.x não seja mais compatível.

O @Uninen Vue Router receberá muito carinho a seguir, antes do lançamento do Vue 2.0.

Obrigado pelo nfo @chrisvfritz :)

@chrisvfritz @Uninen correção: Vuex 2.0 também funciona para Vue 1.x.

A próxima versão principal de vue-router suportará apenas Vue 2.x.

Compilação apenas em tempo de execução: uma vez que não inclui o compilador, você precisa de modelos pré-compilados em uma etapa de compilação ou funções de renderização escritas manualmente.

Existe / haverá uma maneira de pré-compilar modelos sem usar vueify / vue-loader e .vue arquivos? Se não, seria uma boa idéia ter um plugin babel para transformar template: propriedades em render funções em componentes?

Após a atualização para 2.0, os recursos obsoletos ainda podem ser usados. Você pode atualizar para 2.0 primeiro e, em seguida, alterar lentamente os recursos obsoletos?

Será possível criar um componente de terminal, agora que elementDirective se foi?

Como mencionado:

O v-model não se preocupa mais com o valor sequencial inicial. Sempre tratará os dados da instância do Vue como a fonte da verdade.

Considere isso

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

Como posso lidar com a caixa de seleção com matrizes entre componentes personalizados?

_Atualizado 1: _
Resolvido. Transfira prop type="checkbox" para o componente filho no componente pai.

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

Então você pode obter o valor embutido por meio de {props: [ 'value' ]} .
Emita um evento change para o componente pai para informar que o valor mudou.

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

Isso ocorre porque o compilador compila a diretiva v-model acordo com sua type . E o compilador irá gerar o checked prop e associar um evento change a ele.

_Atualizado 2: _
No entanto, o gancho do ciclo de vida updated não é acionado porque v-model altera diretamente o atributo checked (Isso significa que você não pode obter um evento change de um componente de caixa de seleção html nativo, modificando o valor de v-model ).
Então, @ yyx990803 , você pode acionar um evento change após v-model mudanças?

@ YunSun-CN A única maneira de contornar seu problema foi adicionar uma propriedade específica para o valor, ala val, e usá-la para definir o valor real e, em seguida, apenas emitir alterações para a entrada do modelo v 'evento.

@johnleider Eu escrevi uma diretiva personalizada para simular o que v-model faz.
A propósito, você deve gerar modelos de maneira estrita não apenas verificando type prop, mas também verificando o tagName do elemento. Caso contrário, outro componente personalizado com type prop pode sobrescrever seu comportamento de modelo padrão.

Oi. Nós sabemos uma data de lançamento?

@thanosalexander Ainda não decidimos a data, não. Acabamos de introduzir algumas mudanças importantes no sistema de transição com 2.0.0-bet.2, que devem ser testadas exaustivamente. Então, ainda vai demorar algumas semanas até que possamos pensar em um lançamento, na minha opinião.

ok ... eu vou com isso então ... eu não acho que o passo para o estábulo será muito grande! obrigada

E quanto aos documentos? Uma das razões pelas quais o Vue foi adotado cedo foi a documentação e é a única razão que está me segurando agora com a v2. Eu vi o problema de acompanhamento de documentos, mas não vejo como chegar perto de ser concluído em breve. Provavelmente estou ignorando muita coisa acontecendo sob o capô, razão pela qual levantamos a questão :)

Algum plano para implementar o modo de transição fora da comutação de componentes no 2.0?
https://github.com/vuejs/Discussion/issues/156

@ miljan-aleksic Docs estará pronto quando 2.0 for oficialmente lançado. Ainda estamos em beta. ;)

Até então, você pode acompanhar o andamento da documentação aqui (ou até mesmo contribuir)

@aristidesfl Já feito. 🎉

@ miljan-aleksic Adicionando ao que @LinusBorg mencionou, a maior parte do novo guia já está completa e você pode até ler a fonte aqui se desejar. No entanto, lembre-se de que, no momento da escrita, ele não foi totalmente atualizado para refletir as alterações no beta.2 , uma revisão significativa por pares ainda está por vir e há algumas outras pequenas alterações da API que estão sendo consideradas. Portanto, a menos que você queira ajudar a corrigir erros de digitação e melhorar as explicações, recomendo esperar até que seja oficialmente publicado (talvez no estágio RC).

Também concordamos que a excelente documentação é uma parte vital do Vue. Até Dan Abramov da equipe React adora nossos documentos. 😄 É por isso que um dos meus objetivos pessoais é que os documentos 2.0 sejam _ainda melhores_. Enquanto isso ...

Para quem deseja aprender sobre 2.0 antecipadamente, eu recomendo os testes de unidade de recursos como o

Esse é um dos meus principais recursos para escrever documentação e geralmente são bastante legíveis se você estiver familiarizado com o Jasmine.

Obrigado @chrisvfritz , uma informação muito útil. Vou dar uma chance aos novos documentos, levando em consideração um WIP e feedback, se necessário. É hora de levar o Vue 2.0 a sério;)

createElement na função de renderização usando on não parece lidar com arrays (como o snabbdom faz) existe uma maneira de passar dados para as funções chamadas?

Por exemplo, em snabbdom posso usar

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

E o function terá dataToPass como o primeiro argumento. Mas isso parece um erro no vuejs 2 beta 2 Uncaught TypeError: arr[i] is not a function . Existe uma maneira de passar dados e o evento usando o elemento on from create?

@dubcanada, o tratamento de eventos no Vue 2.0 é diferente do snabbdom - você mesmo precisa curry a função. A sintaxe da matriz simplesmente anexa vários manipuladores ao mesmo evento.

Estou tentando obter o conteúdo dos slots como string em vez de processá-los. Com nós padrão, há uma solução fácil, mas com Vnodes não encontrei uma maneira. Existe alguma solução alternativa para isso?

@ miljan-aleksic Tente renderizá-lo, obtendo o conteúdo do elemento com innerHTML , em seguida, ocultando o elemento com display: none em css.

Obrigado pela ajuda. Se eu renderizá-lo, o resultado final será diferente. Estou criando um componente que envolverá seu conteúdo filho com uma tag pre e codificará o HTML.

Nesse caso, renderize a saída em um elemento diferente do original.

Embora eu afirme que a criação de modelos não deve ser sua maneira de escrever seu conteúdo. Deve ser a maneira de descrever _como_ o conteúdo é escrito, e não o conteúdo em si. Eu recomendo armazenar o texto como uma string em JS (ou como um recurso em algum outro lugar em seu projeto, _especialmente_ se for algum tipo de entrada do usuário) e, em seguida, passá-lo para a criança como um suporte, o que deve tornar as coisas milhares de vezes mais fácil de qualquer maneira.

Você tem razão @Kingdaro , o melhor é não misturar conceitos e manter a simplicidade. Foi bom ter a sintaxe hihgligthig, no entanto :)

Ao usar o v-on directiva, o $arguments variável não está mais disponível. Não vejo nenhuma referência sobre essa mudança aqui. É um bug ou uma referência ausente?

@miljan-aleksic use apenas arguments .

Deve ser um desenvolvedor PHP (como eu) ... Eu sei como você se sente. LOL!

Scott

@ yyx990803 , @smolinari eu sou ... e um envergonhado agora haha. Eu me fiz acreditar que já tentei isso ... parece que não fui bem o suficiente. Está funcionando, obrigado e desculpe por desperdiçar seu tempo.

Eu estava prestes a abrir um tíquete sobre outro "problema", mas não tenho mais certeza se é ... Ao usar ref o componente ou elemento registrado não está disponível imediatamente, então algo como isso não funcionaria.

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

No momento em que Foo está sendo renderizado, $refs.button ainda está indefinido. No Vue 1 está funcionando conforme o esperado. O que estou perdendo dessa vez?

Está faltando que você não deve passar elementos DOM ou instâncias de componentes como adereços ...

Por que isso é uma má ideia? Digamos que eu tenha um componente suspenso que desejo conectar a um botão (o gatilho). Ambos são componentes independentes e em vez de conectá-los por meio de uma consulta, estou passando a referência diretamente.

@ miljan-aleksic é ainda melhor conectá-los via estado:

• estado aberto / fechado é mantido em seu pai comum
• o pai passa o estado para o menu suspenso como um suporte
• o pai ouve o evento do botão para alternar o estado

Desta forma, a lista suspensa e o botão são completamente desacoplados, o botão pode ser reutilizado para controlar outros tipos de componentes e a lista suspensa pode ser controlada por outros tipos de componentes de entrada.

Não é fácil livrar-se de velhos hábitos. Devo culpar jQuery ou principalmente a mim? : D

Sua abordagem, Evan, está correta. Eu irei por esse caminho, mesmo que isso signifique que a integração do Dropdown seja mais entediante. Como o componente pai teria que saber como ouvir os diferentes eventos, não apenas sobre como abrir, mas também como fechar o Dropdown quando clicado fora, mas não o próprio dropdown, etc. Muitos eventos e soluções alternativas que o Dropdown estava resolvendo.

Como o componente pai teria que saber como ouvir os diferentes eventos, não apenas sobre como abrir, mas também como fechar o Dropdown quando clicado fora, mas não o próprio dropdown, etc. Muitos eventos e soluções alternativas que o Dropdown estava resolvendo.

Ainda pode? você pode fazer addEventListener('body', ... ) totalmente no componente suspenso para registrar cliques externos, etc ... O menu suspenso pode simplesmente emitir um evento 'fechar' para o pai quando alguém clica fora, por exemplo.

Sim Sim. É hora de refatorar alguns componentes :) Obrigado a todos! Comunidade incrível.

Como aplicar v-model a um componente com createElement ? Dei uma olhada no código gerado usando o compilador de modelo e ... é muito código. Não entendi muito bem a documentação lá sobre diretivas.

Por padrão, uma diretiva de tempo de compilação irá extrair a diretiva e a diretiva não estará presente em tempo de execução. Se você quiser que a diretiva também seja tratada por uma definição de tempo de execução, retorne true na função de transformação.

@blocka você não tem acesso às diretivas embutidas se estiver usando a função render . Você terá que lidar com a lógica equivalente sozinho. Por exemplo v-if é apenas uma expressão ternária, v-for é uma expressão array.map() ... e v-model (em um elemento <input> normal ) é traduzido em uma ligação value e um ouvinte de evento input .

@ yyx990803 foi o que imaginei. Provavelmente vou acabar lidando com isso com um HOC (já estou entregando condicionais da mesma forma (embora esteja pensando em usar isso )

Com vue 1, havia duas vantagens declaradas de vuex vs redux.

1. O desempenho é melhor quando o vuex altera o estado, que funciona melhor com o vue (substituir o estado antigo tinha desempenho equivalente a "verificação suja")
2. A Vuex está mais "ciente" de que está em uma aplicação vue

Usar o dom virtual atenua alguns ou todos de 1?

@blocka atenua parte disso, mas o desempenho geral ainda será muito melhor do que com Redux.

O que mudou em 2.0 é a granularidade da reatividade. Vamos fazer uma comparação:

• No Vue 1.x, a reatividade é muito refinada. Cada diretiva e cada vinculação de texto tem um inspetor correspondente. Isso resulta em atualizações refinadas quando os dados são alterados, mas ao custo de mais sobrecarga de rastreamento de dependência na renderização inicial e uso de memória um pouco maior.
• Com Redux, a reatividade não tem granularidade. Sempre que algo muda, todo o aplicativo precisa ser renderizado novamente. No React, a ligação Redux faz alguma otimização nos contêineres conectados, mas o usuário ainda precisa implementar extensivamente shouldComponentUpdate para obter melhor desempenho.
• No Vue 2.0, a reatividade tem uma granularidade média. Cada componente tem um inspetor correspondente que controla as dependências desse componente. Quando os dados mudam, apenas os componentes que dependem da mudança precisarão renderizar novamente seu DOM virtual. Este é essencialmente o melhor cenário para o React, mas você não precisa fazer nada para conseguir isso no Vue 2.0.

Geralmente com 2.0, você verá (em comparação com 1.x)

• atualizações ligeiramente mais lentas (mas ainda muito rápidas) para pequenas alterações de dados
• atualizações decentemente mais rápidas para mudanças de dados de médio a grande porte
• renderização inicial significativamente mais rápida

Ei,
não consigo fazer as transições com o animated.css funcionarem.

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

Alguém tem uma ideia?

Seus nomes de prop estão errados.

camelCase vs kebap-case ainda se aplica no 2.0.

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

@LinusBorg desculpe, eu já tentei isso. Aqui eu tenho um pequeno violino. Com transições css e a tag de nome, funciona bem.
https://jsfiddle.net/z0nyfba0/

Ao usar v-model em um componente, o componente terá visibilidade para quaisquer modificadores usados ​​com v-model ?

por exemplo, se eu tenho um componente que emite um evento input , quando esse evento é emitido depende se o modificador lazy é usado ou não.

@fergaldoyle, brinquei um pouco com isso e acho que você não pode usar modificadores de modelo v no elemento personalizado, pois você precisa emitir manualmente o evento de entrada. Se você deseja obter um comportamento preguiçoso, você precisa vincular o evento change à entrada, por exemplo, https://jsfiddle.net/cynhtLty/1/

@calebboyd

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

1. Você deve usar enter-active-class e leave-active-class
2. Você deve colocar class="animated" no elemento <router-view> .

@fergaldoyle De acordo com os documentos 1.0, acho que com lazy , o modelo v iria apenas reagir a change vez de input . Você pode usar isso para mudar o comportamento e emitir input ou change para fornecer resultados diferentes dependendo se lazy é fornecido ou não.

Tenho coçado a cabeça enquanto brinco com um exemplo simples de v-for . Por alguma razão, a ligação value não está funcionando para elementos select em 2.0: https://jsfiddle.net/972eL5fL/

Além disso, provavelmente deve ser observado nos documentos que v-for intervalos como "i in 10" começam em 1 em vez de 0 como em 1.0.

@lauritzen

Tenho coçado a cabeça enquanto brinco com um V simples, por exemplo. Por algum motivo, a vinculação de valor não está funcionando para elementos selecionados em 2.0: https://jsfiddle.net/972eL5fL/

Parece funcionar conforme o esperado para mim, o que não está funcionando para você?

Anúncio de serviço público

Nós encorajamos você a fazer perguntas de suporte no fórum ou no gitter .

Este assunto deve ser reservado para discussões sobre a nova API. Se cuidarmos do suporte para várias questões aqui, isso ficará fora de controle.

Obrigada.

Por que vm. $ Get foi descontinuado?
Por que não Vue.get em vez disso?
É muito útil para avaliar expressões computadas como esta
var exp = 'entity.type.name' // this is generated in runtime return vm.$get(exp)

@iagafonov não há muitos cenários onde isso seja útil, portanto, não deve fazer parte do núcleo.

Se você precisa da funcionalidade para um dos poucos cenários, pode facilmente adicionar um comportamento semelhante com a ajuda de, por exemplo, lodash:

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

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

(é claro que você também pode adicioná-lo como "método de classe" como Vue.get () - ou simplesmente importá-lo localmente onde precisar -sua escolha)

@LinusBorg. Em primeiro lugar, eu não uso lodash ou algo parecido.
Em segundo lugar, a implementação do lodash é lenta, porque está em tempo de execução e tenta se aprofundar na estrutura de expressão. vue cumpre a nova função especificada (por parseExpression), ligada ao escopo.
Não é parte trivial, é muito difícil reimplementar isso.
Claro, $ get compile a função todas as vezes). Será bom se parseExression fizer parte da api em Vue.util, por exemplo.

@iagafonov this.$get também precisa analisar o caminho em tempo de execução e recuperar o valor dinamicamente. Caso contrário, você obterá um erro se o caminho não existir. Além disso, a diferença de desempenho será insignificante na maioria dos casos. Se você não quiser lodash, existem muitas outras bibliotecas de recuperação de caminhos por aí. Simplesmente não faz mais parte da preocupação de Vue.

Quais são algumas alternativas aos agora obsoletos atributos param?

você está falando sobre parâmetros em uma diretiva? Então você pode encontrar todos os atributos vinculados dentro do objeto vnode

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

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

@sqal , esta é uma resposta à minha pergunta? Nesse caso, estou falando sobre atributos param como preguiçoso, número e debounce. Por exemplo, antes de 2.0, eu poderia fazer isso <input type="text" v-model="msg" number> (número sendo um atributo param aqui). Como posso obter os mesmos resultados sem usar o atributo param?

@ p-adams é mencionado na postagem - eles são modificadores agora <input v-model.number="msg">

Descobri que no Vue 2.0, quando os adereços mudam, a função de renderização é sempre chamada, então eu me pergunto se 2.0 suportará shouldComponentUpdate para decidir se renderizar novamente.

@ yyx990803 Ok, vejo agora na postagem The lazy and number params are now modifiers .

@HeChenTao Evan explicou isso um pouco aqui https://medium.com/the-vue-point/announcing-vue-js-2-0-8af1bde7ab9#.pc5c8urbv

@HeChenTao a função de renderização não é "sempre" chamada, apenas quando é necessária:

• O Vue não precisa de shouldComponentUpdate , por causa de sua reatividade.
• Quando os dados reativos usados ​​em um componente são alterados, isso aciona a função render, vdom diffing e assim por diante.
• Mas se nenhum desses dados mudou, não atualizar é necessário e a função de renderização _não_ será chamada.

A mesma coisa pode ser feita em reagir com mobx. Tenho quase certeza de que você não precisa implementar shouldComponentUpdate . No entanto, como vue, mobx insiste em um estado mutável. Se, por algum motivo, você aceitou o conceito de estado imutável. Nesse caso, reaja às suas costas com shouldComponentUpdate .

Então, isso significa que se alguém insiste em um estado imutável, vue não será uma boa combinação?

O argumento de contexto dos Componentes Funcionais tem children mais slots . Acho um pouco confuso saber que children() e slots().default exatamente iguais. Me faz pensar qual é a abordagem correta. Provavelmente 'filhos' como slots é preguiçoso, mas ainda assim, por que apoiar duas maneiras diferentes de obter o mesmo comportamento?

Os componentes funcionais são apenas funções e, portanto, não têm filhos. IMHO, as crianças devem ser descontinuadas e apenas manter os slots para não preguiçosos.

@blocka você pode implementar dados reativos em reação com mobx, é verdade. Mas a reatividade está no centro da funcionalidade do Vue. Então, se essa não é a sua xícara de chá, essa pessoa está na festa errada.

@ miljan-aleksic children é bruto (você obtém todos os nós independentemente de qual slot eles devem ir), slots será resolvido com base nos nomes de slot nos filhos entrantes.

Obrigado @ yyx990803. Talvez mais detalhes sobre isso na documentação evitem confusões, @chrisvfritz.

@ miljan-aleksic, vou acrescentar uma nota. 👍

Com relação aos filtros, usar uma propriedade computada parece bastante simples, mas como lidar com o caso de usar filtro com v-model. Se alguém quiser filtrar por uma lista de nomes digitando no campo de entrada, como isso pode ser feito no 2.0?

Você está pensando em ter o Vue avisando quando um campo de dados / propriedade computada não está sendo usado em um modelo? Imagino que haja algumas limitações aqui, mas seria muito útil saber onde eu poderia me dar ao luxo de retirar algumas importações inúteis da loja onde não são necessárias.

@ yyx990803 , o que você acha sobre definir $context referência para o protótipo do componente? O mesmo que com $parent ou $root Eu me descobri acessando frequentemente o contexto que atualmente só está disponível através do objeto $vnode .

Na verdade, essa não parece ser uma forma confiável de acessar o contexto. Como deve ser feito?

@ miljan-aleksic Você pode compartilhar os casos de uso em que acessa o contexto com frequência?

@Kingdaro Você pode abrir um problema para isso? Parece bom se for viável.

@ p-adams Você ainda pode usar uma propriedade computada com Array.prototype.filter .

@chrisvfritz , basicamente para soluções alternativas como, por exemplo, definir variáveis ​​no contexto que a criança está esperando. Ou para definir um ref para o componente anterior que o próprio Vue faz.

Concordo que não é comum a todos, mas pelo menos deve haver uma maneira confiável de acessá-lo dentro do componente. O $ vnode não está presente até que o componente seja montado ao usar modelos (pelo menos minha conclusão até agora).

Eu ficaria contente em saber como acessá-lo de maneira adequada.

Outra situação em que $context seria útil é ao reutilizar um componente como raiz de outro componente.

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

No exemplo child.$parent retornaria o componente Foo em vez de Bar, o que é correto, mas se o pai e o filho forem dependentes um do outro, uma comunicação direta entre eles poderia ser por meio do contexto.

@ miljan-aleksic Vou deixar este aqui para @ yyx990803. Eu diria que, assim como $parent , alcançar $context provavelmente será o caminho errado 99,9% das vezes e acho que provavelmente nunca o usaria.

Eu tenho um problema com v-show e transições. Neste cenário, há um modal que por padrão é 'display: none' no CSS. Quando combinado com v-show nunca seria mostrado porque a diretiva remove a propriedade display, as CSS então persistem. Não posso alterar o CSS (requisitos do projeto) e não posso usar uma diretiva personalizada, pois parece que as transições do Vue dependem especificamente dela.

Estou pensando agora que uma diretiva que avalia logo após v-show poderia definir a propriedade de exibição para bloquear. Preciso experimentar, mas de qualquer forma pode ser uma boa ideia adicionar um modificador ao v-show para permitir a configuração do display para bloquear ou inline-block. Apenas um pensamento.

@chrisvfritz , é esperado que para componentes funcionais a referência pai não seja o pai imediato onde eles estão sendo usados ​​como slots, mas sim o componente de contexto?

A compilação do modelo falhará se contiver "<" (e possivelmente outros caracteres sensíveis ao html) em 2.0.0-beta7

https://jsfiddle.net/x0r59ur1/

Isso funcionou em 1.0.26.

Escapar de "<" com "<" resolve o problema.

Espera-se que

@ yyx990803 , se eu quiser usar transições em uma lista de componentes do mesmo tipo e manter seu estado, como devo fazer isso? Seguindo a documentação, só vejo como quando os componentes são diferentes.

Vamos dizer um componente Tab e fazer a transição de seus itens. Não consigo encontrar uma maneira :(

<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> é apenas para um único elemento. Você precisa de <transition-group> para vários itens.

@ yyx990803 , tentei esse também, mas ainda não vejo como consegui-lo. O grupo de transição funciona adicionando / removendo elementos, mas ao fazê-lo, os componentes seriam reiniciados, perdendo o estado. Ao lado da ideia de uma guia é mostrar apenas um componente por vez, não é exatamente uma lista :)

@ yyx990803 , @LinusBorg Agradeço a ajuda, mas a solução não é óbvia. Eu sei como as transições são aplicadas, o que não consigo descobrir é como keep-alive os componentes transicionados.

Eu criei um novo problema para fins de clareza com o exemplo jsfiddle sobre como os componentes são criados a cada vez.

@ yyx990803 , muito obrigado por melhorar o recurso keep-alive, agora ele funciona conforme o esperado.

Você está literalmente mudando a minha vida, com seus produtos e ética de trabalho sou capaz de aprender, construir e entregar produtos que eu estava esperando há muito tempo. Com sua abordagem simplificada, a alta tecnologia está disponível para todos usarem e desenvolverem. Por tudo isso e muito mais, sou eternamente grato.

@ miljan-aleksic Há uma piscadela de piscadela da campanha do Patreon .

Você sabe o que é @phanan , você está totalmente certo. Comecei a apoiar o Evan pessoalmente e assim que os produtos da empresa começarem a dar resultados vou fazer com que o apoio se torne mais perceptível.

O gancho de ciclo de vida ready foi substituído por mounted ; mas de acordo com o changelog, não há garantia de que o componente será renderizado antes que o mount seja chamado. Isso causa erros esporádicos quando desejo inicializar certos componentes jquery (como selectize) depois que o componente foi inicializado. Qual gancho de ciclo de vida devo usar no lugar? O gancho "pronto" pode ser emulado assim:

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

@GlurG Sim, funcionará. E, a propósito, isso também era necessário com ready'() em 1.0 em muitos casos.

Existe alguma razão pela qual não pode haver um gancho para isso de qualquer maneira? Eu também
através disso ... mesmo em 1.0, e recorremos a coisas como loop com raf para
verifique se está no dom, etc.
Em 10 de agosto de 2016, 18:26, "Thorsten Lünborg" [email protected]
escreveu:

@GlurG https://github.com/GlurG Sim, funcionará. E, aliás,
isso também era nessessariy com ready '() em 1.0 em muitos casos.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/vuejs/vue/issues/2873#issuecomment -238903012 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AACounAoI8p65soUUrbdaiwteDXKgMGJks5qee25gaJpZM4IedHC
.

Ao usar as funções de renderização, as diretivas principais são ignoradas, o que é razoável. Mas alguns não são tão fáceis de reproduzir usando o js simples, como o v-model que tem soluções alternativas para o IE9 e provavelmente resolve outros problemas de casos extremos.

Faz você reconsiderar o uso de um modelo, mas isso não é possível ou é a melhor opção em algumas situações. Os documentos podem definitivamente oferecer mais orientações sobre este assunto e, além disso, pode ser uma boa ideia ter algum ajudante ao trabalhar com funções de renderização que ajudem a resolver essas situações comuns e não façam com que ninguém perca um modelo.

@ miljan-aleksic desculpe, eu apaguei meu comentário porque percebi que só funciona para v-show ou diretivas personalizadas e sim, como você disse no caso do v-model, é necessário adicionar input / alterar listener e atualizar nossos dados manualmente

o novo gancho activated deve ser chamado quando uma rota que ativa / monta router-view é disparada? Não estou vendo esse comportamento atualmente.

@wprater não, está relacionado exclusivamente a <keep-alive> e nada mais.

@ yyx990803 Estou envolvendo minha visão do roteador em um keep-alive, mas não consigo encontrar um gancho para quando volto para a visão anterior. mounted nem activated são chamados. Preciso ter certeza de que o dom foi renderizado.

@wprater evite usar este tópico para perguntas não relacionadas. Se houver um bug, envie o problema no repositório correspondente com reprodução.

O Vue JSX oferece suporte ao operador de propagação de objetos? Já tentei, mas não funciona.

Sim, e

Estou fazendo isso <Component {...{ props } }></Component> e funciona conforme documentado.

@blocka Obrigado! Achei que o nome da propriedade props não fosse necessário 😂

@ yyx990803
components options não suportam o tipo de array, mas funcionam na versão 1.x.

por exemplo

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

É bug?

@ QingWei-Li eles simplesmente não são mais suportados, uma vez que nunca foi um recurso oficialmente documentado. A razão é que com ES2015 você pode simplesmente escrever components: { Parent, Child } .

apenas uma pequena sugestão,
existe alguma chance para a iteração de array normal usarmos v-foreach e para intervalo usarmos v-for .

que fará mais sentido para usuários vindos de php e até mesmo consistente com .each em JQ ou foreach em JS

@ ctf0 Estamos no estágio RC, a API não mudará mais. E não apresentaremos sintaxe alternativa para fazer a mesma coisa.

Não acho que a sobrecarga mental de v-for="item in items" seja significativa o suficiente para justificar isso.

Com esta nova versão, trataria deste caso.

Eu tenho um componente de calendário (vindo da interface do usuário semântica), que usa uma entrada de texto clássica e mostra a data em um formato humano (como "10 de julho de 2016", por exemplo). Com a v1.0, eu estava usando um filtro bidirecional para converter essa string em uma data adequada, de modo que os dados do meu objeto estivessem diretamente prontos para envio. Mas, uma vez que os filtros não funcionam mais no modelo v, como posso fazer a mesma coisa agora na v2.0?

Obrigado

@shadowRR seria possível ver algum código?

@ p-adams Claro. Aqui está.

Primeiro, meu filtro, que é usado no meu modelo V para a entrada do meu calendário. Seu único propósito é escrever, quando o valor muda, um tipo de data apropriado para meus dados (data postgres).

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

E você usaria assim no meu componente (a entrada tem um sistema de calendário que retorna minha data no formato legível 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>

Eu recomendo a leitura da postagem de @ yyx990803 aqui: https://github.com/vuejs/vue/issues/2756 onde ele discute filtros bidirecionais em v-model . Além disso, pode ser melhor fazer perguntas como esta aqui: http://forum.vuejs.org/

Perdi o post que você está falando, vou ver, obrigado;)

Oi,
Tenho algumas dúvidas em novos ganchos de ciclo de vida.
Se eu quiser registrar um manipulador de eventos quando montado e cancelar o registro antes de desmontar, como devo fazer com que funcione? Adicionar verificações e lógicas em ganchos criados e beforeDestroy?
No Vue 1.x eu usaria ganchos fixos e destacados.
Mas no 2.0 há um gancho montado, mas nenhum gancho de desmontagem. Parece um pouco incompatível.
Existe alguma razão pela qual nenhum gancho de desmontagem é fornecido?

@ f15gdsy mounted corresponde a destroyed . Não há attached / detatched contrapartes no 2.0 - você precisa fazer a verificação interna você mesmo. Se seus eventos não se preocupam com o domínio interno / externo, então mounted e beforeDestroy são os lugares apropriados para fazer isso.

Quando usado em um componente customizado, v-on agora escuta apenas eventos customizados $ emitidos por aquele componente. (não escuta mais eventos DOM)

Posso ter perdido alguns posts aqui, mas qual é a decisão de design por trás disso?
Isso tornaria a vinculação de eventos de clique simples em componentes muito detalhada.

1.0:

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

2.0:

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

@fnlctrl , use o modificador nativo: @click.native="bar" .

@ miljan-aleksic Muito obrigado! Acho que este modificador deve ser adicionado a Directives -> v-on -> modifiers nesta edição

Posso usar Koa (1.x ou 2.x) como servidor? Há algum problema em vue-server-renderer com 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 que não chame o gancho enter?

@fundon Você deve fazer a pergunta nos fóruns ou no gitter chat

Bloqueando este tópico porque:

1. Estamos agora no congelamento da API no RC, portanto, este documento não será mais atualizado.
2. Muitas pessoas estão usando isso como um tópico geral de perguntas frequentes, o que não é para isso.

Se você tiver um bug, abra um problema separado seguindo o guia de relatório de problemas, se você tiver uma pergunta, use o fórum ou gitter.

Atualização : para uma lista mais definitiva e detalhada das mudanças no 2.0, consulte o novo guia de migração .