1. Об apply.. хорошо написано тут https://ru.bem.info/forum/issues/174/
2. В твоем случае – тебе нужно положить пачку оберток внутрь блока и в этом случае менять контекст и вызывать applyCtx не нужно , обычно эта конструкция нужна когда тебе нужно сам блок обернуть во что, в неких враппер например или в другой блок и вызвать applyCtx по моде def()

Например:

block('box')(
    def()(function() {
        return applyCtx({
            block: 'container',
            content: {
                block: this.block,
                content: this.ctx.content
            }
        });
    })
);

Получим html:

<div class="container">
    <div class="box">box content</div>
</div>

В твоей задаче достаточно будет написать return куска bemjson, который будет контентом блока box:

block('box')(
    content()(function() {
        return {
            elem: 'left-top',
            content: {
                elem: 'right-top',
                content: {
                    elem: 'right-bottom',
                    content: {
                        elem: 'left-bottom',
                        content: applyNext()
                    }
                }
            }
        };
    })
);

@tavriaforever от applyCtx я, в первую очередь, ожидал, что стили вложенных блоков подключатся автоматически.

Если переписывать контент куском bemjson, приходится создавать файл box.deps.js:

({
    shouldDeps: [
        { elem: 'left-top' },
        { elem: 'right-top' },
        { elem: 'right-bottom' },
        { elem: 'left-bottom' }
    ]
})

Не хотелось бы писать зависимости для каждого враппера.

Нет смысла такие стили раскидывать по папкам. Пишите их в рамках стилей 'box'

Согласен с @Guria Но на будущее - твою запись депсов можно сократить до

({
    shouldDeps: { elems: ['left-top', 'right-top', 'right-bottom', 'left-bottom']
})

@Guria @sipayRT а если примиксован другой блок со своими технологиями к одному из вложенных элементов?

block('box')(
    content()(function() {
        return {
            elem: 'left-top',
            mix: { block: 'box2' },
            content: applyNext()
        };
    })
);

@raulleo зависимости нужно писать в любом случае — доставать зависимости из bemhtml программы это не тривиальная задача, т.к. может быть написано var res = {}; if(...) res.elem = myVar; и т.п. (см. также https://github.com/bem/bem-forum-content-ru/issues/298#issuecomment-83813859)

@veged А давайте писать зависимости как в Ангуляре? Ну, всмысле не прямо так, а по такой же идее. Вначале css-файла делать @import нужных. В начале js-файлов уже всё написано, там же модульная система. И для bemhtml что-нибудь подобное ввести. Потом сборщик всё это считывает и собирает так же как сейчас.

@varya таким образом, кажется, можно выразить только mustDeps из текущего формата описания зависимостей. Как быть с depsByTech и shouldDeps?

@varya кстати, @import в css файле и блок в зависимостях - это разные вещи. @import вставляет столько раз, сколько его напишешь, а блок в сборку попадет только один раз.

mustDeps и shouldDeps различать тем, в начале файла написана зависимость или в конце. Ну для depsByTech так и быть можно как сейчас сделать. Главное что если в файле писать для простых случаев, то похоже на другие системы и сразу ниже порог вхождения.

@varya Я, кстати, слышал про технологию для enb, которая зависимости собирает по тому, что в js-файлах указано, но сейчас ее найти не могу.

@apsavin https://github.com/enb-make/enb-modules/blob/master/techs/deps-with-modules.js

@varya @apsavin Идея крутая, но это будет каша...

@import в css-файлах это и есть чесный depsByTech, но только для css технологии.

Это значит, что для построения CSS-файлов не обязательны DEPS-файлы, и может быть достаточно только кода. Чтобы построить шаблоны и прочее, по-прежнему смотрим в DEPS-файлы и не смотрим в CSS.

Но и совсем без обычных DEPS-ов не обойтись.

Пример:

Допустим, что нам нужна кнопка. в BEMJSON-файле она будет записана так:

{
    block: 'button',
    text: 'Buy!'
}

Из BEMJSON получаем декларацию:

[
    { block: 'button' }
]

Исходный код шаблонов:

button.bemhtml

block('button').content(function () {
    return {
        elem: 'text',
        content: this.ctx.text;
    };
});

Для шаблонов пишем зависимости:

button.deps.js

{
    shouldDeps: { elem: 'text' }
}

Дополняем декларацию зависимостями:

[
    { block: 'button' },
    { block: 'button' elem: 'text' }
]

Исходные файлы CSS-файлы:

button.css

.button {
    padding: 10px 15px;
    border: 1px solid #000;    
}

button__text.css

.button__text {
    color: #000;
}

По дополненной декларации, строим CSS-файл:

.button {
    padding: 10px 15px;
    border: 1px solid #000;    
}

.button__text {
    color: #000;
}

Если бы мы для шаблонов написали зависимости вида depsByTech

{
    tech: 'bemhtml',
    shouldDeps: { elem: 'text' }
}

То в результирующий CSS-файл, не попал бы код элемента button__text, и это было бы ошибкой. При этом button.css никак не зависит от button__text и использовать @import тут было бы не уместно.

@import больше подойдёт для случая с модификатором, например:

button_size_m.css

@import "button__text";

.button_size_m .button__text {
    font-size: 16px;
    line-height: 20px;
}

Т.е. я бы рассматривал @import как что-то дополняющее DEPS-файлы, но не заменяющее их.

@zxqfox почему будет каша?

@varya вариант с @import в конце файла, кажется, не очень очивидным. Тем более, это не чесный аналог shouldDeps: код из @import будет всегда снизу.

кстати, @import в css файле и блок в зависимостях - это разные вещи. @import вставляет столько раз, сколько его напишешь, а блок в сборку попадет только один раз.

@apsavin это же не мешает настроить сборщик таким образом, чтобы код вставлялся только один раз.

Как быть с depsByTech и shouldDeps?

@apsavin Если рассматривать @import как нечто дополняющее, то можно всегда считать, что это mustDeps а для остальных случаев есть DEPS-файлы.

@blond

Как быть с depsByTech и shouldDeps? @apsavin Если рассматривать @import как нечто дополняющее, то можно всегда считать, что это mustDeps а для остальных случаев есть DEPS-файлы.

Собственно, я вот к этому и писал:

Но и совсем без обычных DEPS-ов не обойтись.