Расовые условия с использованием Office.js в Excel

Question

Расовые условия с использованием Office.js в Excel

1

Я встречаю какое-то состояние гонки в следующем коде, где я пытаюсь написать ответ HTTP-запроса на активную ячейку. Я прочитал некоторые возможные решения для ошибок "InvalidObjectPath" из Office.js (я использую ScriptLab специально), но я не думаю, что я пытаюсь использовать что-либо в нескольких контекстах.

Текущее поведение работает иногда, но в других случаях ничего не будет записано в ячейку.

var counter = 0;
$("#run").click(run);
async function run() {
    try {

        await Excel.run(async (ctx) => {
            var user; 
            const sUrl = "https://jsonplaceholder.typicode.com/users/1";
            var client = new HttpClient();
            var range = ctx.workbook.getSelectedRange(); 
            counter++;
            client.get(sUrl, function (response) {
                var obj = JSON.parse(response);
                user = obj.username;
                range.values = [[user + counter]];
                ctx.sync();
            });
            await ctx.sync();
        });
    }
    catch (error) {
        OfficeHelpers.UI.notify(error);
        OfficeHelpers.Utilities.log(error);
    }
}

var HttpClient = function() {
    this.get = function(aUrl, aCallback) {
        var anHttpRequest = new XMLHttpRequest();
        anHttpRequest.onreadystatechange = function() { 
            if (anHttpRequest.readyState == 4 && anHttpRequest.status == 200)
                aCallback(anHttpRequest.responseText);
        }
        anHttpRequest.open( "GET", aUrl, true );            
        anHttpRequest.send(null);
    }
}

James Spotanski 14 июнь 2017, в 03:43

Источник

Теги:

javascript

async-await

office-js

1 ответ

Ещё вопросы

Michael Zlatkovsky - Microsoft · Accepted Answer · 2017-06-14T03-14-00.000Z

Проблема в том, что вы не ожидаете завершения client.get. Это означает, что [некоторое время], Excel.run завершит и "собирает мусор" (ish) некоторые из объектов (range) до выполнения обратного вызова внутри client.get.

Вы можете решить проблему несколькими способами:

Excel.run вызов веб-службы перед выполнением Excel.run. В вашем примере здесь (что может быть нереалистичным для многих других сценариев, но оно здесь), вы фактически не полагаетесь ни на что из документа, прежде чем выполнять свой веб-вызов. В этом случае вам вообще не нужно находиться внутри Excel.run, вы можете иметь Excel.run, Excel.run частью обратного вызова в вызове веб-службы.
Оберните свой веб-сервисный вызов в Promise, чтобы его можно было ждать. Что-то вроде этого: var HttpClient = function() { this.get = function(aUrl) { return new Promise(function (resolve, reject) { var anHttpRequest = new XMLHttpRequest(); anHttpRequest.onreadystatechange = function() { if (anHttpRequest.readyState == 4 && anHttpRequest.status == 200) { resolve(anHttpRequest.responseText); } else { reject(anHttpRequest.statusText); } } anHttpRequest.open("GET", aUrl, true); anHttpRequest.send(null); }); } } var HttpClient = function() { this.get = function(aUrl) { return new Promise(function (resolve, reject) { var anHttpRequest = new XMLHttpRequest(); anHttpRequest.onreadystatechange = function() { if (anHttpRequest.readyState == 4 && anHttpRequest.status == 200) { resolve(anHttpRequest.responseText); } else { reject(anHttpRequest.statusText); } } anHttpRequest.open("GET", aUrl, true); anHttpRequest.send(null); }); } }

Я описываю оба подхода (и многое другое...) в книге, которую я писал о надстройках надстройки здания, используя Office.js: https://leanpub.com/buildingofficeaddins/. Я вставляю несколько скриншотов из некоторых соответствующих материалов.

Кстати, я должен сказать, что получение выбора является одним из нескольких случаев, когда вы не хотите задерживать sync, так как вы хотите захватить мимолетный выбор по времени, а не то, что станет выбором через X секунд, как только веб-вызов будет успешным. Таким образом, это один из немногих случаев, когда вам может понадобиться вставить дополнительный await context.sync() даже если вам это не требуется. Дополнительную информацию см. В разделе "5.8.2: Когда синхронизировать" в книге.

=====

Продвижение API:

=====

От приблизительно обещаний:

=====

В разделе сведений о реализации:

Не могли бы вы предоставить эти выдержки в виде цитируемого текста вместо картин, пожалуйста?
Вам не нужно (и не следует) использовать new Promise конструктор new Promise для «обещания» вызова jQuery ajax. Просто return Promise.resolve($.ajax(…)).then(…, …) - jQuery уже возвращает таблицу (вы могли бы даже await отложенную jQuery напрямую)
@ Bergi, скриншоты для меня самые простые, так как книга написана на диалекте Markdown ( Markua ), который используется LeanPub, но не всегда на 100% хорошо работает с GitHub.
@Bergi, для обещания вызова jQuery ajax: это правда, что jQuery возвращает обещание, хотя, к сожалению, это не полностью стандартное обещание (например, у него нет «.catch»). Так что я думаю, что все еще имеет смысл использовать стандартное обещание Promise для большей гибкости, особенно когда я хочу выполнить некоторую постобработку ответа сервера, как я делал выше. Однако в той же главе есть и другие примеры, такие как обещание функции setTimeout.
@ MichaelZlatkovsky-Microsoft Спасибо! В конечном итоге я захочу использовать значение из getActiveRange () для создания URL-адреса запроса, поэтому я буду отвечать за вызов веб-службы в Promis. Очень признателен!
@ MichaelZlatkovsky-Microsoft Да, упаковка это хорошая вещь, но вы должны вместо этого Promise.resolve вместо new Promise . Ваш фрагмент по существу использует Promise конструктора Promise - и в нем отсутствует обработка ошибок для кода внутри обратных вызовов done и fail .
@Bergi, возможно, я просто неправильно это понимаю - но даже в отправленной вами ссылке на конструктор антипаттерна я вижу такие вещи, как «Вы должны использовать отложенные объекты только тогда, когда вы конвертируете API в обещания и не можете делать это автоматически, или когда вы пишете функции агрегирования, которые проще выразить таким образом. " Из того, что я видел / читал об объекте jQuery Promise, поскольку он не является полностью стандартным Promise (т. .catch Не поддерживает .catch ), кажется .catch безопасным обращаться с ним, как будто это не обещающий API, и переносить это в конструкторе Promise. Рад узнать больше, если вы не согласны.
@ MichaelZlatkovsky-Microsoft Не нужно поддерживать catch. Ему даже не нужно показывать then который возвращает новое обещание. Он должен быть доступен только тогда и вызывать соответствующий обратный вызов, и вы можете передать его в Promise.resolve(…) чтобы получить полностью стандартное обещание. И даже если вы хотите обернуть его в конструкторе обещаний, вы должны обернуть его напрямую ( new Promise((res, rej) => $.ajax(…).then(res, rej)) или ….done(res).fail(rej) ), вместо того, чтобы делать кучу вещей в тех нестандартных небезопасных done и fail обратных вызовах.