I want the best method to implement these two lines.
Goal: Obtain the object of a smart contract named dev-token.
async function ... {
...
const web3 = new Web3(Web3.givenProvider);
const devtoken = await new web3.Contract(abi,address);
...
}
Warning during execution:
MetaMask: The event 'close' is deprecated and may be removed in the
future. Please use 'disconnect' instead. For more information, see:
https://eips.ethereum.org/EIPS/eip-1193#disconnect
Cordially
I had the same problem due to an out-of-date version of the web3.js library. I was using version 1.2 imported from the jsdelivr CDN like this:
<script src="https://cdn.jsdelivr.net/npm/web3#1.2/dist/web3.min.js"></script>
The warnings went away when I updated to the current version of web3.js (1.7.3 at the time of this writting). However, the version distributed in the jsdelivr CDN has other problems, so I had to deliver from my own server the one downloaded by npm:
<script src="./web3.min.js"></script>
Related
I have installed react-native-version-check by yarn into my project when I use some functions the app crash sending me this message:
WARN [TypeError: Network request failed]
this only happens when I'm using these functions only:
VersionCheck.getLatestVersion()
VersionCheck.needUpdate()
The same thing happens using react-native-check-version package function
There has been some unresolved issues regarding this package and especially those functions that you mentioned. I had faced the same issue previously, my suggestion would be to go with a backend driven version check. You can maintain a table to store the latest version, force update flag, etc. Also since these 2 functions are promise, you can check what they are returning.
VersionCheck.getLatestVersion({
forceUpdate: true,
provider: () => fetch('http://your.own/api')
.then(r => r.json())
.then(({version}) => version), // You can get latest version from your own api.
}).then(latestVersion =>{
console.log(latestVersion);
});
VersionCheck.needUpdate()
.then(async res => {
console.log(res.isNeeded); // true
if (res.isNeeded) {
Linking.openURL(res.storeUrl); // open store if update is needed.
}
});
After some search in the library to know what was making this error
it was actually the fetch API
I had to put these lines of code in my build.gradle
dependencies {
api(platform("com.squareup.okhttp3:okhttp-bom:4.7.2"))
api("com.squareup.okhttp3:okhttp")
api("com.squareup.okhttp3:logging-interceptor")
}
after adding those lines everything worked just fine
version "react-native-version-check": "^3.4.3", is up to date
documentation link:
https://www.npmjs.com/package/react-native-version-check?activeTab=versions
I'm using Webpack Module Federation to create 2 React applications: host and child.
In the host, I create atoms.ts and selector.ts filed and I expose them via the plugin under the expose section:
exposes: {
"./atoms": "./src/recoil/atoms.ts",
"./selectors": "./src/recoil/selectors.ts",
}
Inside the child, I just consume that via the remotes section:
remotes: {
host: "host#http://localhost:3000/remoteEntry.js",
}
Then, in the code of the child I use that like that:
import {someSelector} from "host/selectors"
const val = useRecoilValue(someSelector);
It's working fine but I got this warning in the console:
Duplicate atom key "userAuthState". This is a FATAL ERROR in
production. But it is safe to ignore this warning if it occurred because of
hot module replacement.
Does anyone face that issue and know if it's really a problem or how we could hide the warning?
Another related q:
Is it ok that the host will contain <RecoilRoot> and also the child will contain <RecoilRoot> ? because I want both will manage their own state but also share atom/selectors.
Thanks!
Regarding your second question:
Yes, this is totally fine. The nested <RecoilRoot> will create its own context and every atom referenced below the second root will be independent from the upper root. This is also explained in the docs.
Regarding the first question: As the log states this is fine as long as it occurs during development. Sometimes during the hot module replacement recoil throws away atoms and reinstantiates them causing this duplication to happen internally.
But as long as this warning doesn't pop up in your production code, everything is fine.
Are you importing the atoms or the selectors in your host application using a local path?
You need to include in your host webpack config its own entrypoint as remote and import your atoms from 'host/atoms'
I think this could solve your issue.
You can ignore the warning output (if you can bare it), functionality is not affected.
Also, you can install the intercept-stdout package and add the following to next.config.js (outside of the exported configuration):
const intercept = require("intercept-stdout")
// safely ignore recoil warning messages in dev (triggered by HMR)
function interceptStdout(text) {
if (text.includes("Duplicate atom key")) {
return "";
}
return text;
}
if (process.env.NODE_ENV === "development") {
intercept(interceptStdout);
}
This way can omit the annoying warning in console.
=== SAD PANDA ===
TypeError: Failed to fetch
=== SAD PANDA ===
While executing a flow cadence transaction in react.js, I got the above error.
My intention is when I click the minttoken button, this transaction has to execute so as to mint the NFT.
const mintToken = async() => {
console.log(form.name)
const encoded = await fcl.send([
fcl.proposer(fcl.currentUser().authorization),
fcl.payer(fcl.authz),
fcl.authorizations([fcl.authz]),
fcl.limit(50),
fcl.args([
fcl.arg(form.name,t.String),
fcl.arg(form.velocity,t.String),
fcl.arg(form.angle,t.String),
fcl.arg(form.rating,t.String),
fcl.arg(form.uri,t.String)
]),
fcl.transaction`
import commitContract from 0xf8d6e0586b0a20c7
transaction {
let receiverRef: &{commitContract.NFTReceiver}
let minterRef: &commitContract.NFTMinter
prepare(acct: AuthAccount) {
self.receiverRef = acct.getCapability<&{commitContract.NFTReceiver}>(/public/NFTReceiver)
.borrow()
?? panic("Could not borrow receiver reference")
self.minterRef = acct.borrow<&commitContract.NFTMinter>(from: /storage/NFTMinter)
?? panic("could not borrow minter reference")
}
execute {
let metadata : {String : String} = {
"name": name,
"swing_velocity": velocity,
"swing_angle": angle,
"rating": rating,
"uri": uri
}
let newNFT <- self.minterRef.mintNFT()
self.receiverRef.deposit(token: <-newNFT, metadata: metadata)
log("NFT Minted and deposited to Account 2's Collection")
}
}
`
]);
await fcl.decode(encoded);
}
this error being so useless is my fault, but I can explain what is happening here because it also only happens in a really specific situation.
Sad Panda error is a catch all error that happens when there is a catastrophic failure when fcl tries to resolve the signatures and it fails in a completely unexpected way. At the time of writing this it usually shows up when people are writing their own authorization functions so that was the first thing i looked at in your code example. Since you are using fcl.authz and fcl.currentUser().authorization (both of those are the same by the way) your situation here isnt because of a custom authorization function, which leads me to believe this is either a configuration issue (fcl.authz is having a hard time doing its job correctly) or what fcl is getting back from the wallet doesn't line up with what it is expecting internally (most likely because of an out of date version of fcl).
I have also seen this come up when the version of the sdk that fcl uses doesnt line up with the version of the sdk that is there (because some people have added #onflow/sdk as well as #onflow/fcl) so would also maybe check to make sure you only have fcl in your package.json and not the sdk as well (everything you should need from the sdk should be exposed from fcl directly, meaning you shouldnt need the sdk as a direct dependency of your application)
I would first recommend making sure you are using the latest version of fcl (your code should still all work), then i would make sure you are only using fcl and not inadvertently using an older version of the sdk. If you are still getting the same error after that could you create an issue on the github so we can dedicate some resources to helping sort this out (and make it so you and others dont see this cryptic error in future versions of fcl)
Recently, React started giving depreciation warnings for componentWillReceiveProps lifecycle method. I am using a library that utilized this function and the maintainers haven't updated their codebase yet.
Currently, any time I run my tests, whether it is in development or in CI, I keep getting ~30 lines of depreciation warnings for each component that the maintainer provides.
Is there a way to suppress these warnings (at least in development)?
EDIT:
I am willing to add certain comments in my files to disable warnings from a specific package if there is a chance:
// some line to disable warnings for this package
import { DateRangePicker } from 'react-dates';
If you want to disable all warnings that meet some condition, keeping all other warnings, for all tests:
const originalWarn = console.warn.bind(console.warn)
beforeAll(() => {
console.warn = (msg) =>
!msg.toString().includes('componentWillReceiveProps') && originalWarn(msg)
})
afterAll(() => {
console.warn = originalWarn
})
React codebase also contains expect(render(...)).toWarnDev(...), but that's not included in Jest documentation, you might need to investigate more if you want to use that feature.
Similar in concept to a previous answer, but a bit easier would be:
jest.spyOn(global.console, 'warn').mockImplementationOnce((message) => {
if (!message.includes('componentWillReceiveProps')) {
global.console.warn(message);
}
});
If you wanted to do it across tests you could do:
let consoleSpy;
beforeAll(() => {
consoleSpy = jest.spyOn(global.console, 'warn').mockImplementation((message) => {
// same implementation as above
});
afterAll(() => consoleSpy.mockRestore());
A variation on #Aprillion's answer...
I wanted to suppress certain error messages in all tests (in a create-react-app application).
I added this to my setupTests.js:
// This error is a bug fixed in React 18: https://github.com/facebook/react/pull/22114.
// Suppress it for all tests.
const BOGUS_UNMOUNTED_ERROR = (
"Can't perform a React state update on an unmounted component."
);
const originalError = console.error.bind(console.error);
console.error = (...args) => !args.toString().includes(BOGUS_UNMOUNTED_ERROR)
&& originalError(...args);
I guess the most important difference is that I replaced (msg) with (...args) in two places, so that all arguments to console.error() were passed through. Without this, I was getting %s's in my console error messages that should have been filled in with other arguments.
So I found a way to fix these warnings for any library using react-codemod.
Since this library does not work inside node_modules so have to do a little hack.
Run:
yarn add -D react-codemod
open ./node_modules/react-codemod/bin/cli.js
Remove/comment line (72) > + // args.push('--ignore-pattern=/node_modules/');
Run:
./node_modules/.bin/react-codemod rename-unsafe-lifecycles
To this question answer with the path of the library, you want to fix...
“On which files or directory should the codemods be applied?”
./node_modules/react-dates/lib/** // or any library with issue
This could be a temporary fix till react-codemod support node_modules libraries.
You can also fork the library and remove the line for yourself and use it like this inside your CI pipeline to not get any warnings like this anymore.
You can just add this line above whatever is showing the warning. I have tried this in VScode so i'm not sure if it works with others. This disables whatever warning that will be displayed in the next line.
// eslint-disable-next-line
I get the following error "ReferenceError: printStackTrace is not defined",
when I tried to use StackTrace in my angular aplication.
stacktrace.js changed the API for v1.0.
You'll want to use
var callback = function(frames) { console.log(frames); };
var errback = function(err) { console.log(err.message); };
StackTrace.get().then(callback).catch(errback);
as suggested by the docs.
If all you want to do is parse an Error you can just use error-stack-parser
Please refer to the v0.x -> v1.x migration guide if you were using the old version.
By the way, if you need to use version 0.x you can find it in the stable branch on GitHub