Allow different recipes to be called via the INK component

The existing INK components (frontend and backend) were built to handle conversion of DOCX files to HTML; this change allows any INK recipe to be called in the same way.

• Adds a "recipe" parameter (fixes #54)
• Adds an "outputFile" parameter (so the backend knows which file to download at the end of the process)
• Refactor to improve promise handling

The changes to the backend component are backwards-compatible (tested in Editoria) - finding the recipe id works as follows:

1. Read the "recipe" parameter.
2. If there's a matching key (e.g. 'editoria-typescript') in config['pubsweet-component-ink-backend']['recipes'] use that value as the recipe ID. This is the ideal situation, where the app configuration maps keys used in the frontend to recipe IDs in the configured INK instance.
3. If there's no key, use "Editoria Typescript" as the default (for backwards compatibility). Fetch the list of recipes from the INK API and find the recipe with title that matches this key (this is how it used to work, but is inefficient as it has to fetch and filter that list for every conversion).

added 46 commits

• ecc2475a...ca4b3265 - 45 commits from branch master
• fc4bc326 - Merge branch 'master' into ink-backend-recipe-parameter

Compare with previous version

changed the description

Two thumbs up on the backwards compatible implementation.

assigned to @jure

added 3 commits

• 16cb3191 - Restore request peer dependency
• 48f896fa - Improve retry algorithm
• bfba4946 - Update yarn.lock

Compare with previous version

mentioned in issue INK/ink-issues#3 (moved)

Cool, this looks good! Authorization happening on app boot up in particular, was an issue for several users of the component. Now it's happening on request, which makes a lot more sense

I had to look twice at !113 (diffs) as it uses options.recipe twice, but then it made sense. Containing a map of recipeKey to recipeId in the config makes sense, since it's human readable then. One source of confusion though might be, that the user configures options.recipe to be 'editoria-typescript', and the options.recipes map points to say id 7. To the user that all seems OK, but the options.recipe is of course not linked in any way to how INK itself is configured, so its id might be e.g. 12. So, what I'm saying is, that using options.recipe without options.recipes is more intuitive, but worse in a performance sense. Not really something that can be addressed in this MR, but we should add config docs in a separate MR.

LGTM

merged

mentioned in commit a0176b98

This will be a patch release, due to the backwards compatibility. Thanks @alf!

Agreed, keeping the recipe mapping backwards-compatible makes it a bit confusing - we can probably simplify later (maybe allowing INK recipes to choose a non-numeric ID, or having separate pubsweet-server API endpoints for each recipe, or something else…).

Successfully published: pubsweet-component-ink-backend@0.1.1 pubsweet-component-ink-frontend@0.2.3