There is something I really don't understand in reacts and sometime the behaviors seem more about bug features that what is expected.
I was testing an instantiation by array. What is strange that the first time, it work as expected.
{this.state.pma.map((Item, index) => (
<this.props.typePma
key = {index}
ref = {(child) => { child.display(Item)}}
onDelete = {() => this.onDelete(index)}
/>
))}
But if I'm just updating the data even without changing it, like:
appendNewPma(){
var newPma = this.state.pma.slice();
//newPma.push(this.props.typePma);
this.setState({pma:newPma})
}
I've get exception error on this line:
ref = {(child) => { child.display(Item)}}
It complains that child is None (TypeError: Cannot read property 'display' of null
).
But why?!!! Why the logic change when there is no change: The data are not changed, just redisplayed. Why the ref is sending me null object where it is obvious the ref should always give me the instantiated object.
Petyo has already pointed you in the direction of the docs which explain the situation you have come across, but I would suggest that you change your approach, rather than blaming the library.
The whole point of a ref is so that the parent can have a reference to the child. Ideally, these should be used as little as possible but in some cases it is unavoidable. In your case, instead of saving the ref, it looks like you are using it as a sort of broken componentDidMount.
Why not just change the child component to call its display method when it is mounted and/or updated? Additionally, you should consider whether the "display" behaviour can itself be moved into a separate component.
You are facing the caveat that the React docs explain. Your ref callback gets called twice - with the actual element and with null afterwards.
Related
I am new to RxJs in general but am investigating a bug in some React code in which, upon an unrelated action, an old event seems to be emitted and rendered to a display error. Think if you had two buttons that generated two messages somewhere on screen, and clicking one button was showing the message for the other button.
Being new to RxJs I'm not positive where the problem lays. I don't see a single ReplaySubject in the code, only Obserables, Subjects, and BehaviourSubjects. So this is either misuse of an RxJs feature or just some bad logic somewhere.
Anyway I found the code with the related Observable and I'm not quite sure what this person was trying to accomplish here. I have read up on combineLatest, map, and pipe, but this looks like pointless code to me. Could it also be somehow re-emitting old events? I don't see dynamic subscriptions anywhere, especially in this case.
Tldr I don't understand the intent of this code.
export interface IFeedback {
id: number
text: string
}
export interface IFeedbackMessages {
message: IFeedback | undefined
}
feedback$ = new BehaviorSubject<IFeedback | undefined>(undefined)
feedbackNotifs$: Observable<IFeedbackMessages> = combineLatest([
feedback$
]).pipe(
map(([feedback]) => ({
feedback
})
))
I also found this which maybe be an issue. In the React component that displays this message, am I wrong but does it look like each time this thing renders it subscribes and then unsubscribes to the above Subject?
const FeedbackDisplay: React.FC () => {
const [feedbackNotifications, setFeedbackNotifications] = React.useState<IFeedbackMessages>()
React.useEffect(() =>
{
const sub = notification$.subscribe(setFeedbackNotifications)
return () => sub?.unsubscribe()
}, [notifications$])
}
Could it also be somehow re-emitting old events?
Yes, it probably is. BehaviorSubject has the unique property of immediately emitting the last value pushed to it as soon as you subscribe to it.
It's great when you want to model some persistent state value, and it's not good for events whose actual moment of occurrence is key. It sounds like the feedback messages you're working with fall into the second category, in which case Subject is probably a better choice.
does it look like each time this thing renders it subscribes and then unsubscribes to the above Subject?
Not exactly. useEffect accepts a callback, and within that callback you can optionally return a "cleanup" function. React will hang onto that function until the effect is triggered again, then it calls it to clean things up (which in this case consists of closing out the subscription) to make room for the next effect.
So in this case, the unsubscribe will only happen when the component is rendered with a new value for notifications$. Also worth pointing out that notifications$ will only change if it's either passed as a prop or created within the component function. If it's defined outside the function (imported from another file for example), you don't need to (and in fact should not) put it into useEffect's dependency array.
I am beginning to use React (hooks only), and facing a strange issue. I am trying to reproduce the problem in a small test code, but can't get it to happen, except in my full blown app. This leads me to wonder if I'm doing something really wrong.
I have an array of objects, declared as a state. I map this array to display its content. Except that nothing gets displayed (the array is filled, but nothing gets displayed). Now if I declare an un-related state, make it a boolean which flips each time my array gets updated, then my array gets displayed properly. As if, in the render phase itself, React did not detect the array's changes.
A few things:
the array gets updated by a socketIO connection, I simulate it here with a timer
I update my array OUTSIDE of my component function, BUT providing the setter function to the update function
I also create part of the render fields outside my component function (this has no effect, just for readability in my full app)
I essence, this is what I am doing:
const updateArray = (setTestArray, setTestTag, addArray) => {
setTestArray(prevTestArray => {
let newTestArray = prevTestArray.map((data, index) => (data + addArray[index]))
return newTestArray
})
setTestTag(prevTag => {
return (!prevTag)
})
}
const renderArray = (currentTestArray) => {
return currentTestArray.map((data, index) => (
<div>
testArray[{index}]={data}
</div>
))
}
function TestPage(props) {
const [testArray, setTestArray] = useState([])
const [testTag, setTestTag] = useState(false)
useEffect(() => {
let samples = 3
let initArray= []
for (let i=0; i<samples;i++) initArray[i] = Math.random()
setTestArray(initArray)
// In real code: setup socket here...
setInterval(() => {
let addArray= []
for (let i=0; i<samples;i++) addArray[i] = Math.random()
updateArray(setTestArray, setTestTag, addArray)
}, 1000)
return (() => {
// In real code, disconnect socket here...
})
}, []);
return (
<Paper>
Array content:
{renderArray(testArray)}
<br/>
Tag: {(testTag)? 'true' : 'false'}
</Paper>
)
}
This works just fine. But, in my full app, if I comment out everything concerning "testTag", then my array content never displays. testArray's content is as expected, updates just fine, but placing a debugger inside the map section show that array as empty.
Thus my questions:
is my updateArray function a bad idea? From what I read, my prevTestArray input will always reflect the latest state value, and setTestArray is never supposed to change... This is the only way I see to handle the async calls my socket connection generate, without placing "testArray" in my useEffect dependencies (thus avoiding continuously connecting/disconnecting the socket?)
rendering outside the component, in renderArray, doesn't affect my tests (same result if I move the code inside my component), but is there a problem with this?
As a side note, my array's content is actually more complex is the real app (array of objects), I have tried placing this in this test code, it works just fine too...
Thank you!
Edit: Note that moving updateArray inside the useEffect seems to be the recommended pattern. I did that in my full app. The hook linter does not complain about any missing dependency, yet this still doesn't work in my full app.
But the question is still whether what I am doing here is wrong or not: I know it goes against the guidelines as it prevents the linter from doing its job, but it looks to me like this will still work, the previous state being accessible by default in the setter functions.
Edit #2: Shame on me... silly mistake in my real app code, the equivalent of updateArray had a shallow array copy at some place instead of a deep copy.
Why adding the flipping tag made it work is beyond me (knowing the data was then indeed properly displayed and updated), but getting rid of this mistake solved it all.
I will leave this question on, as the question still stand: is placing the state update, and part of the rendering outside the component a functional problem, or just something which might mater on hide dependencies (preventing the react hooks linter from doing its job) and thus simply bad practice?
The fact is that things work just fine now with both functions outside the component function, which makes sense based on what I understand from hooks at this point.
Suppose I have something like this where both components A and D listen to changes in a global store :
import React from 'react'
import useStore from 'whatever-global-store-manager'
function A() {
const [store] = useStore()
if(!store.currentUser)
return <h1>You must log in</h1>
else return <B/>
}
function B() {
return <C/>
}
function C() {
return <D/>
}
function D() {
const [store] = useStore()
console.log(store.currentUser) // Can it be falsey ?
return <h1>{store.currentUser.name}</h1>
}
In A, when currentUser is falsey, B is not rendered, thus D is not rendered. But suppose this scenario :
At first, currentUser is defined as an object with a name property, so D renders, listens to changes in the store and renders the name.
Then, somewhere else in the app, currentUser is set to null.
In which order are the "listeners" processed ? Is there any chance that function D is executed with currentUser to null even when begin ultimately removed from the component tree ?
Another way to formulate the question : Should I check against currentUser in component D before accessing its name property ?
I was looking in the doc for a rule like "When two components listen to the same event, the one higher in the hierarchy is rendered first, and if it turns out the second one should be unmounted according the first's output, then the second one is never even called", but couldn't find anything. In practice, I know it works, but I would like to be sure that it's not just luck.
I believe this largely depends on the store observer mechanism, so it's hard to give a conclusive answer without knowing which store you're using. If observers are registered in order, that might affect how you need to deal with it.
If you wanna find out for sure, you could console.log your render methods, or use debugger while changing the value of currentUser.
Analysis of a hypotetical implementation: let's say an observer is registered when the component mounts, and unregistered when it unmounts. In this situation, the component A would trigger first (since it was registered first), and cause D to unmount, unregistering his trigger. In this hypothetical scenario, D wouldn't need to check for null.
Unrequested advice: a good thing for you might be centralizing the "data collection" in one parent component, while the children just receive that as props and render (without observing the store). I've found (both from lore and personal experience) that it simplifies a lot the development process.
Another way to formulate the question :
Should I check against currentUser in component D before accessing its name property ?
Yes, it is definitely a good decision: it is preferable that there is one redundant code line, instead of obtaining an error.
I was looking in the doc for a rule like
"When two components listen to the same event,
the one higher in the hierarchy is rendered first...
I think the opposite. Although I neither could find the specific documentation to explaine it, I remember that Components do not update like a cascade. That is the idea of the component oriented programming: each one is an independent entity.
Note: if I understand your example well, you could test this example by adding a setTimeout that wraps the return of function A, right? So this way you can then set currentUser as null and D wil be still rendered and you can see what happens.
i am fairly new to React and this is my first project with Redux.
I get some data and set it in the state-tree. When my reducer ADD_PRODUCTS_TO_CART runs, my Products->render() runs, but Product->render() does not, despite having a key.
Here is a gist, it was the most basic i could boil it down to. Hope it makes sense, i've included a file that represents the state of the tree, so you can see the data structure.
https://gist.github.com/hoodweb/e4005e4f1fc95682d4dd9bf87b81fe39
TLDR: Basically the stock decrements in the statetree, but is not rendered. What am i doing wrong?
Update: I have put in console.log() in all render methods, to see what is called. When i decrease the stock of my product, the product is not called. This is most likely due to the .map(() => <Product/>) i am doing. I tried changing my key={} property to include the stock like this:
.map((obj) => <Product key={obj.ID.toString() + obj.Stock.toString()} data={obj} />)
Which seems to work. But I do know how stable this is.
Update2: It seems that if i take my data={} property at put it into seperate properties like this
<Product key={obj.ID} stock={obj.Stock} title={obj.Title} price={obj.Price} beforePrice={obj.BeforePrice}
it works. So that is my solution for now.
In render function of Product you got:
if (data.Variations) { //TODO: Variation logic
return false;
}
Because in data you got Variations param, it goes through this scope (beacause Variations is not null or undefined) and returns null instead of rendering component.
remove return false and your code should work fine.
Like #kiarashws said, whenever you return false in your render() method, it doesn't render. Make sure to not render only when you don't want to.
Is commonly see code like this:
render() {
if (props.shouldNotRender)
return null or false;
return <div>
...
</div>
}
React suggests not to mutate props. I was operating under the impression that when props are passed in, they would be immutable or frozen.
The code below does not throw any errors and mutates the prop. Is this a bug?
try{
var a = this.props.a;
a.push('one')
a.push('two')
a.push('three')
console.log(a)
}catch(err){
console.log(err)
}
I'm not sure of the exact reasoning behind it or if that's documented somewhere but I could take a guess:
Freezing any assignment to a variable is not easy or even necessarily possible outside of using new-ish or even as of yet unimplemented browser features. Also deep freezing all your props in your app could have performance implications and would certainly need to be removed for prod builds.
Can you freeze assignment of a primitive variable? I don't think so. I think babel does it with const by statically checking code at compile time.
And can you freeze objects without Object.freeze or ES7's proxy? Again I don't think so, the es5-shim readme says:
which you cannot possibly obtain in legacy engines
What if someone does mutate something? These props are shallow copied, meaning you won't affect the parent prop unless you modify a nested object. However even if you did it would't affect the app, as that would get wiped out on the next render (just like your modifications).
If I got something wrong please let me know! This is just my reasoning.
It won't throw any error unless you frozen the object(props) explicitly.
Props are received from parents and immutable as far as the Component receiving them is concerned.
i.e React by default the props are immutable in the sense it is the concern of your component to maintain them as data received from parent and use as it is. Where as we can use state to maintain the local(component level data) that can be changed any time and keeping props contract with the parent.
Seems like this is the same behavior as const has, you can't reassign the value, but you can still push to the array or add keys to an object because those are not protected. Anyway, despite the possibility to do those mutations, you should not do this.
this.props.a = [1,2,3]; won't work
this.props.a.push(123); will work.
this.props.a = {name: 'John Doe'} won't work
this.props.a.name = 'John Doe' will work
If you try to reassign a prop in your component a type error will occur.
Uncaught TypeError: Cannot assign to read only property a ...
This is not true. Props are mutable by default. If you're using ES2015 you can make them read-only within your function be doing the following:
const { a } = this.props; // would create a const variable 'a'.
Same as:
const a = this.props.a;
While you won't be able to reassign 'a' now, you can still mutate it. Meaning, a = 'foo'; will throw an error, but you will still be able to do a.push('foo');.
If you want to use immutable data structures, try working with https://github.com/kolodny/immutability-helper or https://facebook.github.io/immutable-js/