Isso pode ser feito por ajudantes.
Veja isto: http://kan.so/packages/details/handlebars-helpers
Há ifequal helper que permite comparar dois valores.
Uma solução semelhante pode ser usada para sua necessidade.

Eu estava com medo daquilo.
Eu sei que algo assim pode ser feito com ajudantes ... Mas, quero dizer, comparar coisas é tão básico que deveria estar no pacote padrão.

Se fosse incluído no pacote, seria um ajudante de qualquer maneira.

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijas está certo, seria de fato um auxiliar;) Ou não, já que um bloco if é tão elementar.
Obrigado pelo link. É útil, mas estou ansioso para escrever um "auxiliar" que sobrescreve o if original, para torná-lo um _proper_ if. Tenho certeza que é possível. Qualquer mecanismo de modelo que se preze precisa da formatação condicional adequada. O guiador não deve ser exceção.

Você precisa superar o fato de que tudo no guidão que aplica a lógica de negócios aos modelos são ajudantes.

Todos os construídos em cada um, se etc, são definidos por meio de registerHelper. Verificar:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

Portanto, não há nada de "ruim" em usar ajudantes. Handlebars é mais ou menos apenas um compilador de template de bigode e para obter essa lógica de negócios extra eles usam ajudantes. se você acha que acabou de ter uma experiência ruim com o uso da palavra "ajudantes" talvez de trilhos ou algo assim.

Eu nunca disse que há algo errado com "ajudantes". Acontece que uma instrução if adequada não deve ser uma extensão, na minha opinião. Um auxiliar (novamente, na minha opinião) é algo específico para um CMS ou algo assim. Um auxiliar é algo que executa uma operação ou condição especial. Algo que não é para todos. Ou seja, se for definido fora da biblioteca principal. Um pouco como plug-ins jQuery, talvez: as coisas mais elementares são embutidas, as coisas que ajudam você a começar. Mas coisas que não são para todos são definidas fora da biblioteca central (ou seja, em plug-ins). Em termos de jQuery, uma função de filtro simples não seria um plugin.

Uma instrução if (na minha opinião) não se aplica a este paradigma de plug-in. É elementar, é um dos princípios mais básicos de programação e motores de template ...

Um rápido acompanhamento então. Aqui está o que eu tenho até agora:

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

