modello lama metor getta "secondo punto di riferimento nella stessa filiale" eccezione nel ciclo for

Question

Ho un ciclo for che voglio includere un modello di vista in:

table.blade:

#game 
    h1= table.name 
     -if(table.playerSitting()) 
      a.btn.btn-danger.stand(href="#") Stand 
    #table 
     -for (var i=0; i<7;i++) 
      include 'seat' exposing i 

sedile. blade:

- id = 'p' + (i+1) 
    div(id="#{id}") 
     -if (table.hasAt(i)) 
      p= table.usernameAt(i) 
     -else 
      -if(!table.playerSitting()) 
       a.btn.btn-inverse.sit(href="#", data-key="#{i}") Sit 
      -else 
       p   

Quando carico la vista, tutto si disegna. Ma se io seduto o in piedi, o andare in un altro tavolo, ottengo questo:

Exception from Deps recompute: Error: Can't create second landmark in same branch 
    at /home/thomporter/meteor/blackjack/views/table.blade:8:4 

6 |  #table 
7 |   -for (var i=0; i<7;i++) 
8 >    include 'seat' exposing i 
9 |  
10 |  

Immagino che posso risolvere questo problema con la creazione di una collezione di "posti" che memorizza gli ID tabella user id &, ma che sembra stupido . Attualmente sto usando una proprietà array della tabella chiamata "players", indice 0-6 per ogni posto ... almeno, questa è l'idea. =)

Vorrei anche menzionare ho sostituito con seat.blade:

p hi 

e senza fortuna, stessi problemi.

Qualche idea?

Modifica
Informazioni sulla versione: versione
Meteorite 0.4.9
Meteor versione 0.5.9 (git checkout)
Lama 3.0.3

Answer 1

Questo bug è in realtà il risultato di utilizzando plain vecchio per cicli invece di cicli foreach.

La regione foreach è preferito rispetto ... [regolari cicli for] non solo a causa della leggibilità e brevità, ma perché fornisce anche lama con la possibilità di integrare meglio con la pagina in diretta motori aggiornamento (specificamente Meteor and Spark). Cioè, se il motore di aggiornamento della pagina live supporta il monitoraggio delle raccolte reattive, potrebbero verificarsi le operazioni DOM più efficienti per aggiornare i risultati della vista sul posto, senza re-rendering dell'intero modello Blade.

Nel tuo caso, Spark non riesce a rieseguire il rendering dei modelli inclusi a causa di rami corrispondenti per lo stesso punto di riferimento. Se si utilizza foreach, questo problema è stato risolto.

Tuttavia, in alcune situazioni (come la vostra), foreach non è appropriato. Penso che la soluzione qui sia quella di creare una sintassi "regular for loop" all'interno di Blade per gestire i loop. Per questo motivo ho creato issue # 157.