I don't see anything in the docs specifically about SS, I know P=props, and S=state but SS?
edit
Sorry, I was referencing this from a React+TypeScript project, namely #types/react. I have added the typescript tag.
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L395
It's used in the return value of getSnapshotBeforeUpdate so I'm betting it stands for SnapShot.
Runs before React applies the result of render to the document, and
returns an object to be given to componentDidUpdate. Useful for saving
things such as scroll position before render causes changes to it.
And the docs in that file for componentDidUpdate show it accepts a third argument called snapshot that says:
The snapshot is only present if getSnapshotBeforeUpdate is present and returns non-null.
So, SS is the user defined type of the snapshot returned by your custom implementation of getSnapshotBeforeUpdate, which gets passed to componentDidUpdate so you can preserve some application specific details from the last render.
Related
Imagine that you've built an application with ReactJs containing a hundred elements. Let's say that in some time, the state of component A changes, and for the sake of simplicity we assume it has only one element and no child component.
My question is: how is Virtual DOM updated in response to the state change?
After a few hours of research, I found two contradictory opinions:
The entire Virtual DOM is torn down; then it is rebuilt from scratch
Only the changed elements are updated in the Virtual DOM.
Unfortunately, official documentation is not clear about this. So, can anybody give the correct answer? (please with supporting reference)
[Edit] : Some parts are imcomplete here, think about reading the comment section !
React update a component when its state or a prop changes. It does a comparison between the previous JSX and the new one and re-render only the differences.
If the parent component has its state or a prop changed, it will be updated.
The child will not be refreshed unless a prop from the parent that is passed to it changes.
Note that the useEffect from the child is triggered first. Knowing that, If you do things that update the state in the child component, then it will be re-rendered everytime (Because the usEffect is triggered everytime if you don't set any dependencies).
Test from Stackblitz - Child Effect is triggered first
Article that made me notice it (I didn't know before this answer :D)
Here is how I understand things in React. To be short, the entire virtual DOM isn't rebuilt from scratch, it's not how JSX comparison works.
I don't have much sources about what I said, but here is the explanation about jsx update from the official documentation. Just that should be enough to eliminate the first point of your list.
I am learning to react lifecycle methods but stuck at a query and not able to find the answer even after lots of research over the web.
As per the react official documentation here, it is said that the method getSnapshotBeforeUpdate is used to perform something just before the DOM commit. The snapshot returned by this function will be later used by componentDidUpdate.
The query:
The parameters 'prevProps' and 'prevState' are already present in method componentDidUpdate, then why does it need the help of function getSnapshotBeforeUpdate? I mean the function componentDidUpdate has necessary inputs to perform what getSnapshotBeforeUpdate is doing.
Any help would be appreciated.
Best,
Rahul
As clearly mentioned in the documentation with an example, the purpose of getSnapshotBeforeUpdate method is not to just get information from prevProps and/or prevState.
But it can be used to extract some information from the previous DOM (such as the current scroll position of a div) before the DOM is updated. Most cases, such DOM related values may not be covered by the prevProps or prevState.
When you consider only the componentDidUpdate method, the DOM has already updated (hence the name DidUpdate) when it's been called. So all the information related to the previous DOM has lost by that time.
Therefore the extracted information on previous DOM from getSnapshotBeforeUpdate can be passed to the componentDidUpdate method to use it there.
I have global state working via Context/AppState/AppStateDispatch. I also have component state working via useState.
But there are times when it appears it might be helpful to avoid using these:
We need immediate access to the value in the current function and can't wait for the next render to get it. Storing it via useState/AppStateDispatch would prevent the value from being accessible until the next render
...and, those same values are needed globally throughout the app
...and a useRef would be destroyed on component unmount
In that case, it seems like it might be appropriate to use a globally-available, non-render-causing object to hold state for these items.
It's pretty easy to implement... but it seems non-React-y. Am I missing something?
I looked into this pretty extensively the past few days. Here are a few observations.
In my use case, I'm using an external webRTC service. Their code requires my app to install listeners for incoming calls, responses to publication of video streams, etc. The listers needs to access the component's webRTC-specific variables
At the same time, those variables can't be part of component state or app state, because when updated, their values won't be available until the next refresh, and the rest of the component needs to access them within the current render.
Using an application global var that is apart from React and doesn't trigger a refresh is, of course, kludgy.
Here's the approach I'm using at the moment. So far it appears to be helpful.
Create an application-state object to store all variables related to my component's use of webRTC.
Initialize it via a call to a function, getWebRTCDefaults().
On component mount, copy it from app state to a component-level variable. Note-- it is not in component state -- it's a component-level variable, accessible anywhere in the component.
As such it can be updated anytime within the component and its values are immediately available throughout the component.
When a call starts and ends -- and only then -- I use React context dispatch to update the app state object. I.e. I do not update that object via useEffect as that could cause unnecessary renders.
This approach seems to be helpful. I can unmount the component and when I remount it, it picks up where it left off -- the webRTC video is still running.
When the PropTypes are defined in a component, there is a certain expectation that these will check the type of the props when they are received. But it's clear that components can receive a prop value before it has been populated with the expected value and, therefore, the PropType warnings appear as a result. So at what point in the component lifecycle are the type checks being run?
This is the factory that bundles in the validation:
https://github.com/facebook/react/blob/master/packages/react/src/ReactElementValidator.js
When in dev mode, it is used here:
https://github.com/facebook/react/blob/8af6728c6f105d37f9c0006288a6d1ac3903dc71/packages/react/src/React.js#L61-L63
So, it looks like it's at the create/clone stage when props are being passed, for instance, bottom of the create element factory calls it: https://github.com/facebook/react/blob/master/packages/react/src/ReactElementValidator.js#L262-L333
If you late-change a valid prop to an invalid one, it either must clone or recreate the element (if it fires a warning) but I don't have the time to confirm this, you can easily create a basic class with loggers for lifecycle methods to verify.
you can search for checkPropTypes in the react repo root and find all uses internally.
the documentation says
All React components must act like pure functions with respect to their props.
https://facebook.github.io/react/docs/components-and-props.html, but does not explain the real reason behind it, why is that?
A React component should be pure, this means the result of its render method should depend solely on the props and the state, and for the same properties and state render should give the same result.
If render is not pure, it means it can return different results for the same input, so React cannot tell which parts of the DOM need to be updated based on the changes to the component. This is critical as the performance of React depends of this. Why? That's a bit complex.
It is amazing to define the UI based on a state, and have the UI re-render itselfs every time any part of the state changes. But you can imagine doing a complete re-render of the entire DOM every time you change something would be painfully slow.
React solves this by checking the minimum ammount of changes needed o the DOM to reflect the new state. It knows what those changes are based on what properties and state each component receives, and can tell if it needs to update a component if any of its properties or state changed.
Take this tree as an example of a component hierarchy
Here we changed h to 8, so we also changed f because h is a child of f, and we also changed c because f is child of c and etcetera.
The key here is to think how React checks the component tree. It ill start at the root and see it changed. Then it'll check all the children and realize only c changed, so there is no need to check all the a and b branches. Then it'll check the c branch and realize only f changed so there is no need to check e and g. That operation is done on every component to calculate the minimum ammount of changes and also what needs to be updated.
If at any point you could mutate how a component is rendered it means React will need to check all of the branches and all of its children to know what changed because it can't rely on the state and the props to know when a branch changed and how. This would be painfully slow and make the whole React framework inviable.
I would say because of tracking the component state changes. If it isn't pure, it would cause side-effects every time it is executed. That way, would be very hard to know what has changed and furthermore how to react to these changes.
Pure functions, in other way, have the same output with the same input. Making it a lot easier to manage properties and track when something has changed, resulting a easier and predictable way to react to the change.
If they weren't pure functions in relation to their props then it would be violating the entire heirarchy/delegation structure that react provides and relies on.
Lets say you have two components, component A and Component B, and Component A is the parent to Component B. Component A has its own state based on some sort of data. When you pass a part of its state down as a prop to component B, you are establishing a contract between the two components that component B will delegate to component A to get the value of said prop.
This is in a sense a contract between the two components and the only way the contract isn't violated is that component B doesn't directly alter or change the passed down prop. That is what being a pure function means, that it doesn't mutate the prop directly. Of course you can clone the prop and then change it however you want that isn't a breaking of contract since at that point they aren't referencing the same values. But if you do mutate props directly you will also be mutating the parent component value. This can cause unintended side effects as well as cause issues with the react shadow dom differencing algorithm.
Here is that explained from the official react docs
https://facebook.github.io/react/blog/2015/02/24/streamlining-react-elements.html#problem-mutating-props-you-dont-own
You will discoverer "Why" understanding Reconciliation algorithm React uses for rendering.
Here you have all the information needed to understand what you want.
Part of that is well explained in Marco Scabbiolo's answer, but If you want to understand the way React works I strongly recommend you to read the post I've suggested.
Posting the answer here would be too much for a post and unnecesary because It has already explained by React Team. That's why I prefer giving you the source directly.