../это возвращает объект представления внутри внутреннего цикла, когда родитель и дочерний элемент имеют одинаковое значение

Это было интригующее открытие, и мне очень хотелось найти причину такого, казалось бы, странного поведения. Я немного покопался в исходном коде Handlebars и обнаружил, что соответствующий код можно найти на строка 176 файла lib/handlebars/runtime.js .

{{#each this.list}}
    {{this}}
{{/each}}

соответствующий код из Handlebars источник следующий:

let currentDepths = depths;
if (depths && context != depths[0]) {
  currentDepths = [context].concat(depths);
}

depths — это внутренний стек объектов контекста, context — это объект, переданный в текущий исполняемый блок, а currentDepths — это стек контекста, доступный для исполняемого блока. Как видите, текущий context помещается в доступный стек только если context не приблизительно равно текущей вершине стека, depths[0].

Давайте применим эту логику к коду в вопросе.

Когда контекст внешнего блока #for равен 15, а контекст внутреннего блока #for равен 0:

• depths равно: [15, {ROOT_OBJECT}] (где {ROOT_OBJECT} означает объект, который был аргументом вызова метода шаблона.)
• Поскольку 0 != 15, currentDepths становится: [0, 15, {ROOT_OBJECT}].
• Во внутреннем блоке шаблона #for {{this}} соответствует 0, {{../this}} соответствует 15, а {{../../this}} соответствует {ROOT_OBJECT}.

Однако, когда внешний и внутренний #for блоки имеют контекстное значение 15, мы получаем следующее:

• depths is: [15, {ROOT_OBJECT}].
• Потому что 15 == 15, currentDepths = depths = [15, {ROOT_OBJECT}].
• Во внутреннем блоке #for шаблона {{this}} – это 15, _43  – {ROOT_OBJECT}, а {{../../this}} – undefined.

Вот почему кажется, что ваш {{../this}} пропускает уровень, когда внешний и внутренний блоки #for имеют одинаковое значение. Дело в том, что значение внутреннего #for не помещается в стек контекста!

Именно в этот момент мы должны спросить, почему Handlebars ведет себя таким образом, и определить, является ли это особенностью или ошибкой.

Так получилось, что этот код был добавлен намеренно для решения проблемы, которую пользователи опыт работы с рулем. Проблема может быть продемонстрирована на примере:

Предполагая объект контекста:

{
    config: {
        showName: true
    },
    name: 'John Doe'
}

Пользователи сочли следующий вариант использования нелогичным:

{{#with config}}
    {{#if showName}}
        {{../../name}}
    {{/if}}
{{/with}}

Конкретная проблема заключалась в необходимости двойного ../ для доступа к корневому объекту: {{../../name}}, а не {{../name}}. Пользователи считали, что, поскольку объект контекста в {{#if showName}} был объектом config, то при переходе на один уровень, ../, следует получить доступ к «родителю» config — корневому объекту. Причина, по которой потребовались два шага, заключалась в том, что Handlebars создавал объект стека контекста для каждого помощника блока. Это означает, что для доступа к корневому контексту требуется два шага; первый шаг получает контекст {{#with config}}, а второй шаг получает контекст корня.

Был сделан коммит, который предотвращает перемещение объекта контекста в доступный контекст стек, когда новый объект контекста приблизительно равен объекту наверху стека контекста. Ответственный код — это исходный код, который мы рассмотрели выше. Начиная с версии 4.0.0 Handlebars.js, наш пример конфигурации не удастся. Теперь требуется только один ../ шаг.

Возвращаясь к примеру кода в исходном вопросе, причина, по которой 15 из внешнего блока #for определяется как равная 15 во внутреннем блоке #for, связана с тем, как сравниваются числовые типы в JavaScript; два объекта типа Number равны, если каждый из них имеет одинаковое значение. Это отличается от типа Object, для которого два объекта равны, только если они ссылаются на один и тот же объект в памяти. Это означает, что если бы мы переписали исходный код примера, чтобы использовать типы Object вместо типов Number для контекстов, то мы бы никогда не встретились с оператором условного сравнения, и мы всегда имели бы ожидаемый стек контекста внутри наш внутренний блок #for.

Цикл for в нашем помощнике будет обновлен для передачи типа Object в качестве контекста создаваемого им фрейма:

for(var i = from; i <= to; i += incr) {
    accum += block.fn({ value: i });
}

И нашему шаблону теперь потребуется доступ к соответствующему свойству этого объекта:

{{log ../this.value}}
<span>{{../this.value}}:{{this.value}}</span><br>

С этими изменениями вы должны обнаружить, что ваш код работает так, как вы ожидали.

Несколько субъективно заявлять, является ли это ошибкой с Handlebars. Условие было добавлено намеренно, и результирующее поведение делает то, для чего оно было предназначено. Однако мне трудно представить случай, в котором такое поведение было бы ожидаемым или желательным, когда задействованные контексты являются примитивными, а не типами Object. Было бы разумно, если бы код Handlebars выполнял сравнение типов объектов только. Я думаю, что здесь есть законный повод открыть задачу.