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.
Related
https://svelte.dev/tutorial/debug
Occasionally, it's useful to inspect a piece of data as it flows through your app.
One approach is to use console.log(...) inside your markup. If you want to pause execution, though, you can use the {#debug ...} tag with a comma-separated list of values you want to inspect
I've been messing around with the React dev tools to find out where a state change is coming from but I can't find it. Instead of putting debugger after every thing that even looks sideways at the state I'd like to find a better solution.
Is there some sort of "stop on all changes to this variable" in React Devtools?
We are using hooks, not redux.
I am currently building a Tetris game on React just to practice hooks (used to develop in class components back in the day, kind of left React for a while and yesterday I decided to use it once again).
The game is working perfectly well, and it behaves as expected on each and every situation, however, there is a constant warning related to using a function within useEffect without it being a dependency.
To clarify - I have a useEffect function that all it does is call an updateFunction and is dependent just on the x and y coordinates of the moving Tetris block. The update function updates the state of the board whenever the position of the shape changes.
I know that React re-creates functions on each and every render, but giving a useCallback to the update function would cause it to be re-created endlessly (as then, the complier would ask me to make it dependent on the board state, thus each time it updates the board, it'll be forced to be re-created once again), and this causes an infinite loop of rendering.
Is it really necessary to put every function within useEffect as a dependency, even if said functions only causes a visual rendering to show the current state of the game?
You can always put whole function inside useEffect and you want get this error and problem
Someone just asked the similar question, and my answer is there, React won't let me use `useEffect` in a completely reasonable way
The answer to your question is that, no you don't have to, if the warning doesn't bother you, and your code is still working, then move on.
Otherwise you can try to find a way to disable this linter, or ask yourself why not to meet all the dependency requirement.
It's best to think of the effect dependencies as "correct" or not, and not try to tailor them to achieve some specific behavior. (The vast majority of the time anyway)
This means that if an effect uses a value that could possibly change, then it's declared as a dependency. Sometimes you app works fine if your dependencies are "incorrect" because elsewhere you can guarantee a value is constant. But this is more about maintaining the application than having it work currently.
Later if you change how one of the dependencies works in a refactoring, then the effect now may need to re-run and doesn't leading to strange and hard to diagnose bugs like stale values where you can't tell where they come from.
If this leads to cumbersome hooks with huge dependency arrays that infinite loop themselves, then it's an indication that logic is messy and needs to be refactored, split into multiple effects, rethink how the data flows through your hooks, etc.
It's hard to advise specifically without seeing your code. But in your case it seems like you could make the "update function" take arguments instead, which means it could then be completely static. Or if you did use useCallback that depends on x,y then it would regenerate when those change, but you probably have a lot of logic to run when those change, so that's probably expected.
Summary:
I would advise you to take the warnings of eslint-plugin-react-hooks seriously, and clean your code until it passes. In the long wrong, in a large and complex application, it really helps keep things clean.
There are very rare exceptions that come up when doing non standard things, but it's worth it to try your best on this before resorting to ignoring those warnings.
These past few days, i've been playing around with different animation libraries for React, in an effort to find a solution for transitioning between views (not routes), where a view would be a component wrapping other components and so on.
so far i tried:
react-transtition-group
react-animations
react-spring
Still need to experiment with react-motion's Transition...
...and there are a lot more out there, but all these, do what i need, except for one thing... while each state of the transition/style is applied, the child component(s) always update, triggering a re-render (which makes sense by the way), unless the child's shouldComponentUpdate() returns false, or is wrapped inside a PureComponent, both of which are not a solution, since you might (surely) want to do "things" with your component after the transition ends.
All the examples out there, serve their purpose, but they all use either functional components, or simple strings, for demo purposes, none of which one should care if are re-rendered or not, but a simple modification that would log every time the component is rendered, will show that they render multiple times during the transition.
Oddly enough, nobody seems to care, or is unaware. I have found very few questions or issues regarding this matter, though it's very much real, and the libs are very poorly documented on this.
Please share your solutions for avoiding this issue.
My workaround is to wrap the transitioned children/views inside a simple PureComponent, to prevent them from re-rendering, still it doesn't seem right.
I have the following states: 'home.person','home.person.house'
I'm in 'home.person.house' and want to hard reload state stating from 'home.person'. According to https://github.com/angular-ui/ui-router/pull/1809, I can pass as a parameter the start state from which the reload will start. So, I have the following line:
$state.reload('home.person');
However, the reload doesn't occur even thought everything in ui-route seems to work fine (debugged it). The resolve function of state 'home.person' wasn't called. Are there any suggestions why I'm not getting the result I wish for?
You can try using this :
$state.go("home.person",{reload:true});
It would be good if you could share the parent and child state codes. It's difficult to provide a solution without much reference.
Using https://github.com/reactjs/express-react-views as a starting point, I can successfully get server-side rendering/client-side mounting working. Problem I have is the size of the page once react has stamped data-reactid's over the state passed to renderComponentToString.
The object itself is a JSON payload from a server-side async call and comes in around 80KB. I pass this as is to renderComponentToString and the resultant page is over 20MB!
At this stage I'm thinking I could switch to renderComponentToStaticMarkup and take the hit client side for the first diff when I next update the state but wondering if there is a smarter solution here (props vs state?). Looking at the very clever react-quickstart (https://github.com/andreypopp/react-quickstart) I see the async state is effectively completely decoupled from the normal component lifecycle and therefore doesn't suffer from this issue however there's a lot of moving parts here and I'd rather come up with something more lightweight based on https://github.com/reactjs/express-react-views but with the necessary moving parts in place for client-side mounting to work.
Thoughts? Am I doing something wrong here?
I've resolved this for now:
The serialised payload for client-side mount was actually being rendered in the react render method, which was a noob error on my part. This was done rather than stringifying it and passing it down in a piece of non-react markup, which is what I should have done from the start.