My issue is regards to blob storage, but is suspect the issue is universal to the sdk.
It is impossible to use this client, or to generate a working client from the spec that can run in react native.
There are always incompatible dependencies included, especially from this projects' core-http.
Compounding the problem: the spec is not valid swagger, so using a different generator does not work at all.
Thanks for reporting @ehvattum
Can you elaborate on the kind of incompatible dependencies that you have encountered when using the libraries that depend on core-http?
Or if you can point us to a sample app using react-native and say the blob library with steps to replicate the problem, that would be helpful too.
@ramya-rao-a Issue updated: This is a related issue: #4917 - mentions xmlbuilder and xml2js as examples.
Is there any updates/plans on this issue ?
@AndriiDidkivsky sorry we don't have any concrete plan yet on the timeline. We know that one of our dependencies xml2js has circular dependency issue which prevents it from being used in reactive-native. However, we don't yet have a replacement xml parser. We are also working on separating out the xml parser dependency to a separate package, so it would not cause problems for users that don't depend on storage. Again, no ETA yet on when that would be available.
I am receiving this error while bundling the react native project. Sharing this as it may help for integration.
error: Error: While trying to resolve module@azure/loggerfrom fileC:Usersxxxsourcexxxnode_modules@azurestorage-
blobdistindex.js, the packageC:[email protected]was successfully found. H
owever, this package itself specifies amainmodule field that could not be resolved (C:Usersxxxsourcexxxnode_module
[email protected]`. Indeed, none of these files exist:
@jeremymeng Is there any new update? I saw it was tagged with milestones.
I've been investigating what it would take to support react native with our SDKs today and with some changes I've been able to use some @azure/storage-blob and @azure/app-configuration APIs.
Here's what I've found so far.
The react native bundler (metro) respects the browser and react-native mappings in package.json, but does not look at the module field. This means that for packages that have runtime specific logic (which is most of them), we need to at a minimum include a mapping from main to module. In practice this looks like:
{
"react-native": {
"./dist/index.js": "./dist-esm/src/index.js"
}
}
react native uses JavaScriptCore for executing JavaScript code, and includes shims for a few APIs like fetch and XMLHttpRequest. However, it does not expose APIs like crypto, Text(Encoder|Decoder), or atob/btoa. It also doesn't include any node.js modules.
This means we really need to treat react native as a 3rd runtime, and many places where we have node and browser files today, we may need a react-native version as well.
The @azure/cosmos library uses isomorphic-webcrypto when running in react-native, and requires the user to install it themselves. This may be something we can depend on for our libraries that require signing (e.g. AppConfiguration).
React Native doesn't provide a way to build or parse XML. In node.js we use xml2js to handle building and parsing XML, but this package doesn't work in react native because it depends on some native node modules.
I did find another library - xmldom that exposes DOMParser and XMLSerializer with APIs that match those found in browsers, but it has not yet reached version 1.0.0. It has some subtle differences from the DOMParser in browsers, and doesn't expose everything that'd be nice to have as part of its public API (e.g. enums.) However I was able to get it working with storage-blob with some minor changes to the browser version of the xml utilities.
React Native doesn't include a utility to do base64 encoding/decoding (e.g. atob/btoa). It appears that they used to have a utility package that was removed sometime prior to 0.60.x.
However this can be solved by relying on the buffer module much like we do for browser builds.
The react-native toolchain handles TypeScript compilation itself.
It currently lacks support for for...await loops, so operations that return AsyncIterableIterators can't be looped over this way.
They do still work if you call next on the iterator.
There may be a way to configure either the metro bundler or babel to support for...await but this is not strictly an SDK issue (since users can't write code that uses for...await.)
Currently the credentials available in @azure/identity won't work in react-native and msal does not (yet?) support react-native either.
It is possible to use the react-native-app-auth package and create a custom TokenCredential to use with our packages.
Rough example:
import { authorize } from "react-native-app-auth";
import { TokenCredential } from "@azure/core-auth";
export class ReactNativeAadTokenCredential implements TokenCredential {
constructor(private clientId: string, private redirectUrl: string, private tenant: string) {}
getToken(scopes: string | string[]) {
if (!Array.isArray(scopes)) {
scopes = [scopes];
}
return authorize({
clientId: this.clientId,
redirectUrl: this.redirectUrl,
issuer: `https://login.microsoftonline.com/${tenant}/v2.0`,
scopes: scopes,
}).then((result) => {
const expiry = new Date(result.accessTokenExpirationDate).getTime();
return {
token: result.accessToken,
expiresOnTimestamp: expiry,
};
});
}
}
Currently the biggest blocker for AMQP-based services (service-bus/event-hubs) is lack of react-native support in rhea.
More investigation is needed here.
Most helpful comment
Is there any updates/plans on this issue ?