Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Handle error and await for finished promises (#7)
* Use machine translation workflow when requested Add optional `isWorkflowMT` boolean param to `createJobBatch` method. If `true`, pass `localeWorkflows` param with POST request, containing an array with an object for each locale that has the locale id string and the workflowUid for machine testing workflow in the AT project. This param is not necessary if we want to keep the default workflow for each locale, so only include if `isWorkflowMT` is true. I couldn't find a way to fetch the workflowUids from the API, but they can be found on the project dashboard under Project Settings > Workflows, then clicking "Edit workflow Settings." Looks like uid is the same across an account/project, so we _can_ use the same one, but I left it out of this commit in case it should be kept private. Next iteration will include updating the translations tab config to include `options`, which could either accept one uid for MT or possibly and array of workflow names + id's to allow selecting from a custom set of workflows. This way we can set the ID from each project, instead of in the plugin. * Use workflowUid to create task with workflow Along with updates to translations-tab, use an optional workflowUid (if present) passed in by the user to set the workflow on task creation, rather than hard-coding the specific uid string for the machine translation workflow. Dev can pass an optional array of `workflowOptions` in the options config that's sent to `TranslationsTab`, enabling a select option in the tab for choosing a workflow and passing in `workflowUid` with the `createTask` params here. Example: ``` const myCustomConfig = { ...defaultFieldLevelConfig, workflowOptions: [ { workflowUid: '35cdc9b707d9', workflowName: 'Machine Translation (testing)' } ] } ``` * Handle errors; await for finished promises There are lots of points of potential silent and/or unhandled errors due to not applying await for async functions and/or not using a `catch` for any errors thrown. If we don't add `await` or `throw` errors, then the translation tab won't be able to tell if a the call is actually complete or was successful, resulting in a "Success" toast that's potentially inaccurate. I tried manually adding in errors in all the various calls and triggering the "Import" from the button in the translation tab and this update (along with the parallel change to `TranslationsTab`) allowed all of them to be caught in the `try/catch` added to `imortFile` in TranslationsTab. Note, however, that I didn't test the documentLevel functions because I don't have that implemented. I copied the changes made for fieldLevel and have no reason to believe they wouldn't work :) * Remove unnecessary catches * Update package version * Add `test` script Adds `test` script so that added workflow doesn't fail, although there aren't any tests yet * Comment out test from github workflow Commenting out `Test` from workflow for now because we don't have any tests so it fails. Tried to start by adding a simple test, but everything here is involves fetching from Sanity or Smartling so no simple functions to add quickly. * Remove `@sanity/client` dependency Had added this as a dependency in attempt to fix error showing in VSCode in helper.js where we import `sanityClient`, but that created different issues when I tried to use `@sanity/client` instead of `'part:@sanity/base/client'`, so just removing the dependency from package.
- Loading branch information