I’ve gone through all the documentation I can find. What does the react test renderer act() function actually do? They give short justifications here and there, but I mean at a more technical level.
Ty!
https://reactjs.org/docs/test-renderer.html#testrendereract
This document is the best explanation I've found, although it still seems incomplete.
In short:
In synchronous use (i.e. the callback function you pass to act() does not return a Promise, and you don't await the results), act(f) runs f, then makes sure that any React state updates and effects started during f are finished before returning.
In asynchronous use (f returns a Promise, and then you await the results of act(f)), it... maybe also magically waits for any Promises created during f? It's not really clear. In a GitHub issue filed on the above document, someone asked the author to clarify this, but they haven't responded.
Related
I'm new to useSWR, and trying to figure out its benefits. So far, I feel like my refactoring is causing me quite a headache, and one that came up again is that I am not receiving the data from the hook that I expect.
If you see the screenshot, in one hook I get the proper data, and the other one, I get the whole response from axios. It doesn't show on the screenshot, but I have tried using the same axiosInstance on both fetcher, and things are the same.
I have also tried to add a async/await on the fetcher, still the same. Any idea?
My workaround is to type and refactor the parsed response., so I get instead
data.data.resultinstead.
What fixes my issue was actually to close/kill the app, then re-start it. It give me the expected result only then...
This answered my question, but leads to another one... why? ^^'
Consider the following code
useEffect(effect, [v]) // v can be undefined
I want to run the effect function only after the first render or when v changes.
My questions are
Do I need to check whether v changes in effect? Or I can rely on react to check the value of the dependency list (i.e., the [v]).
If the answer of 1. is the latter, is this behavior supposed to be changed in the near future? For e.g., when the concurrent mode is released.
From react official docs
Conditionally firing an effect
The default behavior for effects is to
fire the effect after every completed render. That way an effect is
always recreated if one of its dependencies changes.
It says if one of its dependencies changes, then, an effect is recreated. However, it does not mention the reverse: an effect is recreated if and only if one of its dependencies changes.
I only remember that in the early stage of hook, I read somewhere that the effect function can be run in some cases even without v's change, in order to optimize the memory, or in concurrent mode?? I really do not remember exactly and could not find out the source.
It would be very helpful if anyone can tell me how exactly React does, or refer to the related internal source code of react. I think they would have a special check of the first render, otherwise, when v is undefined after the first render, effect will not run.
I also posted the question on react repo here. The thread helped me solved my question.
Hope that it also helps others.
In React's componentWillReceiveProps function, if I check whether the props have changed first, is it ok to then make an AJAX call? It seems that this function may be called multiple times in React Fiber (post 16 beta) and this blog (https://medium.com/#baphemot/understanding-reactjs-component-life-cycle-823a640b3e8d) suggests that no side effects should be performed. However, I didn't see such a warning in the React docs and I figured that the AJAX call was made only if the props changed that that would be OK.
According to recent (React 16.3+) documentation, this is considered unsafe and in reply to your exact query:
Using this lifecycle method often leads to bugs and inconsistencies,
and for that reason it is going to be deprecated in the future.
If you need to perform a side effect (for example, data fetching or an
animation) in response to a change in props, use componentDidUpdate
lifecycle instead.
It's ok to make a call in OnWillReceiveProps but it's up to you to define a condition that makes sense, if your condition is well made you should not have a lot of call. Anyway you should in most of case avoid the use of OnWillReceiveProps which is kind of greedy in term of perfomance
I am using React.rb (a opal-ruby binding to react.js) and Opal-rspec for testing.
It seems like I need to reset react's internals between tests as I am getting the awful "Cannot read property ‘firstChild’ of undefined" error, in some tests.
If I move the "failing" test to be the first test, then the error goes away (but can come up in a later test.)
React.rb is NOT being loaded twice, I have made sure a couple of ways including putting a console.log into the first line of the react source file.
SOOO It would seem I need a way to completely clear reacts state between tests. Any way to do that?
The problem seems to occur if you do a static render of a component that is later asynchronously updated (i.e. when a promise is fulfilled). Once this happens react is busted. I don't know if this is inherent in react, or its because of the reactrb bindings (I doubt that as they are very simple) or something else.
I discovered by experimenting that creating a timer with a duration of 0 allows me to defer work into the event queue. I really like this feature, because it allows avoiding a lot of nasty reentrancy issues. Is this intentional functionality that will not change? Can it be added to the documentation? If not, is there a supported way to do this?
Current Answer
The proper way to do this is with scheduleMicrotask(Function callback).
See the API documentation here: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-async#id_scheduleMicrotask
A great article on async tasks and the event loop is here: https://www.dartlang.org/articles/event-loop/
Old Answer (pre Dart 1.0)
For now, the answer is yes, new Timer(0, callback) is the easiest way to defer a function call.
Soon, hopefully, http://dartbug.com/5691 will be fixed and there will be a better way. The problem with Timer is that the HTML spec says that the callback should happen no sooner than 4ms later. Depending on what you're doing that can be on issue.
Microsoft introduced setImmediate() to solve this. It invokes the callback at the beginning of the next event loop, after any redraws. My preferred solution in Dart is to have Future.immediate() defer until the next event loop, and possibly a function like defer() that takes a callback.
But new Timer(0, f) will still work, even after a better solution is available. I wouldn't mind a lint warning for it though.