Usando isso em meu modelo como {{#when riskfactor eq 0}}...{{/when}} eu obtenho em meu console um array de [6, undefined, 0, function()] . O último que recebo. Isso é o que eu preciso chamar para processar o conteúdo deste bloco when. Os três primeiros ... bem, nem tanto. O "6" é na verdade o valor do "fator de risco". Ok, eu posso ir com isso. O indefinido está além de mim. Acho que o Handlebars está tentando avaliá-lo no objeto de entrada, mas não vai funcionar. Quero obter coisas que estão realmente _in_ no modelo, porque valores como esses não têm nada a ver com meu objeto.

Eu estava esperando algo como ["riskfactor", "eq", "0", function()] . Só então minha função pode prosseguir e processar isso. Como vou fazer isso com "undefined"?

Acho que a filosofia do Handlebars (e outros modelos "sem lógica") é que o contexto que chega para o modelo já deve estar totalmente processado. Se as estruturas de dados internas do seu aplicativo não se alinham perfeitamente com o que seria apropriado para um modelo (o que será o caso quase todas as vezes), você deve inserir uma etapa antes de renderizar o modelo que cria o contexto do modelo a partir dos dados internos do seu aplicativo estruturas.

Acredito que essa seja a intenção quando as pessoas falam sobre "separar a lógica da apresentação". Pense nas barras de apoio como o componente de visualização de um sistema MVC. Seu modelo já existe; tudo o que você deve escrever agora é o controlador (neste caso, é um conjunto de ligações unilaterais do modelo para a visualização).

Para responder à sua pergunta mais recente, você deseja usar isto:

 {{#when "riskfactor" "eq" 0}}...{{/when}}

As expressões do guiador são nomes de variáveis ​​ou strings. Se for um nome de variável, você obterá o valor da variável quando pesquisado no contexto atual, não o nome.

Isso está fora do domínio do Guiador, como alguns apontaram.

Não.
QUALQUER sistema de template pode fazer um bloco if-else simples comparativo, e os Handlebars não podem. Isso torna o Handlebars ridiculamente incompleto, seus criadores incompetentes (o que é improvável) ou um sistema com uma perspectiva nebulosa das tarefas de um sistema de modelos.

NÃO use um MOTOR DE MODELO LOGICLESS ENTÃO. KTHXBAI!

Entendi. Toodles.

@thany , @andriijas provavelmente foi um pouco duro, mas ele está certo. O guiador foi projetado para ser sem lógica. Definitivamente, você pode fazer uma bicicleta com motor, mas muitas empresas ficam felizes em fazer apenas bicicletas sem motor. Da mesma forma, você pode fazer um sistema de template com mais lógica, mas isso não é algo que o Handlebars está tentando fazer. Desculpe, não é o que você estava procurando.

Eu tenho que ficar do lado de @thany no if . Devemos ser capazes de passar qualquer predicado para ele. Não ser capaz de realmente limitar sua utilidade. Eu entendo a filosofia por trás dos modelos sem lógica, mas uma implementação dogmática não é realmente pragmática (e, portanto, a existência de ajudantes, certo?). Eu diria que isso é mais como a empresa de bicicletas adicionando uma relação de marcha variável, o que seria totalmente razoável.

BTW, se você quiser se enfurecer contra a máquina e fazer isso, você pode criar um ajudante que pega o predicado como uma string e, em seguida, avaliá-lo (e tornar isso duas vezes herético: smiling_imp :):

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thany olhe para isso da perspectiva das melhores práticas, seu back-end deve servir os dados com toda a lógica já descoberta. O front-end (modelo) deve apenas renderizá-lo ... se você tiver uma boa representação JSON de seus objetos de back-end de 95 % casos podem ser satisfeitos com a construção de condicionais http://handlebarsjs.com/#conditionals

Sério, nem TODAS (ou mesmo 95%) as decisões tomadas são voltadas para backend. Por exemplo, para determinar qual nome de classe renderizar, é totalmente razoável tomar essa decisão no modelo. Algo assim está 100% vinculado ao frontend / template. O back-end não dá a mínima para qual nome de classe é renderizado. Ou que tal palavras no singular / plural? Isso é outra coisa que não pode ser feita com o bloco if.

O back-end, na minha opinião, é responsável por fornecer dados, e APENAS dados, ao trabalhar com modelos avançados como este. Se o back-end precisar fornecer ao analisador de modelo variáveis ​​prontas para cada situação sobre a qual o modelo possa tomar uma decisão (considerando alguma flexibilidade aqui), eles seriam ridiculamente complicados apenas pela quantidade de variáveis, quanto mais o backend que os torna.

Você também pode colocar HTML no back-end se cada decisão de que um template precisa precisar de outra modificação no back-end. Isso apenas tira uma grande parte do propósito dos modelos. As decisões vinculadas ao back-end estão em um nível completamente diferente. Um bloco if não é necessariamente lógico. É apenas decidir o que / como renderizar.

Eu não posso acreditar que este problema requer uma discussão tão longa, um bloco if adequado é realmente pedir muito? :(

Não vou argumentar a favor nem contra a implementação de um auxiliar de comparação básico, mas este é o caso real em que não acho que poderia ter renderizado o modelo sem usar um auxiliar ou alterar a estrutura de dados:

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

Mas, novamente, o auxiliar que escrevi tinha três linhas de código:

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

concordo com @thany , também não acredito que isso seja algo que deveria estar fora do template / view.

por que exatamente um modelo não pode ter lógica nele? e como o guidão está fornecendo uma separação entre lógica e apresentação? ele ainda tem uma instrução if , não é mesmo? você está dizendo que uma instrução if que simplesmente testa a existência e / ou "falsidade" não é de forma alguma diferente de uma instrução if que verifica a (in) igualdade ou qualquer outra condição?

a única - real - diferença então é que ao contrário de outras bibliotecas de modelos, o guidão tem uma implementação muito pobre / incompleta da referida lógica sob o pretexto de ser "sem lógica". sinto muito, mas isso é completamente absurdo. se quiser remover a lógica, você deve remover a instrução if completo. você não fará isso, porém, porque, em última análise, um modelo precisa de lógica pelo (s) mesmo (s) motivo (s) pelo qual o guidão ainda tem uma instrução if .

portanto, a declaração "separando a lógica da apresentação." é falacioso, não apenas pelos motivos acima, também porque você não está removendo a "lógica" do modelo, você está simplesmente movendo-o para outra parte do modelo - ou seja, o auxiliar - e talvez você obtenha a reutilização de código - o que seria uma coisa boa - e talvez não, caso em que você pode obter qualquer número de auxiliares desempenhando quase / exatamente a mesma coisa que outros auxiliares, devido a uma pequena diferença que teria sido melhor fornecendo uma implementação correta de if . como isso é uma boa decisão de design?

ainda estou lutando para entender por que, se certa "lógica" está inerentemente ligada a uma visão específica e não tem importância, significado e / ou uso para qualquer outra coisa que não a própria visão, qual é exatamente o problema. simplesmente soa como extremismo / exagero da mvc para mim.

@andriijas se eu pudesse usar uma biblioteca de modelos diferente, eu usaria, infelizmente a decisão está fora de minhas mãos. como tal, toda e qualquer recomendação para usar uma biblioteca de modelos que permite "lógica", infelizmente, será ignorada.

Alguém realmente olhou como o atual if é implementado? (há também a menos que seja bom)

Agora que você viu como o if está implementado atualmente, pode fazer mais sentido para vocês porque o guidão tem um padrão simples e elegante que satisfaz a maioria das pessoas.

Veja aqui como é fácil estender

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

Aceite que todos os seus projetos de código aberto não fornecem tudo que você precisa para cozinhar seu bacon, apenas as bases.

@andriijas sim, unless é apenas um if com o resultado invertido. Não vejo como isso compensa nada. obrigado pelo link repo de helpers, já escrevi um helper, mas não vejo como isso compensa por nada.

O guiador tem um pouco mais de 10kb (minzipado) e o guidão tem um pouco menos de 3kb (minzipado). Portanto, você adiciona uma biblioteca de modelos de 10kb à sua base de código e precisa de mais 3kb apenas para poder adicionar lógica aos seus modelos. lógica que você e vários outros estão dizendo que você não deveria ter em seus modelos de qualquer maneira?

isso não responde a nenhuma das minhas perguntas e, na verdade, serve apenas para provar que é absurdo proibir testes condicionais que não sejam de existência / falsidade em seu bloco de instrução if .

@andriijas Estou olhando para /lib/handlebars/base.js#L97 , mas não tenho certeza do que você quer dizer. Parece que existe alguma forma de uso alternativo dele, mas a documentação não especifica isso. Você se importaria de explicar?

@constantology algumas pessoas podem precisar de outros 3kb, você e os outros caras neste tópico, por exemplo. O restante dos 3500 que estrelaram este repositório no github provavelmente não reclamarão, porque resolveram suas necessidades lógicas adicionando ajudantes ou fazendo isso antes de renderizar os modelos.

@piksel, o que você está vendo é o fato de que o if embutido é apenas um auxiliar como qualquer "complemento" com o qual muitos parecem ter problemas, pensando que os auxiliares são mais lentos ou algo assim.

Não há nada de errado em usar ajudantes em seu projeto. Em um projeto, eu uso alguns dos ajudantes de ganhos, copiados para meu próprio arquivo view_helper, portanto, é ainda menor que 3k.

Em um projeto de backbone, tenho um método getTemplateData em minhas visualizações, onde reduzo a lógica complexa a coisas mais fáceis que tornam os modelos mais limpos e mais fáceis de seguir, ah e também, é mais fácil testar a unidade em javascript simples do que modelos de guidão.

@andriijas que ainda não responde nenhuma das minhas perguntas ...

neste ponto, eu estaria apenas reiterando o que já disse, então se você sentir que pode realmente fornecer uma resposta razoável para qualquer uma ou todas as perguntas que já fiz, eu ficaria muito feliz em ouvir o que você precisa dizer. :)

ps o número de pessoas que marcaram o repo e / ou estão usando a biblioteca não é necessariamente uma indicação de quão boa é uma biblioteca. há mais usuários do Windows do que mac / linux combinados e - dependendo do site de estatísticas do navegador que você olhar - ainda há mais pessoas usando o Internet Explorer 6, 7 e 8 combinados do que um navegador mais moderno. isso não torna o Windows um sistema operacional melhor do que osx ou linux e não torna as versões mais antigas do Internet Explorer melhores do que os padrões modernos, navegadores compatíveis.

Toda essa discussão é estúpida para mim. Um ajudante if está lá, É LÓGICA. Portanto, todo o argumento sem lógica é um espantalho total. É como se um carro tivesse janelas que só rolam e as pessoas reclamam e querem que elas também rolem. E o fabricante disse que não ia mudar porque esses carros seguiam uma filosofia estrita de não ter vidros mecanicamente controlados ... Ou apóia ou não. Uma implementação medíocre não deve ser justificada com um argumento de espantalho.

Concordo totalmente e entendo não ter lógica de negócios nos templates. Mas, a menos que você esteja fazendo modelos extremamente triviais, você terá alguma lógica de visualização aí. Obviamente, o guiador reconhece isso, pois o auxiliar if existe. Trabalhar em torno de um auxiliar if tendão da perna adicionando um monte de lógica de visualização em seu código não é a resposta como @thany apontou. Já fiz isso antes, fica feio rápido.

@mikeobrien sim, já mencionei isso em um comentário anterior . foi uma das muitas perguntas que ficaram sem resposta.

Concordo totalmente e entendo não ter lógica de negócios nos templates. Mas, a menos que você esteja fazendo modelos extremamente triviais, você terá alguma lógica de visualização aí.

bem colocado. : ^)

@constantology doh, desculpe, acho que deveria ter lido os comentários anteriores melhor. : /

Eu concordo com @constantology

FWIW Eu acho o Handlebars uma biblioteca de modelos realmente elegante e bem escrita.

Eu entendo o conceito de blocos e auxiliares muito bem, no entanto, não acho que criar um auxiliar para fazer algo pequeno - que poderia ser tratado com mais elegância, apoiando-o na biblioteca central - significa uma separação clara de lógica e apresentação. CSS está adicionando suporte para declarações condicionais e parte disso já pode ser alcançado com consultas de mídia, então a lógica em uma linguagem puramente de apresentação não é necessariamente um grande boo-boo, se for simplesmente "ver lógica" como @mikeobrien colocou.

Eu sinto que esta limitação - falta de verificações condicionais em if / unless blocos - torna realmente difícil criar modelos elegantes e encapsulados.

Além disso, também concordo em ter um método para pré-processar dados antes de analisá-los por meio de um modelo, no entanto, apenas para alterações simples, não para reformatar a estrutura de dados inteira para dobrá-la à vontade de qualquer biblioteca. Porque?

1. isso pode afetar potencialmente o desempenho geral da análise se você precisar pegar uma estrutura de dados complexa e criar algo mais simples.
2. baseado em 1 , ele pode, potencialmente , tornar seu código de visualização mais frágil - e mais difícil de refatorar - se alterações forem feitas no esquema original.
3. isso também pode tornar a vinculação de dados bidirecional mais complicada, pois você não está mais mapeando a estrutura de dados original para a exibição, aumentando assim a quantidade de código que pode ser necessária para controlar as alterações.

Isso está apenas na minha cabeça, não fiz nenhuma pesquisa quantificável para comprovar nada disso, mas é o que pensar. : ^)

para a pergunta original, um auxiliar se com comparação seria a coisa errada. é um cenário comum e ajudantes como:
{{#ifzero count}} Sem resultados {{/ ifzero}}
{{#ifsingular count}} 1 resultado {{/ ifsingular}}
{{#ifplural count}} {{count}} resultados {{/ ifplural}}
seria mais útil e se traduziria no que ele realmente deseja fazer. a sintaxe if atual é útil para (não) exibir valores vazios. um cenário muito comum também. se alguém realmente precisa de um if com comparação, é muito provável que seja lógica de negócios e ele não deve fazê-lo no modelo.

Isso seria suficiente.
No entanto, ainda acho que não cabe a um mecanismo forçar os desenvolvedores a um determinado canto, seja esse _em princípio_ um bom canto ou não. Acho que deve caber ao desenvolvedor qual é a lógica de negócios e qual é a lógica do modelo.

Ou seja, a menos que a limitação de não poder fazer comparações seja puramente uma limitação técnica que de alguma forma a tornou um paradigma. Isso significa apenas que tal funcionalidade nunca poderia ser adicionada em caso de necessidade. Espero que não seja o que aconteceu.

Testando obrigado. Testando. Você não deseja colocar comparações em modelos porque não pode testar essa lógica facilmente. É muito mais simples criar valores booleanos simples por meio de um formatador de dados para seu modelo e testá-lo, do que conectar-se a algo como selênio e testá-lo lá.

Isso não é apenas teoria, não é apenas 'em princípio'. Provavelmente seria uma besteira de dívida técnica do mundo real colocar comparações regulares em modelos e não testar essa lógica. Não escreva ou use esses auxiliares. Ainda não usei um ajudante para o guidão. No entanto, se você usou um auxiliar, pode espioná-lo e testar para ter certeza de que a coisa funcionou, então é melhor do que comparações feitas nos modelos.

Existem muitos sistemas de template sem lógica que não oferecem comparações. Por exemplo, em linguagens fortemente tipadas como go, o que significa igualdade? Não há comparações nos modelos Go. Existem implementações de bigode e guiador em todas as linguagens e são iguais.

Remover lógica como comparações de modelos não torna sua vida mais difícil, mas sim mais fácil. A dívida técnica não é brincadeira, pode arruinar produtos e até empresas.

Vamos.
Comaprisões não são tão difíceis. Não é ciência de foguetes (ou cirurgia cerebral).

Em micro-modelos muito simples, você não precisa de lógica, mas se ficar mais complicado, você precisará de lógica nos modelos. Existe algo como "lógica de negócios", bem como "lógica de modelo". Determinar o que fazer quando há apenas um item de alguma coisa, ou dois, ou dez. Paginação, por exemplo. Divisores. Textos simples "abaixo de 50%" e "acima de 50%", e eu poderia continuar.

O fato de outros motores de template não possuírem lógica também não significa que você deva segui-los cegamente. Eles estão errados também, na minha opinião.

O fato é que, em algum ponto, você terá algum tipo de lógica que simplesmente não precisa ou não deseja na lógica de negócios, simplesmente porque não é lógica de negócios. Não posso concordar que meus colegas desenvolvedores tenham um valor booleano em, para cada tipo de comparação que qualquer modelo atual ou futuro possa precisar.

“pode arruinar produtos e até empresas”? Seriamente?
A funcionalidade inadequada também pode.

O que há de errado em enviar o que a maioria das pessoas precisa e você adicionar um ajudante
para o que você precisa? Todo mundo ganha. Não é tão difícil, não é como um foguete
Ciência.

Se for ciência do foguete: https://github.com/elving/swag

No sábado, 18 de maio de 2013, thany escreveu:

Vamos.
Comaprisões não são tão difíceis. Não é ciência de foguetes (ou cirurgia cerebral).

Em micro-modelos muito simples, você não precisa de lógica, mas se houver algum
mais complicado, você vai precisar de lógica nos modelos. Existe tal
coisa como "lógica de negócios", bem como "lógica de modelo". Determinando o que
fazer quando houver apenas um item de alguma coisa, ou dois, ou dez. Paging, para
exemplo. Divisores. Textos simples "abaixo de 50%" e "acima de 50%", e eu poderia continuar.

O fato de que outros motores de template também não têm lógica,
não significa que você deve segui-los cegamente. Eles entendem errado, também, na minha
opinião.

O fato é que, em algum momento, você terá algum tipo de lógica que você apenas
não precisa ou deseja na lógica de negócios, simplesmente porque não é um negócio
lógica. Não consigo converter para meus colegas desenvolvedores com um valor booleano
em, para cada tipo de comparação concebível que qualquer presente ou futuro
modelo pode precisar.

“pode arruinar produtos e até empresas”? Seriamente?
A funcionalidade inadequada também pode.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/wycats/handlebars.js/issues/206#issuecomment -18104713
.

A maioria das pessoas _não_ o usa pode ser devido ao problema descrito aqui: sem lógica. Portanto, é claro que a maioria das pessoas que usam ativamente ficará mais ou menos satisfeita com ele.

@thany eu sinto você e eu concordo com você.

Acho que as pessoas atrás do guidão não querem desistir desse, mas, ei, o que vou contar a vocês são uma notícia incrível:
Você pode _fork _ o projeto, adicionar o patch e usar seu próprio fork.
Devido à magia do git, deve ser bastante fácil acompanhar as novas versões apenas git pull ing.

E espere, fica melhor.

Se isso for uma grande necessidade e no geral for melhor, talvez as pessoas comecem a usar seu garfo ou, melhor ainda, os caras atrás do guiador irão fundir seu garfo de volta à origem / mestre: dançarino:

tenha um bom dia; D

Se eu me permitir o tempo, com certeza!

Eu concordo totalmente com @constantology. É insano ter template sem lógica. E se você queria ter um template sem lógica, por que você colocou lá a instrução: "if" que representa a lógica como perigo de cor vermelha ... Não faz sentido. Acho que a lógica de comparação básica é necessária como o sal na sopa. @mikeobrien : "Uma implementação

Há algo a ser dito sobre os modelos sem lógica. Porém, eu sinto que o problema é que todos aqui estão confundindo lógica de negócios com lógica de exibição. A lógica de negócios não tem lugar em modelos. Período. A lógica de visão, entretanto, é outra questão completamente. Acho que o guiador percebeu isso, e é por isso que adicionaram if / else em primeiro lugar, eles ficaram um pouco confusos ao longo do caminho.

Preciso saber se meu array de dados tem um ou vários itens e, com base nisso, quero juntá-los com vírgulas ou adicionar um plural a uma palavra. Com o atual bloco if, não posso fazer isso.

É por isso que fiz esta solicitação pull: https://github.com/wycats/handlebars.js/pull/566 e jsfiddle que o acompanha: http://jsfiddle.net/YsteK/

Esta solicitação pull fornece um novo auxiliar: ifTest, que obtém uma expressão javascript que é avaliada da mesma forma que o javascript faria com o contexto. Aproveitar.

Honestamente, essa é uma funcionalidade tão básica que me faz sentir que se você quiser manter essa mentalidade de não ter lógica incorporada à estrutura (o que parece completamente ilógico para mim!), Você precisa reconsiderar o uso de termos lógicos como "se" .

Eu me pego adicionando isso a muitos dos meus projetos simplesmente porque é muito útil ao comparar coisas como "0" e "1" com outros valores booleanos:

Handlebars.registerHelper ('ifCond', função (v1, v2, opções) {
if (v1 === v2) {
return options.fn (this);
}
retornar options.inverse (this);
});

Eu acho que é totalmente justo fazer com que a funcionalidade "if" existente funcione da maneira que funciona, mas faça um favor ao idioma inglês e escolha outra palavra (ou faça com que ela faça o que as pessoas esperam). Parece uma verdadeira perversão do termo "se" quando ele simplesmente não se comporta como uma declaração if verdadeira em qualquer outro contexto.

Eu gostaria de adicionar outro voto para remover if inteiramente ou permitir que if aceite alguns argumentos básicos de comparação, por exemplo, eq , ne , gt , etc. Você acabaria com {{#if arg1 eq arg2}} . Claro, remover if inteiramente faria mais sentido para a sua filosofia "sem lógica nos modelos" (agora é mais como "nenhuma lógica nos modelos _na maior parte do tempo_ mas _ às vezes_ está tudo bem").

Sem um ajudante, acabo fazendo coisas assim o tempo todo:

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

O que parece meio bobo adicionar todas essas propriedades extras a um objeto.

webgovernor - Verifique isto: http://jsfiddle.net/YsteK/

É um auxiliar que habilita essa funcionalidade. É necessária uma expressão javascript que é avaliada da mesma forma que o javascript faria com o contexto. Aproveitar.

Obrigado tniswong, isso é muito semelhante ao meu ajudante. Eu tenho o problema resolvido, eu só queria destacar a hipocrisia do dogma "sem lógica" do Guiador.

Sem problemas. Eu estou bem aí com você. Eu amo guidão, mas é bastante inútil sem este ajudante.

Enviei este auxiliar como uma solicitação pull, mas ele foi rejeitado. Então, enviei outra solicitação de pull que removeu o bloco if. Também rejeitado. /suspirar

Hahaha. O Github precisa de um botão de voto positivo.

Foi rejeitado? -_-

A obstinação da religião sem lógica de Handlebars é verdadeiramente estonteante.

566 e # 568

Ele mencionou que pode adicioná-lo ao README, mas não estou prendendo a respiração.

+1 para isso! Arghhh!

FWIW, o repositório Swag fornece ajudantes que adicionam comparação, classificação e outras coisas interessantes. Eu não construo nada no guiador sem ele.

Dito isso, eu pessoalmente concordo em deixar o Handlebars o menos lógico possível, já que o mantém limpo, extensível e sustentável. Se você quiser mais, contribua com um repositório como o _Swag_ para coisas fora do escopo do projeto. Caso os mantenedores deste projeto mudem de ideia, basta uma solicitação de pull: +1:

@aboutaaron Se você pretende fazer uma afirmação como "deixar o Handlebars ficar o menos lógico possível, já que o mantém limpo, extensível e sustentável", você deve pelo menos ter a decência de:

1. fornecer prova de que o guiador não contém lógica. Se você leu o tópico, verá que já foi provado que o guiador contém lógica incompleta na forma de uma instrução if que só verifica a "veracidade". Se você não leu o tópico, eu sugeriria que você fizesse isso.
2. fornecem provas de que o guiador fornece uma lógica incompleta na forma de uma instrução if que apenas verifica a "veracidade", de alguma forma, "o mantém limpo, extensível e sustentável".
   Isso não é uma contradição? Se o guidão for extensível, isso não significa que seria trivial fornecer uma implementação completa de instruções condicionais?
   Como, por exemplo, o guidão fornecendo uma instrução if tornaria menos limpo, extensível e sustentável do que um desenvolvedor que usa guidão E brindes ?
   Alguém poderia argumentar que usar os ajudantes de ganhos tornará uma base de código menos limpa, extensível e sustentável, já que você precisa usar um ajudante diferente para cada operador de comparação, ou seja, gt , gte , is , isnt , lt , lte bem como para cada operador lógico, ou seja, and , or .
   Como isso torna o código mais legível do que fazer tudo isso da mesma forma que faria - dentro de uma instrução if - em qualquer outra linguagem? Se fosse esse o caso, eu assumiria que as próprias linguagens de programação eliminariam as declarações condicionais que verificam qualquer coisa diferente de "veracidade". Eu não vejo isso acontecendo.

Se por acaso você for usar o velho - e refutado - argumento de "colocar lógica de negócios no modelo", não o faça. isso já foi abordado - várias vezes, por várias pessoas - neste tópico. Ao mesmo tempo, se isso for algo que você considera um argumento válido, isso eliminaria a necessidade de usar a biblioteca de ganhos , contradizendo sua afirmação anterior.

Concluindo, o fato de existirem várias bibliotecas por aí que buscam agregar completude à implementação incompleta de if no guidão - de uma forma ou de outra - mostra que existe a necessidade desse tipo de funcionalidade em seu essencial. Observe a própria linguagem JavaScript, o Harmony está introduzindo muitos recursos que foram fornecidos por bibliotecas, iteradores, módulos, geradores, classes, proxies, etc; e oe DOM API também implementou recursos que foram fornecidos por bibliotecas de terceiros, querySelector [All], CORS e há até uma implementação de DOM Promises em Chrome canary.

Não há nenhuma prova de que "deixar o Handlebars ficar o menos lógico possível, uma vez que o mantém limpo, extensível e sustentável". Ao mesmo tempo, outros e eu mostramos - em comentários anteriores deste tópico - que um pouco pode ir longe, se o guidão fornecesse uma implementação if , daria aos desenvolvedores uma API unificada para fazer seus modelos são mais fáceis de ler e manter.

@constantologia +1 Amém.

Acabei de chegar aqui depois de tentar {{#if something> something_else}} e perceber a verdade dessa situação. No entanto, estou tentado a concordar com o pessoal do guiador neste caso. Usei líquido por um longo tempo e tópicos de comentários como esse inevitavelmente levaram à adição de recursos incompletos, como matemática e concatenação de strings, que realmente pertenciam ao back end.

O objetivo com a instrução if "sem lógica" parece ser: fazer a parte lógica na parte de trás e apresentar o guidão com a "resposta" como uma única variável. Se a resposta for "sim", faça isso, caso contrário, faça a outra coisa. Não vejo nenhum problema com isso (depois de ler os comentários acima) e irei corrigir meu código agora.

Estou trabalhando em alguns aplicativos do Ember e gostaria de dar minha opinião. Acho que a instrução #if seria melhor se _ (opcionalmente) _ aceitasse um argumento. Eu entendo perfeitamente o desejo de deixar as coisas logic-less , mas às vezes pode ser muito frustrante trabalhar com elas.

Imagine uma lista simples de perguntas que podem ser selecionadas ou desmarcadas. Na verdade, qual é a diferença entre esses dois blocos de lógica?

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

Existem diferenças bastante grandes em como preciso escrever o código que sustenta esses dois exemplos. Seria muito bom ter a flexibilidade de escolha também. Eu também não vejo como o primeiro contém mais lógica do que o segundo.

Eu senti exatamente a mesma coisa que este tópico diz. Então, eu encontrei este tópico.
Portanto, acho que acabei de entender a filosofia do Guiador.
Então, descobri que precisava de uma coleção auxiliar como Swag.

Agora não tenho nenhum problema porque Swag vai me ajudar.
No entanto, fiquei confuso porque o auxiliar if padrão era muito simples.
Se você diz que o Hanlebars não tem lógica, duvido que o Handlebars precise de ajudantes integrados.
Se não tivesse ajudantes embutidos, acho que poderia entender a filosofia do Guiador com mais facilidade.

Posso não ter um bom entendimento sobre logic-less e business logic , quero lhe dizer o que pensei.

Eu acredito que você simplesmente não pode considerar um único if / menos (sem condicionais) como lógico, já que é apenas - no contexto sem lógica - um meio de representar um dado booleano, como o "{{foo}}" sintaxe é um meio de representar dados de string.

Portanto, acho que o seguinte comportamento deve ser interrompido: "Se não houver lógica, por que existe uma instrução if? HA-HA, xeque-mate !!!"

Em seguida, altere para "{{#exists}}" em vez de "{{#if}}" porque isso faz mais sentido.

Em 5 de outubro de 2013, às 10:52, cal127 [email protected] escreveu:

Eu acredito que você simplesmente não pode considerar um único if / menos (sem condicionais) como lógico, já que é apenas - no contexto sem lógica - um meio de representar um dado booleano, como o "{{foo}}" sintaxe é um meio de representar dados de string.

Portanto, acho que o seguinte comportamento deve ser interrompido: "Se não houver lógica, por que existe uma instrução if? HA-HA, xeque-mate !!!"

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

: thumbsup: para alterar {{#if}} para {{#exists}} ou {{#isTrue}}

Concordo que podemos encontrar um nome mais sensato. 'existe' seria suficiente, e minhas sugestões seriam 'verdadeiras' ou 'ativas'.

Mesmo assim, o nome 'se' ainda seria mais apropriado por razões históricas. Barras de controle 'if implementação não é sintaticamente diferente de qualquer outra implementação if, ela está em conformidade com a antiga sintaxe "if ([predicado]) [do sth]".

A diferença é que o [predicado] deve ser uma variável bool simples, não pode ser uma expressão. Mas esta não é a limitação de 'se'. Esta é uma limitação mais genérica causada pela falta de suporte para expressões do interpretador do guiador. (O que é exatamente o que torna o Handlebars menos lógico, eu acho)

O que significa que este 'se' não é diferente de qualquer outro 'se'.

E tentar mudar o nome de 'se' pode ser considerado heresia por alguns, não diga que não avisei.

Chame isso de {{#truthy}} e {{#falsey}} porque isso é tudo que {{#if}} e {{#unless}} fazem.

Para os desenvolvedores: tire a cabeça da areia. Seriamente. Você pode ver que há demanda por uma instrução if adequada (e pretendo usar a palavra 'demanda' literalmente), então vá e implemente-a, em vez de reclamar da falta de lógica. Se você deseja que seus modelos não tenham lógica, elimine TODA a lógica, incluindo {{#if}} e {{#each}} .

APENAS implemente uma instrução if adequada.
Pessoas que acreditam fortemente em sua falta de lógica devem optar por não usá-lo. Simples. Como. Este.

Eu até já fiz o trabalho para você.

https://github.com/wycats/handlebars.js/pull/566
https://gist.github.com/tniswong/5910264

Em 5 de outubro de 2013, às 15:20, thany [email protected] escreveu:

Chame-o de {{#truthy}} e {{#falsey}} porque isso é tudo o que {{#if}} e {{#unless}} fazem.

Para os desenvolvedores: tire a cabeça da areia. Seriamente. Você pode ver que há demanda por uma instrução if adequada (e pretendo usar a palavra 'demanda' literalmente), então vá e implemente-a, em vez de reclamar da falta de lógica. Se você quiser que seus modelos não tenham lógica, acabe com TODAS as lógicas, incluindo {{#if}} e {{#each}}.

APENAS implemente uma instrução if adequada. Pessoas que acreditam fortemente em sua falta de lógica devem optar por não usá-lo. Simples. Como. Este.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Obrigado por isso, mas a solução deve estar no pacote principal. O termo "ifTest" é presumivelmente apenas porque o Handlebars sequestra o termo "if" antes que você possa usá-lo.

Outra coisa é que seu ifTest pega uma string e faz a avaliação dessa string em tempo de execução, enquanto se um bloco if apropriado estivesse no pacote principal, ele poderia estar no modelo compilado (que é exatamente um dos fortes pontos - um que eu não gosto de jogar ao mar usando eval() para ifs e outros)

Você está 100% correto. Apenas usando as ferramentas disponíveis para mim no momento.

Independentemente disso, funciona.

Em 5 de outubro de 2013, às 15:41, thany [email protected] escreveu:

Obrigado por isso, mas a solução deve estar no pacote principal. Além disso, o termo "ifTest" é presumivelmente apenas porque o Handlebars sequestra o termo "if" antes de você poder usá-lo. Outra coisa é que seu ifTest pega uma string e faz a avaliação dessa string em tempo de execução, enquanto se um bloco if apropriado estivesse no pacote principal, ele poderia estar no modelo compilado (que é exatamente um dos fortes pontos - um que eu não gosto de jogar ao mar usando eval () para ifs e elses)

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Acabei de tropeçar neste tópico enquanto procurava por comparação no Guiador. Acho que você deve remover / renomear os blocos {{#if}} e {{#each}} ou implementar uma instrução if adequada. É um recurso básico para todos os idiomas. Período. Se você realmente deseja modelos sem lógica, por que não usa o Mustache?

Eu entendo que há uma opinião entre os desenvolvedores de que os modelos devem ser lidos por não desenvolvedores (ou seja, designers). Mas A) Eu nunca trabalhei com um designer onde isso fosse um problema, e B) Eu acho que a abordagem deve ser que uma solução genérica está disponível embutida, e como extensão você pode usar a verificação apenas booleana, então você tem uma escolha. Além disso, adicionar ajudantes como {{#ifValueEqualsA}} e {{#ifValueEqualsB}} forçará você a criar muitos códigos clichê que simplesmente não são necessários. Eu trabalho em um projeto móvel não muito grande e já tenho 200 linhas de código que apenas adicionam comparações para necessidades específicas. Isso vai contra (espero) a mentalidade de todos os desenvolvedores de que as coisas devem ser o mais genéricas possível.

@ cal127 "Eu acredito que você simplesmente não pode considerar um único se / menos (sem condicionais) como lógico" - então qual é o problema? Por que verificar uma expressão é mais lógico do que verificar um valor booleano? É um cheque. Período. Essa é a lógica que é feita aqui, não a expressão (uma vez que um valor booleano é - adivinhe - uma expressão). Claro, assumindo que a expressão representa não negócios, mas a lógica da IU.

Lamento que a ideia de motores de modelo sem lógica já pareça moribunda ... não vejo isso ainda acontecendo no futuro. Os desenvolvedores precisam de ferramentas que tornem as coisas mais fáceis e rápidas, e não mais complicadas.

@thany rocks. Eu vim sobre bigode (outra linguagem de modelo sem lógica) ontem e essa foi exatamente a pergunta que me veio à cabeça alguns momentos depois. Como os programadores alguma vez acharam isso legal. Isso só piora as coisas. O paradigma de programação que conheço é a "separação da lógica do NEGÓCIO da lógica da APRESENTAÇÃO". Essa definição significa que há lógica na apresentação (visualizações que contêm / incluem modelos em um padrão como mvc, por exemplo). Como é que eles estão tentando negar isso e removendo a lógica da apresentação.

Cenário: Estou executando um loop em uma exibição e desejo realizar uma ação após x iterações. Com o guidão, agora tenho que criar um helper e depois usar no loop, certo? como isso torna minha vida mais fácil? O que aconteceu a if count == x ????? Como isso é melhor do que usar uma linguagem como o próprio php para seus modelos? Como isso ajuda a projetar mecanismos de template lógicos?

Mim? Nada menos lógico para um trabalho orientado por lógica. Desculpa!

Eu não posso acreditar o quão ignorante vocês podem ser, queridos crentes no sem lógica. Simplesmente não é uma realidade, é um mito completo, uma falácia, uma falsa religião. Nenhum modelo com mais do que algumas linhas será totalmente sem lógica. Simplesmente não é prático.

Agora, impor tal crença aos seus usuários é uma decisão inteiramente sua. Mas continuar rejeitando qualquer demanda por lógica é prova de estupidez e ignorância. Especialmente neste caso particular, uma vez que já existe uma quantidade de lógica possível, embora minúscula.

Mais uma vez, recomendo fortemente que você reconsidere. Não, espere, não reconsidere. Apenas ouça e faça a coisa certa. Pessoas que não querem nenhuma lógica boba em seus modelos, podem seguir em frente e continuar seus caminhos perversos e saltar por todos os tipos de obstáculos para não usar a lógica.

Estender o bloco if para fazer comparações adequadas não elimina seu uso atual. Isso não causará problemas para aqueles que ainda não viram a luz lógica, essas pessoas podem continuar a codificar como antes.

Não se trata de legal; você mesmo usa a separação entre a lógica e a apresentação como argumento e então a ignora para pedir que sua vida seja simplificada. Você poderia ter adicionado qualquer uma das bibliotecas de modelos de guiador padrão ao seu projeto ou escrito o seu próprio.

Você ou ninguém mais abordou qualquer um dos numerosos argumentos contra isso em qualquer um dos numerosos tópicos. Apenas para que esses argumentos sejam claros neste tópico:
1) Você estará perturbando um ecossistema existente; o que causará conflitos e retrabalhos para as equipes que desejam atualizar, mas têm seu próprio FI há cerca de 2 anos.
2) Existem bibliotecas auxiliares que adicionarão o, se necessário, junto com todos os outros auxiliares que você solicitará em seguida.
3) Assim que for acordado adicionar este 'se', o novo argumento será a sua implementação. Nome. Sintaxe. Argumentos. Você pode prometer que ficará feliz com o caso, mas outros não. Haverá imediatamente um (s) novo (s) tópico (s) argumentando que deveria funcionar de alguma outra maneira.
4) O 'se' existente é exatamente o que deveria estar lá para -render-. "Exibir X se Y estiver presente". Não se trata de lógica de negócios; o que deve acontecer no seu modelo (eu sugiro o Backbone, então você pode ter o que quiser que o seu if seja, apenas um método isXXX () no seu modelo).

Já que estamos pedindo coisas um ao outro, por favor, não continue fazendo isso se você não tiver um bom argumento técnico para fazer uma grande mudança. Ficar frustrado é bobagem - Adicione o 'SE' que você deseja e pronto.

1) Não, você não vai. Se você não fizer nada, os modelos devem continuar funcionando. Claro que tudo deve ser compatível com versões anteriores. E mesmo se não for, simplesmente não atualize.
2) Uma declaração if é elementar. O que você está dizendo é que as rodas de um carro agora são opcionais.
3) A sintaxe de uma instrução if é de muito pouca importância. Cada linguagem de programação tem um, e cada um deles faz exatamente a mesma coisa. Portanto, escolha um e ficará bem. Mais importante, ter QUALQUER instrução if adequada é melhor do que temos agora.
4) Errado, pesquise "lógica do modelo" para cima.

Quanto à sua última posição, o argumento _foi_ feito, e é válido. Tem sido discutido várias vezes, mas realmente parece uma religião. Inquebrável, mas tão frágil.

George Frick -

1) Como isso é diferente de atualizar QUALQUER outra estrutura ou biblioteca que já existiu?
2) Você está certo. Porém, adicionar manualmente esses recursos básicos não deve ser necessário para algo tão fundamental e necessário.
3) É para isso que servem as solicitações pull.
4) Você perdeu completamente o ponto. Ninguém neste segmento está defendendo a lógica de negócios na camada de visualização. Estamos defendendo uma lógica de exibição ÚTIL na camada de visualização. O "se" fornecido não é um verdadeiro se, tornando-o confuso para qualquer pessoa que já tenha usado uma linguagem de programação. É mais um "existe".

Se você acha que adicionar isso faria com que as pessoas usassem lógica de negócios em modelos, provavelmente você está certo porque não pode consertar estúpidos. Só porque alguém PODE fazer algo ruim não significa que você deva evitar que outras pessoas façam algo bom (e necessário) no processo.

Em 22 de novembro de 2013, às 15:55, George Frick [email protected] escreveu:

Não se trata de legal; você mesmo usa a separação entre a lógica e a apresentação como argumento e então a ignora para pedir que sua vida seja simplificada. Você poderia ter adicionado qualquer uma das bibliotecas de modelos de guiador padrão ao seu projeto ou escrito o seu próprio.

Você ou ninguém mais abordou qualquer um dos numerosos argumentos contra isso em qualquer um dos numerosos tópicos. Apenas isso para que os argumentos sejam claros neste tópico:
1) Você estará perturbando um ecossistema existente; o que causará conflitos e retrabalhos para as equipes que desejam atualizar, mas têm seu próprio FI há cerca de 2 anos.
2) Existem bibliotecas auxiliares que adicionarão o, se necessário, junto com todos os outros auxiliares que você solicitará em seguida.
3) Assim que for acordado adicionar este 'se', o novo argumento será a sua implementação. Nome. Sintaxe. Argumentos. Você pode prometer que ficará feliz com o caso, mas outros não. Haverá imediatamente um (s) novo (s) tópico (s) argumentando que deveria funcionar de alguma outra maneira.
4) O 'se' existente é exatamente o que deveria estar lá para -render-. "Exibir X se Y estiver presente". Não se trata de lógica de negócios; o que deve acontecer no seu modelo (eu sugiro o Backbone, então você pode ter o que quiser que o seu if seja, apenas um método isXXX () no seu modelo).

Já que estamos pedindo coisas um ao outro, por favor, não continue fazendo isso se você não tiver um bom argumento técnico para fazer uma grande mudança. Ficar frustrado é bobagem - Adicione o 'SE' que você deseja e pronto.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

@thany
Há uma diferença entre refutar um argumento e rejeitá-lo. "ERRADO" equivale a "NUH UH!".
Tente não ser tão pessoal sobre isso também.

@tniswong
1) Não é, o mesmo se aplica a qualquer estrutura.
2) Se você aplicar isso em um sentido geral, o Node deve incluir todos os seus componentes. Pode-se argumentar que eles são fundamentais ou necessários, mas levaria à ideia de que agrupá-los fora da estrutura padrão é uma boa abstração e separação. Muitos projetos simplesmente não precisam de nenhum deles e outros precisam de versões especiais. Assim, você pode conectar um conjunto padrão, escrever o seu próprio ou não usar nenhum. Não há (novamente) nenhuma razão tecnicamente sólida para que todos esses auxiliares sejam incluídos por padrão.
3) Sua declaração não nega de forma alguma o ponto original, na verdade - você o ajuda. 20 solicitações pull para corrigir If. Aposto que a equipe de desenvolvimento vai adorar passar por eles.
4) Exatamente, é um 'existe'. Renderize se existir.
Quando você não consegue escrever sobre 'ninguém, nunca', toma um único contra-exemplo. _ levanta a mão_.

Pelas notas acima, parece-me que uma das seguintes opções é necessária:

1. Renomeie if para exists e pare de chamar o guidão "sem lógica" (porque não é)
2. Adicione suporte para if para se comportar como uma instrução if .
3. Remova if inteiramente.

Eu ficaria feliz com qualquer uma dessas opções.

Não se esqueça de {{#unless}}

Em 22 de novembro de 2013, às 4:40 PM, Aaron M [email protected] escreveu:

Pelas notas acima, parece-me que uma das seguintes opções é necessária:

Renomeie se para existe e pare de chamar os guidões "sem lógica" (porque não é)
Adicione suporte para que o if se comporte como uma instrução if.
Remova-o inteiramente.
Eu ficaria feliz com qualquer uma dessas opções.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Acho que o que isso realmente significa é bem resumido por Aaron.

1. Há uma hipocrisia que precisa ser tratada alegando ser sem lógica E fornecendo um se / menos.
2. O "se" fornecido é um nome impróprio.

Corrija os dois e esse argumento vai embora.

Em 22 de novembro de 2013, às 4:43 PM, Todd Niswonger [email protected] escreveu:

Não se esqueça de {{#unless}}

Em 22 de novembro de 2013, às 4:40 PM, Aaron M [email protected] escreveu:

Pelas notas acima, parece-me que uma das seguintes opções é necessária:

Renomeie se para existe e pare de chamar os guidões "sem lógica" (porque não é)
Adicione suporte para que o if se comporte como uma instrução if.
Remova-o inteiramente.
Eu ficaria feliz com qualquer uma dessas opções.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

@georgefrick
Eu estava descartando seu argumento simplesmente porque já havia sido refutado um milhão de vezes antes. Já discutimos isso há muito tempo e deve acabar. A instrução if deve ser adicionada, ninguém ficará em desvantagem e todos ficarão felizes. Não querer é o mesmo que não querer ar condicionado em TODAS as casas. Serei o juiz do que quero em minha casa. Se estiver no seu e você não quiser, deixe como está. Simples assim.

@webgovernor
Nenhuma renomeação precisa ser feita. Uma declaração if adequada pode ser totalmente compatível com a atual. Atualmente é apenas "if boolean then ...", e qualquer instrução if com todos os recursos fará exatamente isso, apenas esse booleano agora pode ser qualquer expressão em vez de apenas uma variável.

@tniswong
Que legal da parte deles, certo? Para adicionar uma tag extra suja porque o bloco if, conforme implementado, é tão simplificado que não pode nem mesmo negar uma expressão. Mas em um guiador futuro, a tag menos pode simplesmente se tornar um apelido para "se não". Tipo do..while versus while..do na programação, onde os dois existem principalmente para facilitar a leitura e não _realmente_ por qualquer razão técnica.

Eu também desejo comparações básicas nos guiadores. Eu entendo a filosofia sem lógica. Também acredito que o suporte básico de comparação seria mais intuitivo e permitiria aos usuários trabalhar com mais eficiência. Se os usuários em massa estão movendo a lógica de comparação básica para um ajudante, essa filosofia não está fazendo um favor a eles ou dissuadindo um comportamento percebido abaixo do ideal - está apenas criando mais trabalho.

@jeremiahlee Não tenho certeza se você concorda ou discorda de mim, posso ler seu comentário de qualquer maneira :)

De qualquer forma, já trabalhei com barras de orientação no passado e solicitei que implementassem um bloco if adequado. Isso resultou em uma avalanche de comentários sobre uma filosofia falsa de que a lógica deveria permanecer no modelo. Nenhum desenvolvedor de Handlebars gostaria de pensar um milímetro fora de seu próprio mundo minúsculo (há uma palavra rude para isso, mas vou pular). Basta olhar para este tópico como prova.

Isso me forçou a escrever um auxiliar chamado "quando" que faz comparações. Ainda sem uma construção de bloco if adequada, mas perto o suficiente para mim na época. No entanto, isso criou um monte de trabalho desnecessário para mim.

@thany : Concordo que as

Eu também votarei a favor de @thany e outros argumentos. As instruções if else são muito básicas.
Classes condicionais e select caixas com option s pré-selecionados devem ser viáveis ​​com o pacote padrão de guidão.

Com ajudantes aninhados, isso não é mais um problema, por exemplo

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

bom exemplo @mmun : +1:

Um pouco estranho, e não vejo nenhum combinador booleano ... Mas acima de tudo, isso não muda o ponto de vista geral dos mantenedores deste projeto, que parece ser um inquebrável "SEM LÓGICA !! 11 !! 1! 1 "tipo de visão.