shareVkPostWithUpload: Ввести переиспользуемость полученного в ходе выполнения функции токена

[dewolixgit]

Проблема: если не передать в shareVkPostWithUpload токен или он окажется протухшим, то токен, полученный при обращении к методу photos.getWallUploadServer (через функцию callVkApi), окажется неиспользуемым следующим за ним методом photos.saveWallPhoto (тоже через функцию callVkApi).

Пример сценария с передачей в качестве токена протухшего токена, находящегося в window.access_token (значение по умолчанию):

1. Вызов callVkApi (photos.getWallUploadServer) приводит к тому, что протухший токен обнаруживается и происходит обновление токена в window.access_token. Это ок.
2. Выполнение доходит до следующего callVkApi (photos.saveWallPhoto). Здесь функция по-прежнему принимает accessToken, переданный в аргументах. А на момент начала выполнения accessToken был равен протухшему токену. Таковым он и сохраняется, потому что токен — строка. Именно такой токен попадает в callVkApi, который, к тому же, специально не обновляет токен и в итоге возвращает ошибку от ВК.

Пример сценария с передачей в качестве токена пустой строки.

1. Передаём в shareVkPostWithUpload специально пустую строку. callVkApi (photos.getWallUploadServer) внутри себя видит, что токена нет и вызывает getVkAccessToken, который, в свою очередь, записывает новый токен в window.access_token.
2. Затем выполнение доходит до следующего callVkApi (photos.saveWallPhoto). Функция внутри себя видит, что переданный accessToken пустой, поэтому снова вызывает getVkAccessToken, хотя можно бы было использовать только что полученный ранее токен.

Решение побыстрее полагается на сайдэффект с записью в window токена. Можно в отдельную переменную в начале выполнения функции сохранить window.token. Когда дойдём до второго callVkApi (photos.saveWallPhoto), проверим:

• Если window.token на момент начала выполнения функции отличается от текущего window.token, значит в процессе выполнения первого callVkApi (photos.getWallUploadServer) был получен новый токен и нужно использовать его
• Если window.token на момент начала выполнения функции не отличается от текущего window.token, значит в процессе выполнения первого callVkApi (photos.getWallUploadServer) сработал либо установленный по умолчанию токен из аргумента accessToken (он же и есть window.token на момент начала выполнения функции), либо сработал просто переданный непустой токен в этом же аргументе accessToken, а это значит, что и во втором callVkApi можно использовать accessToken
  Хотя дополнительно указываю на то, что решение жёстко завязывается на особенность работы callVkApi и getVkAccessToken, связанную с перезаписью токена в window.token, что, наверное, в целом затрудняет осознание происходящего