Практика денормализации в реактивном применении

Question

Я создаю реактивное приложение с Meteor (с MongoDB в качестве бэкэнда).

Я изначально создал коллекцию и денормализаторы с нереактивной информацией, например ::

class DocCollection extends Mongo.Collection {
  insert(doc, callback) {
    const docId = super.insert(doc, callback);
    doc = docMongo.findOne(docId);  // for illustration, A
    console.log(doc);
    return docId;
  }
}

docMongo = new DocCollection();

Теперь я хотел бы заключить его в MongoObservable, что облегчит прослушивание изменений в коллекции:

export const Doc = new MongoObservable.Collection(docMongo);

Затем я определю метод:

Meteor.methods({
  add_me() {
    Doc.insert(myDoc);
  }
});

в server/main.js и вызывать его в конструкторе app.component.ts:

@Component(...)
export class AppComponent {

  constructor() {
    Meteor.call('add_me');
  }
}

Я получаю undefined, напечатанный на консоли (если я не сплю немного раньше findOne), поэтому я предполагаю, что когда я был в поисках do c после вставки в мой Mongo.Collection документ еще не был готов к поиску.

1. Почему это происходит, даже если я переписал нереактивный класс и только потом обернул его в MongoObservable?
2. Как я обычно делаю денормализацию с помощью реактивного сбора? Должен ли я передавать наблюдаемые моим денормализаторам и создавать там новые, или можно потом красиво обернуть нереактивный код (как я пытался и потерпел неудачу выше)? Обратите внимание, что я не хочу напрямую передавать doc внутрь, так как в более сложном сценарии ios это вызовет другие вставки / обновления в другом месте, которые я также хотел бы ждать.
3. Как люди как правило, тестировать эти вещи? Если я запускаю тест, приведенный выше код может быть успешным локально, так как время вставки БД невелико, но не удается, если задержка выше.