Неудобная типизация функции vkApi #6
Labels
enhancement
New feature or request
Comments
Merged
n-merkulova
added a commit
that referenced
this issue
Jan 31, 2023
## v2.0.0 - [-] удалены утилиты, которые не несли смысловой нагрузки и являлись просто оберткой try catch над вызовом метода VK ([issue](#5)) - [*] изменен метод вызова VK API через bridge, в него добавлена проверка на ошибки токена и возможность ретрая в их случае - [*] изменен метод получения access token - [+] добавлен оптимальный метод получения access token с обращением к window - [+] добавлен метод для шеринга в пост с загрузкой картинки на сервер VK - [*] функция initializeApp теперь асинхронная (issue не было, но жалобы были) - [+] добавлена возможность получения access token с пустым scope ([issue](#7)) - [*] исправлены возвращаемые типы всех функций ([issue](#6)) - [*] общие минорные улучшения, небольшой рефактор - [+] сборка библиотеки на rollup, режим разработки, сборка модулей в двух форматах - cjs и es - [*] улучшены JSDoc - [*] хук useEventSubscribe передает полученный event в callback ([issue](#1))
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Сейчас функция возвращает тип
{ response: any } | {error: any }, из-за чего становится невозможным использовать ее следующим образом:const { response, error } = await vkApi(...);, происходит ошибка типизации.Предлагаю поменять возвращаемый тип на
{ response?: any; error?: any }, и было бы хорошо шаблонизировать функцию, чтобы можно было передавать в нее тип ожидаемого ответа и ошибкиThe text was updated successfully, but these errors were encountered: