Esto lo pueden hacer los ayudantes.
Mira esto: http://kan.so/packages/details/handlebars-helpers
Existe ifequal helper que permite comparar dos valores.
Se puede utilizar una solución similar para sus necesidades.

Tenía miedo de eso.
Sé que algo así se puede hacer con ayudantes ... Pero, quiero decir, comparar cosas es tan absolutamente básico que debería estar en el paquete predeterminado.

Si se incluyera en el paquete, sería una ayuda de todos modos.

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

@andriijas tiene razón, de hecho sería un ayudante;) O no, ya que un bloque if es tan elemental.
Gracias por el enlace. Es útil, pero estoy ansioso por escribir un "ayudante" que sobrescriba el if original, para convertirlo en un _proper_ if. Estoy seguro de que es posible. Cualquier motor de plantillas que se precie necesita un formato condicional adecuado. Los manillares no deberían ser una excepción.

Debe superar el hecho de que todo en el manillar que aplica la lógica empresarial a las plantillas son ayudantes.

Todos los incorporados en cada uno, si, etc., se definen a través de registerHelper. Cheque:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

Así que no hay nada "malo" en usar ayudantes. Handlebars es más o menos un compilador de plantillas de bigote y, para obtener esa lógica comercial adicional, utilizan ayudantes. si cree que acaba de tener una mala experiencia con el uso de la palabra "ayudantes", tal vez de rieles o algo así.

Nunca dije que hubiera algo malo con los "ayudantes". Es solo que una declaración if adecuada no se supone que sea una extensión en mi opinión. Un ayudante (de nuevo, en mi opinión) es algo específico de un CMS o algo así. Un ayudante es algo que realiza una operación o condición especial. Algo que no es para todos. Es decir, si se define fuera de la biblioteca principal. Tal vez un poco como jQuery-plugins: las cosas más elementales están integradas, las cosas que te ayudan a empezar. Pero las cosas que no son para todos se definen fuera de la biblioteca principal (es decir, en complementos). En términos de jQuery, una función de filtro simple no sería un complemento.

Una declaración if (en mi opinión) no se aplica a este paradigma de complemento. Es elemental, es uno de los principios más básicos de programación y motores de plantillas ...

Entonces, un seguimiento rápido. Esto es lo que tengo hasta ahora:

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

