Plugins don't support asynchronous functions

[ebner87]

Hi all,

I was looking at the documentation and some other suggestions in the issues list about how to inject new headers to Formio requests (more specifically when you want to use the Resources in a select Data Source Type, for example).

I know that I can set the formioToken and then use x-jwt-token in my backend, which would work fine for me if I didn't need to also have some other params passed along with the request (like location id, warehouse id, etc) that are selected in the frontend.

I tried a few different ways, but none of them worked. After implementing them, when I go to the form builder and select the Resources option in Data Source Type, it just doesn't trigger the http request anymore, if I remove those implementations then it comes back sending the request but, of course, without the headers I want to add.

Here's how I'm doing using Fetch API plugin:

`import { Formio } from 'formiojs';

const FetchPlugin = {
priority: 0,
preRequest: async (url, method, request, formio) => {
// Assuming you can get the JWT token asynchronously from your state
const jwtToken = await asyncFunctionToGetToken();
request.headers.set('Authorization', Bearer ${jwtToken});
return Promise.resolve(request);
},
};

Formio.registerPlugin(FetchPlugin);`

and here's another try using it right before I call the FormEdit component:

Formio.plugins = [{ priority: 0, requestOptions: function (value) { // Assuming you already have the token const jwtToken = state.userReducer.authJWT; value.headers.append("Authorization", Bearer ${jwtToken}); return Promise.resolve(value); } }];

I also tried creating a XMLHttpRequest interceptor, but am having the same symptom.

The versions I'm running are @formio/react 5.3.0 and formiojs 4.17.1

Any ideas I can do that (so I don't need to use the x-jwt-token header) or how can I add new parameters (such location id and some other ids that are referenced in the frontend)?

[brendanbond]

A better option here is probably the requestOptions plugin, see a trivial example here: https://codesandbox.io/p/sandbox/http-request-plugin-example-forked-y3m9v2?file=%2Fsrc%2Findex.js%3A8%2C19

I think the problem you're running into here, though, is that, at the moment, the request plugins don't accept asynchronous functions and can't really handle promises, so your code is not going to run and may just break the javascript execution by just passing Promise objects where actual options and request objects are expected. Although I would be interested to support asynchronous request plugin methods, for now you'll have to load any data that is needed by the plugin before registering it.

I am going to rename this issue and send it up the chain.

[ebner87]

Hi Brendan,

Thanks for the quick response.

Well, I didn't post all the different alternatives I tried to not get a very long post, but I also tried returning the options (or request/value) variable directly trying to keep synchronous nature of it and the issues was the same: when I have the requestOptions in place, the request is not triggered once I select Resource in Data Source Type.

So, not really only for async functions.

[brendanbond]

Cool, what would help here is if you could throw up a minimally reproducible example on a codesandbox or something similar so we can get to the bottom of it, I'm still not quite sure I'm following.

[ebner87]

Hi Brendan,

Nevermind. I was creating the codesandbox to send you and realized that I was using options.header.append to add the header to the request, this way is raising the issue I was talking about (where requests are not fired/triggered).

Changing it to options.header['custom-header'] did the trick.

I saw somewhere else that the this property was an object (or was being handled as such) instead of an array. It didn't come to my head to check it or try as an array (maybe I need some rest).

Thanks for the help though.