Usando esto en mi plantilla como {{#when riskfactor eq 0}}...{{/when}} obtengo en mi consola una matriz de [6, undefined, 0, function()] . El último que consigo. Eso es lo que necesito llamar para procesar el contenido de este bloque de cuándo. Los tres primeros ... bueno, no tanto. El "6" es en realidad el valor de "factor de riesgo". Bien, puedo ir con eso. Lo indefinido me supera. Creo que Handlebars está tratando de evaluarlo en el objeto de entrada, pero eso no funcionará. Quiero obtener cosas que estén en realidad _en_ ​​la plantilla, porque valores como estos no tienen nada que ver con mi objeto.

Esperaba algo como ["riskfactor", "eq", "0", function()] . Solo entonces mi función puede seguir adelante y procesar eso. ¿Cómo voy a hacer eso con "indefinido"?

Creo que la filosofía de Handlebars (y otras plantillas "sin lógica") es que el contexto que llega para la plantilla ya debería estar completamente procesado. Si las estructuras de datos internas de su aplicación no se alinean perfectamente con lo que sería apropiado para una plantilla (que será el caso casi siempre), entonces debe insertar un paso antes de renderizar la plantilla que construye el contexto de la plantilla a partir de los datos internos de su aplicación. estructuras.

Creo que esa es la intención cuando la gente habla de "separar la lógica de la presentación". Piense en Handlebars como el componente de visualización de un sistema MVC. Tu modelo ya existe; todo lo que debe escribir ahora es el controlador (en este caso, es un conjunto de enlaces unidireccionales del modelo a la vista).

Para responder a su pregunta más reciente, desea utilizar esto:

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

Las expresiones de manillar son nombres de variables o cadenas. Si es un nombre de variable, obtendrá el valor de la variable cuando se busque en el contexto actual, no el nombre.

Esto está fuera del ámbito de los manillares, como algunos han señalado.

No.
CUALQUIER sistema de plantillas puede hacer un simple bloque comparativo if-else-block, y Handlebars no puede. Eso hace que Handlebars sea ridículamente incompleto, sus creadores incompetentes (lo que es poco probable) o un sistema con una perspectiva nublada de las tareas de un sistema de plantillas.

ENTONCES NO use un MOTOR DE PLANTILLA SIN LÓGICA. KTHXBAI!

Entiendo. Toodles.

@thany , @andriijas probablemente fue un poco duro, pero tiene razón. El manillar está diseñado para que no tenga lógica. Definitivamente puedes hacer una bicicleta con motor, pero muchas empresas están felices de fabricar solo bicicletas sin motor. Del mismo modo, puede crear un sistema de plantillas con más lógica, pero eso no es algo que Handlebars esté tratando de hacer. Lo siento, no es lo que estabas buscando.

Tengo que ponerme del lado de @thany en el if helper. Deberíamos poder pasarle cualquier predicado. No poder limitar realmente su utilidad. Entiendo la filosofía detrás de las plantillas sin lógica, pero una implementación dogmática no es realmente pragmática (y, por lo tanto, la existencia de los ayudantes, ¿verdad?). Yo diría que esto se parece más a que la compañía de bicicletas agregue una relación de transmisión variable, lo que sería totalmente razonable.

Por cierto, si desea enfurecerse contra la máquina y hacer esto, puede crear un ayudante que tome el predicado como una cadena y luego evaluarlo (y hacer esto dos veces 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, mírelo desde la perspectiva de las mejores prácticas, su Back-end debería servir los datos con toda la lógica ya calculada. El Front-end (plantilla) debería simplemente renderizarlo ... si tiene una buena representación JSON de sus objetos de backend que 95 % de casos pueden satisfacerse con condicionales incorporados http://handlebarsjs.com/#conditionals

En serio, no TODAS (ni siquiera el 95%) de las decisiones que se toman están orientadas al backend. Por ejemplo, para determinar qué nombre de clase representar, es totalmente razonable tomar esa decisión en la plantilla. Algo así está 100% vinculado a la interfaz / plantilla. Al backend no podría importarle menos qué nombre de clase se representa. ¿O qué pasa con las palabras en singular / plural? Esa es otra cosa que no se puede hacer con el bloque if.

En mi opinión, el backend es responsable de proporcionar datos, y SOLO datos, cuando se trabaja con plantillas enriquecidas como esta. Si el backend necesita dar al analizador de plantillas variables listas para cada situación sobre la que la plantilla podría tomar una decisión (considerando cierta flexibilidad aquí), serían ridículamente complicadas solo por la gran cantidad de variables, y mucho menos por la backend que los hace.

También puede poner HTML en el backend si cada decisión que necesita una plantilla necesita otra modificación en el backend. Eso solo quita una gran parte del propósito de las plantillas. Las decisiones vinculadas al backend están en un nivel completamente diferente. Un bloque if no es necesariamente lógico. Es solo decidir qué / cómo renderizar.

No puedo creer que este problema requiera una discusión tan larga, ¿es realmente demasiado pedir un bloque if adecuado? :(

No voy a argumentar a favor ni en contra de la implementación de un ayudante de comparación básico, pero este es el caso muy real en el que no creo que podría haber renderizado la plantilla sin usar un ayudante o cambiar la estructura de datos:

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

Pero, de nuevo, el ayudante que escribí tenía tres líneas de código:

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

Estoy de acuerdo con

¿Por qué exactamente una plantilla no puede tener lógica? y ¿cómo los manillares proporcionan una separación entre la lógica y la presentación? todavía tiene una declaración if ¿no? ¿Está diciendo que una declaración if que simplemente prueba la existencia y / o la "falsedad" no es de ninguna manera diferente a una declaración if que verifica la (in) igualdad o cualquier otra condición?

la única diferencia, real, es que, a diferencia de otras bibliotecas de plantillas, el manillar tiene una implementación muy pobre / incompleta de dicha lógica bajo el pretexto de ser "sin lógica". Lo siento, pero eso es una tontería. si desea eliminar la lógica, debe eliminar la instrucción if completo. Sin embargo, no hará eso, porque en última instancia, una plantilla necesita lógica por las mismas razones por las que el manillar todavía tiene una declaración if .

entonces, la declaración "separando la lógica de la presentación". es falaz, no solo por las razones anteriores, también porque no está eliminando la "lógica" de la plantilla, simplemente la está moviendo a otra parte de la plantilla, es decir, el ayudante, y tal vez obtenga la reutilización del código. lo cual sería algo bueno, y tal vez no lo haga, en cuyo caso puede obtener cualquier número de ayudantes que realicen casi / exactamente lo mismo que otros ayudantes, debido a una pequeña diferencia que habría sido mejor al proporcionar una implementación correcta de if . ¿Cómo es esta una buena decisión de diseño?

Todavía estoy luchando por entender por qué, si cierta "lógica" está intrínsecamente ligada a una vista específica y no tiene importancia, significado y / o utilidad para otra cosa que no sea la vista misma, cuál es exactamente el problema. simplemente me suena a mvc extremismo / exageración.

@andriijas, si pudiera usar una biblioteca de plantillas diferente, lo haría, desafortunadamente la decisión está fuera de mis manos. como tal, todas y cada una de las recomendaciones para usar una biblioteca de plantillas que permita la "lógica" desafortunadamente caerán en oídos sordos.

¿Alguien ha mirado realmente cómo se implementa el if actual? (también hay a menos que sea bueno)

Ahora que ha visto cómo se implementa actualmente el if, podría tener más sentido para ustedes por qué los manillares tienen una configuración predeterminada simple y elegante que satisface a la mayoría de las personas.

Mira aquí lo fácil que es extender

https://github.com/elving/swag

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

Acepte que todos sus proyectos de código abierto no proporcionan todo lo que necesita para cocinar su tocino, solo las bases.

@andriijas sí, unless es solo un if con el resultado invertido. No veo cómo esto compensa nada. gracias por el enlace del repositorio de ayudantes, ya escribí un ayudante, aunque de nuevo, no veo cómo esto compensa nada.

El manillar pesa un poco más de 10 kb (minzip) y el swag un poco menos de 3 kb (minzip). Entonces agrega una biblioteca de plantillas de 10kb a su base de código y necesita otros 3kb solo para poder agregar lógica a sus plantillas. lógica que usted y varios otros dicen que no debería tener en sus plantillas de todos modos?

esto no responde a ninguna de mis preguntas y, de hecho, solo sirve para demostrar el punto de que no tiene sentido rechazar pruebas condicionales que no sean existencia / falsedad en su bloque de declaración if .

@andriijas Estoy mirando /lib/handlebars/base.js#L97 , pero no estoy muy seguro de lo que quieres decir. Parece que hay alguna forma de uso alternativo, pero la documentación no lo especifica. ¿Te importaría explicarme?

@constantology, algunas personas pueden necesitar otros 3kb, tú y los otros chicos de este hilo, por ejemplo. Es probable que el resto de los 3500 que protagonizaron este repositorio en github no se quejen, porque han resuelto sus necesidades lógicas agregando ayudantes o haciéndolo antes de renderizar las plantillas.

@piksel lo que estás viendo es el hecho de que el if incorporado es solo un ayudante como cualquier "complemento" con el que muchos parecen tener un problema, pensando que los ayudantes son más lentos o algo así.

No hay nada de malo en usar ayudantes en su proyecto. En un proyecto, utilizo algunos de los ayudantes de botín, copiados en mi propio archivo view_helper, por lo que es incluso menos de 3k.

En un proyecto de red troncal tengo un método getTemplateData en mis vistas, donde reduzco la lógica compleja a cosas más fáciles que hacen que las plantillas sean más limpias y fáciles de seguir, ah y también, es más fácil probar un Javascript simple que las plantillas de manillar.

@andriijas que todavía no responde a ninguna de mis preguntas ...

En este punto, solo estaría reiterando lo que ya he dicho, por lo que si cree que realmente puede proporcionar una respuesta razonable a alguna o todas las preguntas que ya he formulado, estaría muy feliz de escuchar lo que tiene que hacer. decir. :)

ps, el número de personas que protagonizaron el repositorio y / o están usando la biblioteca no es necesariamente una indicación de lo buena que es una biblioteca. hay más usuarios de Windows que de mac / linux combinados y, según el sitio de estadísticas del navegador que mire, todavía hay más personas que usan Internet Explorer 6, 7 y 8 combinados que un navegador más moderno. eso no hace que Windows sea un sistema operativo mejor que osx o linux y no hace que las versiones anteriores de Internet Explorer sean mejores que los navegadores compatibles con los estándares modernos.

Toda esta discusión es estúpida para mí. Hay un if ayudante, ES LÓGICO. Así que todo el argumento sin lógica es un hombre de paja total. Es como si un automóvil tuviera las ventanillas que solo se bajaran y la gente se quejara y quisiera que también se subieran. Y la manufactura dijo que no lo iban a cambiar porque estos autos seguían una estricta filosofía de no tener ventanas controladas mecánicamente ... O lo apoyas o no. Una implementación a medias no debe justificarse con un argumento de hombre de paja.

Estoy totalmente de acuerdo y entiendo que no hay lógica empresarial en las plantillas. Pero a menos que esté haciendo plantillas extremadamente triviales, tendrá algo de lógica de vista allí. Handlebars obviamente reconoce esto ya que existe el asistente if . Trabajar alrededor de un if helper paralizado agregando un montón de lógica de vista en su código no es la respuesta como

@mikeobrien sí, ya lo mencioné en un comentario anterior . fue una de las muchas preguntas que han quedado sin respuesta.

Estoy totalmente de acuerdo y entiendo que no hay lógica empresarial en las plantillas. Pero a menos que esté haciendo plantillas extremadamente triviales, tendrá algo de lógica de vista allí.

bien dicho. : ^)

@constantology doh, lo siento, supongo que debería haber leído mejor los comentarios anteriores. : /

Estoy de acuerdo con @constantology

FWIW Me parece que Handlebars es una biblioteca de plantillas realmente elegante y bien escrita.

Entiendo bien el concepto de bloques y ayudantes, sin embargo, no creo que crear un ayudante para hacer algo pequeño, que podría manejarse de manera más elegante al admitirlo en la biblioteca central, signifique una clara separación de la lógica y la presentación. CSS está agregando soporte para declaraciones condicionales y algo de esto ya se puede lograr con consultas de medios, por lo que la lógica en un lenguaje puramente de presentación no es necesariamente un gran boo-boo, si es simplemente "ver lógica" como lo expresó

Siento que esta única limitación, la falta de controles condicionales en los bloques if / unless , hace que sea muy difícil crear plantillas elegantes y encapsuladas.

Además, también estoy de acuerdo con tener un método para preprocesar los datos antes de analizarlos a través de una plantilla, sin embargo, solo para cambios simples, no para volver a formatear la estructura de datos completa para doblarla a la voluntad de cualquier biblioteca. ¿Por qué?

1. esto podría afectar potencialmente el rendimiento general del análisis si necesita tomar una estructura de datos compleja y crear algo más plano.
2. basado en 1 , puede, potencialmente , hacer que su código de vista sea más frágil y más difícil de refactorizar si se realizan cambios en el esquema original.
3. también podría hacer que la vinculación de datos bidireccional sea más complicada, ya que ya no está mapeando la estructura de datos original a la vista, lo que aumenta la cantidad de código que puede necesitar para realizar un seguimiento de los cambios.

Esos están fuera de mi cabeza, no he hecho ninguna investigación cuantificable para respaldar nada de eso, pero es motivo de reflexión. : ^)

para la pregunta original, un ayudante if con comparación sería incorrecto. es un escenario común y ayudantes como:
{{#ifzero count}} Sin resultados {{/ ifzero}}
{{#ifsingular count}} 1 resultado {{/ ifsingular}}
{{#ifplural count}} {{count}} resultados {{/ ifplural}}
sería más útil y se traduciría en lo que realmente quiere hacer. la sintaxis if actual es útil para (no) mostrar valores vacíos. un escenario muy común también. si alguien realmente necesita un si con comparación, es muy probable que sea lógica de negocios y no debería hacerlo en la plantilla.

Eso lo haría de hecho.
Sin embargo, sigo pensando que no depende de un motor forzar a los desarrolladores a ir a una determinada esquina, ya sea que, en principio, sea una buena esquina o no. Creo que debería depender del desarrollador cuál es la lógica empresarial y cuál es la lógica de la plantilla.

Es decir, a menos que la limitación de no poder hacer comparaciones sea puramente una limitación técnica que de alguna manera lo convirtió en paradigma. Eso solo significa que dicha funcionalidad nunca podría agregarse si surgiera la necesidad. Espero que no sea eso lo que pasó.

Prueba de gracias. Pruebas. No desea poner comparaciones en plantillas porque no puede probar esta lógica fácilmente. Es mucho más sencillo crear valores booleanos simples a través de un formateador de datos para su plantilla y probarlo, que conectarlo a algo como selenio y probarlo allí.

Esto no es solo teoría, no es solo "en principio". Probablemente sería una tontería de la deuda técnica del mundo real poner incluso comparaciones en las plantillas y no probar esta lógica. No escriba ni utilice estos ayudantes. Todavía no he usado un ayudante para el manillar. Sin embargo, si usó un ayudante, podría espiarlo y probarlo para asegurarse de que funcionó, por lo que es mejor que las comparaciones que se construyen en las plantillas.

Hay muchos sistemas de plantillas libres de lógica que no ofrecen comparaciones. Por ejemplo, en lenguajes fuertemente tipados como go, ¿qué significa igualdad? No hay comparaciones en las plantillas de Go. Hay implementaciones de bigote y manillar en todos los idiomas y son lo mismo.

Eliminar la lógica como las comparaciones de las plantillas no hace su vida más difícil, la hace más fácil. La deuda técnica no es una broma, puede arruinar productos e incluso empresas.

Vamos.
Las prisiones no son tan difíciles. No es ciencia espacial (o cirugía cerebral).

En micro-plantillas muy simples no necesitas lógica, pero si se vuelve más complicado, necesitarás lógica en las plantillas. Existe la "lógica empresarial", así como la "lógica de plantilla". Determinar qué hacer cuando solo hay un elemento de algo, o dos, o diez. Paginación, por ejemplo. Divisores. Textos simples de "menos del 50%" y "más del 50%", y podría continuar.

El hecho de que otros motores de plantillas tampoco tengan lógica en ellos tampoco significa que deba seguirlos ciegamente. Ellos también se equivocan, en mi opinión.

El hecho es que, en algún momento, tendrá algún tipo de lógica que simplemente no necesita o no desea en la lógica empresarial, simplemente porque no es lógica empresarial. No puedo creer que mis compañeros desarrolladores tengan un valor booleano para cada tipo de comparación concebible que cualquier plantilla actual o futura pueda necesitar.

"puede arruinar productos e incluso empresas"? ¿Seriamente?
La funcionalidad incorrecta también puede hacerlo.

¿Qué hay de malo en que envíe lo que la mayoría de la gente necesita y usted agregue un ayudante?
para lo que necesitas? Todos ganan. No es tan difícil, no es como un cohete
Ciencias.

Si es ciencia espacial: https://github.com/elving/swag

El sábado 18 de mayo de 2013, thany escribió:

Vamos.
Las prisiones no son tan difíciles. No es ciencia espacial (o cirugía cerebral).

En micro-plantillas muy simples no necesita lógica, pero si obtiene alguna
más complicado, necesitará lógica en las plantillas. Hay tal
algo como "lógica empresarial", así como "lógica de plantilla". Determinando que hacer
hacer cuando solo hay un elemento de algo, o dos, o diez. Paginación, para
ejemplo. Divisores. Textos simples de "menos del 50%" y "más del 50%", y podría continuar.

El hecho de que otros motores de plantillas tampoco tengan lógica en ellos,
no significa que debas seguirlos ciegamente. Ellos también se equivocan en mi
opinión.

El hecho es que, en algún momento, tendrás algún tipo de lógica que simplemente
no necesita ni quiere en la lógica empresarial, simplemente porque no es empresarial
lógica. No puedo convencer a mis compañeros desarrolladores de tener un valor booleano
en, para cada tipo de comparación concebible que cualquier presente o futuro
plantilla alguna vez podría necesitar.

"puede arruinar productos e incluso empresas"? ¿Seriamente?
La funcionalidad incorrecta también puede hacerlo.

-
Responda a este correo electrónico directamente o véalo en Gi
.

La mayoría de las personas _no_ usarlo puede deberse al problema que se describe aquí: no hay lógica. Entonces, por supuesto, la mayoría de las personas que lo usan activamente estarán más o menos contentas con él.

@gracias te siento y estoy de acuerdo contigo.

Creo que la gente detrás del manubrio no quiere renunciar a este, pero bueno, lo que les voy a decir son noticias increíbles:
Puede _fork _ el proyecto, agregar el parche y usar su propio fork.
Debido a la magia de git, debería ser bastante fácil mantenerse al día con las nuevas versiones con solo git pull ing.

Y espéralo, se pone mejor.

Si esto resulta ser una gran necesidad y en general es mejor, tal vez la gente comience a usar su horquilla o incluso mejor, los chicos detrás del manillar fusionarán su horquilla con el origen / maestro: bailarín:

que tengas una buena; D

Si me concediera el tiempo, ¡seguro!

Estoy absolutamente de acuerdo con @constantology. Es una locura tener plantilla sin lógica. Y si querías tener una plantilla sin lógica, por qué pusiste ahí la declaración: "si" que representa la lógica como peligro de color rojo ... No tiene sentido. Creo que la lógica de comparación básica es necesaria como sal en la sopa. @mikeobrien : "Una implementación a medias no debe justificarse con un argumento de hombre de paja". : +1:

Hay algo que decir sobre las plantillas sin lógica. Sin embargo, creo que el problema es que todos aquí confunden la lógica de negocios con la lógica de vista. La lógica empresarial no tiene cabida en las plantillas. Período. Ver la lógica, sin embargo, es otro asunto completamente diferente. Creo que Handlebars se da cuenta de esto y es por eso que agregaron el if / else en primer lugar, simplemente se confundieron un poco en el camino.

Necesito saber si mi matriz de datos tiene un elemento o varios, y en base a eso quiero unirlos con comas o agregar un plural a una palabra. Con el bloque if actual, no puedo hacer esto.

Es por eso que hice esta solicitud de extracción: https://github.com/wycats/handlebars.js/pull/566 y jsfiddle adjunto: http://jsfiddle.net/YsteK/

Esta solicitud de extracción proporciona un nuevo ayudante: ifTest, que toma una expresión javascript que se evalúa como lo haría javascript dado el contexto. Disfrutar.

Honestamente, esta es una funcionalidad tan básica que me hace sentir que si desea mantener esta mentalidad de no tener lógica incorporada en el marco (¡lo cual me parece completamente ilógico!), Debe reconsiderar el uso de términos lógicos como "si". .

Me encuentro agregando esto a muchos de mis proyectos simplemente porque es muy útil al comparar cosas como "0" y "1" con otros valores booleanos:

Handlebars.registerHelper ('ifCond', function (v1, v2, options) {
si (v1 === v2) {
return options.fn (esto);
}
return options.inverse (esto);
});

Creo que es totalmente justo hacer que la funcionalidad "si" existente funcione como lo hace, pero hazle un favor al idioma inglés y elige otra palabra (o haz que haga lo que la gente espera). Se siente como una verdadera perversión del término "si" cuando simplemente no se comporta como una afirmación verdadera en ningún otro contexto.

Me gustaría agregar otro voto para eliminar if completo o permitir que if acepte algunos argumentos de comparación básicos, por ejemplo, eq , ne , gt , etc. Terminarías con {{#if arg1 eq arg2}} . Por supuesto, eliminar if completo tendría más sentido para su filosofía de "no hay lógica en las plantillas" (ahora es más como "no hay lógica en las plantillas, la mayoría de las veces, pero a veces está bien").

Sin un ayudante, termino haciendo cosas como esta todo el tiempo:

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

Lo que parece un poco tonto agregar todas esas propiedades adicionales a un objeto.

webgovernor - Mira esto: http://jsfiddle.net/YsteK/

Es un ayudante que habilita esta funcionalidad. Se necesita una expresión de javascript que se evalúe como lo haría javascript dado el contexto. Disfrutar.

Gracias tniswong, eso es muy similar a mi ayudante. Tengo el problema resuelto, solo quería resaltar la hipocresía del dogma "sin lógica" de Handlebars.

No hay problema. Estoy ahí contigo. Me encantan los manillares, pero es bastante inútil sin este ayudante.

Envié este ayudante como una solicitud de extracción, pero fue rechazado. Así que envié otra solicitud de extracción que eliminó el bloque if. También rechazado. /suspiro

Jajaja. Github necesita un botón de voto a favor.

¿Fue rechazado? -_-

La obstinación de la religión sin lógica de Handlebars es realmente alucinante.

566 y # 568

Mencionó que podría agregarlo al archivo README, pero no estoy conteniendo la respiración.

+1 a esto! ¡Argghhh!

FWIW, el repositorio Swag proporciona ayudantes que agregan comparación, clasificación y otras cosas ingeniosas. No construyo nada en Handlebars sin él.

Dicho esto, personalmente estoy de acuerdo con dejar que Handlebars permanezca lo menos lógico posible, ya que lo mantiene limpio, extensible y mantenible. Si quieres más, contribuye a un repositorio como _Swag_ para cosas fuera del alcance del proyecto. Si los mantenedores de este proyecto cambian de opinión, todo lo que se necesita es una solicitud de extracción: +1:

@aboutaaron Si vas a hacer una declaración como, "dejar que Handlebars permanezca lo menos lógico posible ya que lo mantiene limpio, extensible y mantenible", al menos deberías tener la decencia de:

1. proporcionan la prueba de que el manillar no tiene lógica. Si ha leído el hilo, verá que ya se ha demostrado que el manillar contiene una lógica incompleta en forma de una declaración if que solo verifica la "veracidad", si no ha leído el hilo, entonces le sugiero que lo haga.
2. proporcionar pruebas de que los manillares proporcionan una lógica incompleta en la forma de una declaración if que solo verifica la "veracidad", de alguna manera, "la mantiene limpia, extensible y mantenible".
   ¿No es esto una contradicción? Si el manillar es extensible, ¿no significa eso que sería trivial proporcionar una implementación completa de declaraciones condicionales?
   ¿Cómo, por ejemplo, los manillares que proporcionan una declaración if completa lo harían menos limpio, extensible y fácil de mantener que un desarrollador que usa manillares Y swag ?
   Se podría argumentar que el uso de los ayudantes de botín hará que una base de código sea menos limpia, extensible y fácil de mantener, ya que necesita usar un ayudante diferente para cada operador de comparación, es decir, gt , gte , is , isnt , lt , lte así como para cada operador lógico, es decir, and , or .
   ¿Cómo hace esto que el código sea más legible que hacer todo esto de la misma manera que lo haría, dentro de una declaración if , en cualquier otro idioma? Si este fuera el caso, entonces asumiría que los lenguajes de programación mismos eliminarían las declaraciones condicionales que verifican cualquier otra cosa que no sea la "veracidad". No veo que esto suceda.

Si por casualidad va a utilizar el argumento cansado y refutado de "poner la lógica empresarial en la plantilla", no lo haga. esto ya ha sido abordado - varias veces, por varias personas - en este hilo. Al mismo tiempo, si eso es algo que considera un argumento válido, entonces eliminaría la necesidad de usar la biblioteca de botines , lo que contradice su declaración anterior.

En conclusión, el hecho de que existan varias bibliotecas que buscan completar la implementación incompleta de if en manillares, de una forma u otra, muestra que existe la necesidad de este tipo de funcionalidad en su centro. Mire el lenguaje JavaScript en sí, Harmony está introduciendo muchas características que han sido proporcionadas por bibliotecas, iteradores, módulos, generadores, clases, proxies, etc. de terceros; y la API de DOM también ha implementado características que fueron proporcionadas por bibliotecas de terceros, querySelector [All], CORS e incluso hay una implementación de DOM Promises en Chrome canary.

No hay pruebas de que "dejar que Handlebars permanezca lo menos lógico posible, ya que lo mantiene limpio, extensible y fácil de mantener". Al mismo tiempo, otros y yo hemos demostrado, en comentarios anteriores de este hilo, que un poco puede ser muy útil, si los manillares proporcionaran una implementación if , les daría a los desarrolladores una API unificada para hacer sus plantillas son más fáciles de leer y mantener.

@constantology +1 Amén.

Acabo de llegar aquí después de probar {{#if something> something_else}} y darme cuenta de la verdad de esta situación. Sin embargo, estoy tentado a estar de acuerdo con la gente del manillar en este caso. Usé líquido durante mucho tiempo, y los hilos de comentarios como este conducen inevitablemente a la adición de características a medias como las matemáticas y la concatenación de cadenas que realmente pertenecían al back-end.

El objetivo con la declaración if "sin lógica" parece ser: hacer la parte lógica en la parte trasera y presentar los manubrios con la "respuesta" como una sola variable. Si la respuesta es "sí", haga esto; de lo contrario, haga lo contrario. No veo ningún problema con eso (habiendo leído los comentarios anteriores), y voy a arreglar mi código ahora.

Trabajando en algunas aplicaciones de Ember y quería dar mi opinión. Siento que la declaración #if sería mejor si _ (opcionalmente) _ aceptara un argumento. Entiendo totalmente el deseo de dejar las cosas logic-less , pero a veces puede ser bastante frustrante trabajar con ellas.

Imagine una lista simple de preguntas que se pueden seleccionar o deseleccionar. Realmente, ¿cuál es la diferencia entre estos dos bloques 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}}

Hay diferencias bastante grandes en cómo necesito escribir el código que respalda estos dos ejemplos. Sería realmente bueno tener la flexibilidad para elegir. Tampoco veo realmente cómo el primero contiene más lógica que el segundo.

Sentí exactamente lo mismo que dice este hilo. Entonces, encontré este hilo.
Por tanto, supongo que acabo de entender la filosofía de Handlebars.
Luego, descubrí que lo que necesitaba es una colección de ayuda como Swag.

Ahora no tengo ningún problema porque Swag me ayudará.
Sin embargo, me confundí porque el if helper predeterminado era demasiado simple.
Si dices que Hanlebars no tiene lógica, dudo que Handlebars necesite ayudantes integrados.
Si no tuviera ayudantes integrados, creo que podría entender la filosofía de Handlebars más fácilmente.

Puede que no entienda bien logic-less y business logic , quiero decirles lo que pensé.

Creo que simplemente no se puede considerar un solo si / a menos que (sin condicionales) como lógica, ya que es solo, en el contexto sin lógica, un medio para representar un dato booleano, como el "{{foo}}" la sintaxis es un medio para representar una cadena de datos.

Así que creo que debería detenerse el siguiente comportamiento: "Si no tiene lógica, ¿por qué hay una declaración if? ¡¡¡JA-JA, jaque mate !!!"

Luego cámbielo a "{{#exists}}" en lugar de "{{#if}}" porque tiene más sentido.

El 5 de octubre de 2013, a las 10:52 a.m., cal127 [email protected] escribió:

Creo que simplemente no se puede considerar un solo si / a menos que (sin condicionales) como lógica, ya que es solo, en el contexto sin lógica, un medio para representar un dato booleano, como el "{{foo}}" la sintaxis es un medio para representar una cadena de datos.

Así que creo que debería detenerse el siguiente comportamiento: "Si no tiene lógica, ¿por qué hay una declaración if? ¡¡¡JA-JA, jaque mate !!!"

-
Responda a este correo electrónico directamente o véalo en GitHub.

: thumbsup: para cambiar {{#if}} a {{#exists}} o {{#isTrue}}

Estoy de acuerdo en que podemos encontrar un nombre más sensato. 'existe' lo haría, y mis sugerencias serían 'verdaderas' o 'en'.

Pero no obstante, el nombre "si" sería aún más apropiado debido a razones históricas. Handlebars 'if implementación no es sintácticamente diferente a cualquier otra implementación if, cumple con la antigua sintaxis "if ([predicate]) [do sth]".

Lo que es diferente es que el [predicado] debe ser una variable bool simple, no puede ser una expresión. Pero esta no es la limitación de 'si'. Esta es una limitación más genérica causada por la falta de soporte para las expresiones del intérprete de Handlebars. (Que es exactamente lo que hace que Handlebars sea menos lógico por cierto, creo)

Lo que significa que este 'si' no es diferente de cualquier otro 'si'.

Y tratar de cambiar el nombre de 'si' puede ser considerado una herejía por algunos, no digas que no te lo advertí.

Llámalo {{#truthy}} y {{#falsey}} porque eso es todo lo que hacen {{#if}} y {{#unless}} .

A los desarrolladores: saquen la cabeza de la arena. Seriamente. Puede ver que hay demanda de una declaración if adecuada (y tengo la intención de usar la palabra 'demanda' de manera bastante literal), así que vaya e impleméntela, en lugar de quejarse de la falta de lógica. Si desea que sus plantillas no tengan lógica, elimine TODA la lógica, incluidos {{#if}} y {{#each}} .

SÓLO implemente una declaración if adecuada.
Las personas que creen firmemente en su falta de lógica, optarán por no usarlo. Sencillo. Como. Ese.

Incluso ya hice el trabajo por ti.

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

El 5 de octubre de 2013, a las 3:20 p.m., gracias a las [email protected] escribió:

Llámalo {{#truthy}} y {{#falsey}} porque eso es todo lo que {{#if}} y {{#unless}} hacen.

A los desarrolladores: saquen la cabeza de la arena. Seriamente. Puede ver que hay demanda de una declaración if adecuada (y tengo la intención de usar la palabra 'demanda' de manera bastante literal), así que vaya e impleméntela, en lugar de quejarse de la falta de lógica. Si desea que sus plantillas no tengan lógica, elimine TODA la lógica, incluidos {{#if}} y {{#each}}.

SÓLO implemente una declaración if adecuada. Las personas que creen firmemente en su falta de lógica, optarán por no usarlo. Sencillo. Como. Ese.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Gracias por eso, pero la solución debería estar en el paquete principal. El término "ifTest" es presumiblemente solo porque Handlebars secuestra el término "si" antes de que pueda usarlo.

Otra cosa es que su ifTest toma una cadena y realiza la evaluación de esa cadena en tiempo de ejecución, mientras que si un if-block adecuado estaría en el paquete principal, podría estar en la plantilla compilada (que es exactamente una de las más fuertes de Handlebars puntos: uno que no me gusta tirar por la borda usando eval() para ifs y elses)

Estás 100% correcto. Solo usando las herramientas disponibles para mí en ese momento.

Independientemente, funciona.

El 5 de octubre de 2013, a las 3:41 p.m., gracias a las [email protected] escribió:

Gracias por eso, pero la solución debería estar en el paquete principal. Además, el término "ifTest" es presumiblemente solo porque Handlebars secuestra el término "si" antes de que pueda usarlo. Otra cosa es que su ifTest toma una cadena y realiza la evaluación de esa cadena en tiempo de ejecución, mientras que si un if-block adecuado estaría en el paquete principal, podría estar en la plantilla compilada (que es exactamente una de las más fuertes de Handlebars puntos: uno que no me gusta tirar por la borda usando eval () para ifs y elses)

-
Responda a este correo electrónico directamente o véalo en GitHub.

Me encontré con este hilo mientras buscaba una comparación en Handlebars. Creo que debería eliminar / cambiar el nombre de los bloques {{#if}} y {{#each}} , o implementar una declaración if adecuada. Es una característica básica para todos los idiomas. Período. Si realmente quieres plantillas sin lógica, ¿por qué no usas Moustache en su lugar?

Entiendo que existe una opinión entre los desarrolladores de que las plantillas deben ser legibles por personas que no sean desarrolladores (es decir, diseñadores). Pero A) Nunca he trabajado con un diseñador donde esto fue un problema, y ​​B) Creo que el enfoque debería ser que una solución genérica esté disponible incorporada, y como extensión, puede usar la verificación solo booleana, por lo que tiene una elección. Además, agregar ayudantes como {{#ifValueEqualsA}} y {{#ifValueEqualsB}} lo obligará a crear una gran cantidad de código repetitivo que simplemente no es necesario. Trabajo en un proyecto móvil no tan grande y ya tengo 200 líneas de código que solo agregan comparaciones para necesidades específicas. Eso va en contra (con suerte) de la mentalidad de todos los desarrolladores de que las cosas deberían ser lo más genéricas posible.

@ cal127 "Creo que simplemente no se puede considerar un solo si / a menos que (sin condicionales) como lógica". Entonces, ¿cuál es el problema? ¿Por qué es más lógico verificar una expresión que verificar un valor booleano? Es un cheque. Período. Esa es la lógica que se hace aquí, no la expresión (ya que un valor booleano es, adivinen qué, una expresión). Por supuesto, asumiendo que la expresión no representa lógica empresarial, sino lógica de interfaz de usuario.

Lamento que la idea de motores de plantilla sin lógica parezca ya moribunda ... No veo que esto siga funcionando en el futuro. Los desarrolladores necesitan herramientas que hagan las cosas más fáciles y rápidas, no más complicadas.

@thany rocas. Me encontré con bigote (otro lenguaje de plantilla sin lógica) ayer y esta fue exactamente la pregunta que apareció en mi cabeza unos momentos después. ¿Cómo pudieron los programadores pensar que esto es genial? Esto solo empeora las cosas. El paradigma de programación que conozco es la "separación de la lógica empresarial de la lógica de la PRESENTACIÓN". Eso significa que hay lógica en la presentación (vistas que contienen / incluyen plantillas en un patrón como mvc, por ejemplo). ¿Cómo es que están tratando de negar eso y quitando la lógica de la presentación?

Escenario: estoy ejecutando un bucle en una vista y quiero realizar una acción después de x iteraciones. Con los manillares, ahora tengo que crear un ayudante y luego usarlo en el bucle, ¿verdad? ¿Cómo hace esto mi vida más fácil? ¿Qué pasó con si cuenta == x ????? ¿Cómo es eso mejor que usar un lenguaje como el propio php para sus plantillas? ¿Cómo ayuda a diseñar sobre motores de plantillas lógicas?

¿Me? Nada sin lógica para un trabajo orientado a la lógica. ¡Perdón!

No puedo creer lo ignorantes que pueden ser, queridos creyentes en la falta de lógica. Simplemente no es una realidad, es un mito completo, una falacia, una religión falsa. Ninguna plantilla de más de unas pocas líneas será completamente sin lógica. Simplemente no es práctico.

Ahora, hacer cumplir esa creencia en sus usuarios es totalmente su decisión. Pero seguir ignorando cualquier exigencia de lógica es una prueba de estupidez e ignorancia. Especialmente en este caso particular, dado que ya existe una cantidad de lógica posible, aunque minúscula.

Una vez más, le insto encarecidamente a que lo reconsidere. No, espera, no lo reconsideres. Solo escucha y haz lo correcto. Las personas que no quieren nada de esa lógica tonta en sus plantillas, pueden seguir adelante y continuar con sus caminos perversos y saltar a través de todo tipo de obstáculos para no usar la lógica.

Extender el bloque if para hacer comparaciones adecuadas no elimina su uso actual. No causará problemas a aquellos que aún no han visto la luz lógica, esas personas pueden continuar codificando como antes.

No se trata de ser genial; usted mismo usa la separación entre la lógica y la presentación como argumento y luego ignórala para pedir que se simplifique su vida. Podrías haber agregado cualquiera de las bibliotecas de plantillas de manubrios estándar a tu proyecto o escrito el tuyo propio.

Usted o nadie más ha abordado ninguno de los numerosos argumentos en contra de esto en cualquiera de los numerosos hilos. Solo para que esos argumentos sean claros en este hilo:
1) Estarás alterando un ecosistema existente; lo que provocará conflictos y reelaboraciones para los equipos que quieran actualizar pero que hayan tenido su propio IF durante ~ 2 años.
2) Existen bibliotecas de ayuda que agregarán si lo necesita, junto con todos los demás ayudantes que solicitará a continuación.
3) Tan pronto como se acuerde agregar este 'si', el nuevo argumento será la implementación del mismo. Nombre. Sintaxis. Argumentos. Puede prometer que estará contento con el si eso aparece, pero otros no lo harán. Inmediatamente habrá un nuevo hilo (s) aquí argumentando que debería funcionar de otra manera.
4) El 'si' existente es exactamente lo que debería estar ahí para -rendir-. "Mostrar X si Y está presente". No se trata de lógica empresarial; lo que debería suceder en su modelo (sugiero Backbone, entonces puede tener lo que quiera que sea, para ser solo un método isXXX () en su modelo).

Ya que nos estamos pidiendo cosas, no continúes con esto si no tienes un buen argumento técnico para hacer un cambio importante. Estar frustrado es una tontería: agregue el 'SI' que desea y listo.

1) No, no lo harás. Si no hace nada, las plantillas deberían seguir funcionando. Por supuesto, todo debería ser compatible con versiones anteriores. E incluso si no lo es, simplemente no actualice.
2) Una declaración if es elemental. Lo que está diciendo es que las ruedas de un automóvil ahora son opcionales.
3) La sintaxis de una instrucción if tiene muy poca importancia. Cada lenguaje de programación tiene uno y cada uno de ellos hace exactamente lo mismo. Así que elige uno y estará bien. Más importante aún, tener CUALQUIER declaración if adecuada es mejor que lo que tenemos ahora.
4) Incorrecto, busque "lógica de plantilla" hacia arriba.

En cuanto a su última postura, el argumento se ha hecho y es sólido. Se ha discutido una y otra vez, pero realmente parece una religión. Irrompible y, sin embargo, tan frágil.

George Frick -

1) ¿En qué se diferencia esto de actualizar CUALQUIER otro marco o biblioteca que haya existido alguna vez?
2) Tienes razón. Sin embargo, agregar manualmente estas características básicas no debería ser necesario para algo tan fundamental y necesario.
3) Para eso están las solicitudes de extracción.
4) Te perdiste por completo el punto. Nadie en este hilo defiende la lógica empresarial en la capa de visualización. Estamos abogando por una lógica de visualización ÚTIL en la capa de vista. El "si" dado no es un verdadero si, lo que lo hace confuso para cualquiera que alguna vez haya usado un lenguaje de programación. Es más un "existe".

Si cree que agregar esto haría que las personas usen la lógica empresarial en las plantillas, probablemente tenga razón porque no puede arreglar lo estúpido. El hecho de que alguien PUEDA hacer algo malo no significa que debas evitar que otras personas hagan algo bueno (y necesario) en el proceso.

El 22 de noviembre de 2013, a las 3:55 p.m., George Frick [email protected] escribió:

No se trata de ser genial; usted mismo usa la separación entre la lógica y la presentación como argumento y luego ignórala para pedir que se simplifique su vida. Podrías haber agregado cualquiera de las bibliotecas de plantillas de manubrios estándar a tu proyecto o escrito el tuyo propio.

Usted o nadie más ha abordado ninguno de los numerosos argumentos en contra de esto en cualquiera de los numerosos hilos. Solo eso para que los argumentos sean claros en este hilo:
1) Estarás alterando un ecosistema existente; lo que provocará conflictos y reelaboraciones para los equipos que quieran actualizar pero que hayan tenido su propio IF durante ~ 2 años.
2) Existen bibliotecas de ayuda que agregarán si lo necesita, junto con todos los demás ayudantes que solicitará a continuación.
3) Tan pronto como se acuerde agregar este 'si', el nuevo argumento será la implementación del mismo. Nombre. Sintaxis. Argumentos. Puede prometer que estará contento con el si eso aparece, pero otros no lo harán. Inmediatamente habrá un nuevo hilo (s) aquí argumentando que debería funcionar de otra manera.
4) El 'si' existente es exactamente lo que debería estar ahí para -rendir-. "Mostrar X si Y está presente". No se trata de lógica empresarial; lo que debería suceder en su modelo (sugiero Backbone, entonces puede tener lo que quiera que sea, para ser solo un método isXXX () en su modelo).

Ya que nos estamos pidiendo cosas, no continúes con esto si no tienes un buen argumento técnico para hacer un cambio importante. Estar frustrado es una tontería: agregue el 'SI' que desea y listo.

-
Responda a este correo electrónico directamente o véalo en GitHub.

@gracias
Existe una diferencia entre refutar un argumento y descartarlo. "INCORRECTO" equivale a "¡NUH UH!".
Trate de no ser tan personal al respecto tampoco.

@tniswong
1) No lo es, lo mismo es válido en cualquier marco.
2) Si aplica esto en un sentido general, Node debe incluir todos sus componentes. Se puede argumentar que son fundamentales o necesarios, pero llevaría a la idea de que agruparlos todos juntos fuera del marco estándar es una buena abstracción y separación. Muchos proyectos simplemente no necesitan ninguno de ellos y otros necesitan versiones especiales. Por lo tanto, puede agregar un conjunto estándar, escribir el suyo propio o no usar ninguno. No hay (nuevamente) ninguna razón técnicamente sólida para que todos estos ayudantes se incorporen de forma predeterminada.
3) Su declaración no niega de ninguna manera el punto original, de hecho, lo ayuda. 20 solicitudes de extracción para corregir errores de If. Apuesto a que al equipo de desarrollo le encantará revisarlos.
4) Exactamente, es un 'existe'. Renderice esto si existe.
Cuando no se puede escribir sobre "nadie jamás", se necesita un solo contraejemplo. _levanta la mano_.

De las notas anteriores me parece que uno de los siguientes es necesario:

1. Cambie el nombre de if a exists y deje de llamar a los manillares "sin lógica" (porque no lo es)
2. Agregue soporte para que if comporte como una declaración if .
3. Elimina if completo.

Estaría feliz con cualquiera de esas opciones.

No olvides {{#unless}}

El 22 de noviembre de 2013, a las 4:40 p.m., Aaron M [email protected] escribió:

De las notas anteriores me parece que uno de los siguientes es necesario:

Cambie el nombre si existe y deje de llamar a los manillares "sin lógica" (porque no lo es)
Agregue soporte para que if se comporte como una declaración if.
Retirar si es por completo.
Estaría feliz con cualquiera de esas opciones.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Creo que Aaron lo resume muy bien.

1. Hay una hipocresía que debe abordarse afirmando que no tiene lógica Y proporcionando un si / a menos.
2. El "si" dado es un nombre inapropiado.

Arregle ambos, y este argumento desaparecerá.

El 22 de noviembre de 2013, a las 4:43 p.m., Todd Niswonger [email protected] escribió:

No olvides {{#unless}}

El 22 de noviembre de 2013, a las 4:40 p.m., Aaron M [email protected] escribió:

De las notas anteriores me parece que uno de los siguientes es necesario:

Cambie el nombre si existe y deje de llamar a los manillares "sin lógica" (porque no lo es)
Agregue soporte para que if se comporte como una declaración if.
Retirar si es por completo.
Estaría feliz con cualquiera de esas opciones.

-
Responda a este correo electrónico directamente o véalo en GitHub.

@georgefrick
Descartaba su argumento simplemente porque ha sido refutado un millón de veces antes. Hemos hablado de esto durante demasiado tiempo y debe terminar. Se debe agregar la declaración if, nadie estará en desventaja y todos estarán felices. No quererlo es lo mismo que no querer aire acondicionado en TODAS las casas. Seré el juez de lo que quiero en mi casa. Si está en el tuyo y no lo quieres, déjalo así. Simple como eso.

@webgovernor
No es necesario cambiar el nombre. Una sentencia if adecuada puede hacerse totalmente compatible con la actual. Actualmente es solo "if boolean then ...", y cualquier instrucción if con todas las funciones hará exactamente eso, solo esa cosa booleana ahora puede ser cualquier expresión en lugar de solo una variable.

@tniswong
Qué amables de ellos, ¿verdad? Para agregar una etiqueta extra asquerosa porque el bloque if, tal como lo implementaron, está tan simplificado que ni siquiera puede negar una expresión. Pero en un futuro Handlebars, la etiqueta a menos que simplemente se convierta en un alias de "si no". Un poco como do.. while versus while..do en programación, donde los dos existen principalmente por legibilidad y no _realmente_ por ninguna razón técnica.

Yo también deseo comparaciones básicas en Handlebars. Entiendo la filosofía sin lógica. También creo que el soporte de comparación básico sería más intuitivo y permitiría a los usuarios trabajar de manera más eficiente. Si los usuarios en masa están moviendo la lógica de comparación básica a un ayudante, esta filosofía no les está haciendo un favor o disuadiendo un comportamiento subóptimo percibido, solo está creando más trabajo.

@jeremiahlee No estoy seguro de si estás de acuerdo o en desacuerdo conmigo allí, puedo leer tu comentario de cualquier manera :)

De cualquier manera, he trabajado con Handlebars en el pasado y les he pedido que implementen un if-block adecuado. Esto resultó en una avalancha de comentarios sobre una falsa filosofía de que la lógica debería permanecer en el modelo. Ningún desarrollador de Handlebars deseaba pensar ni un milímetro fuera de su propio mundo diminuto (hay una palabra grosera para eso, pero la omitiré). Solo mira este hilo como prueba.

Esto me obligó a escribir un ayudante llamado "cuándo" que hace comparaciones. Todavía no hay una construcción adecuada de if-block, pero lo suficientemente cerca para mí en ese momento. Sin embargo, creó mucho trabajo innecesario para mí.

@thany : Estoy de acuerdo en que Handlebars debe tener una comparación básica de dos valores incorporada. Las plantillas sin lógica tampoco deben ser sin empatía.

También votaré por @thany y los otros argumentos. Las declaraciones if else son demasiado básicas.
Las clases condicionales y las cajas select con option s preseleccionados deberían ser factibles con el paquete predeterminado de manillares.

Con los ayudantes anidados, esto ya no es un problema, p. Ej.

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

buen ejemplo @mmun : +1:

Un poco extraño, y no veo ningún combinador booleano ... Pero sobre todo, no cambia el punto de vista general de los mantenedores de este proyecto, que parece ser un irrompible "¡¡NO LÓGICA !! 11 !! 1! 1 "tipo de vista.