For a project, we want to have notifications visible throughout all views in the app.
The sidebar menu allows users to move between views, and is on the same level as the notification component and the websocket component react-stomp. The router is used to change the view on the next level depending on the selected menu item.
Our problem is that if a new message arrives, we need to pass it down to the view as props, and of course this triggers a re-render of the entire component.
Is there a way to avoid this rerender?
We would like to avoid redux, though we are aware it is a possible solution.
By default, if props changes react will trigger re-render. If you want to avoid rendering a componenet you can use the hook shouldComponentUpdate(nextProps, nextState)
Quoting React's documentation:
Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.
For further reading visit their docs
Have you tried experimenting with react lifecycle event hooks ?
You could use REACT CONTEXT API if you want to avoid using a state manager like Redux or MobX
Related
I'm trying to use react-navigation make a reusable SplitView component for React Native where the parent navigators are able to perform navigations on their children. To accomplish this I am using ref's to programmatically perform navigations on nested navigators. However, I am running into an issue where when my app re-renders, all my navigation refs become:
{ current: null }
And I am not able to perform any further navigations.
Here is a link to a Snack project demonstrating this issue. Note that you will have to uncomment lines 13-17 in App.js to see the issue. The commented-out useEffect is there to force an initial re-render. Without it the navigation works just fine.
The docs for "Navigating without the navigation prop" have some notes around initialization issues with this use case but I didn't have any luck with their suggested solutions. I think the issue they are referring to is a race condition before the Navigation container has a chance to mount--I don't think this is what is happening to me because it seems like once my app re-renders I NEVER get access to the correct ref.
It turns out the issue was because I was using createRef instead of useRef. When working with refs + functional components it's necessary to use the useRef hook since createRef will return a new ref on every render, and it's not possible to store the created ref as an instance variable as you would in a class component.
I am new to React and a bit struggling with state in React and how and where we need to use it. So far, I found out that "If modifying a piece of data does not visually change the component, that data shouldn’t go into state". So, state is all about re-rendering the UI(I hope I am correct). So, the question I want to ask is Is it true that we use state only for re-rendering the UI only?, nothing else and nothing more?
You can use state in your class components. State is like private data of your component that may change by action made by user.
State is immutable. This means you can not change state directly in following way this.state.someVal = "smth". The only way to change state is using this.setState() method.
When you change state value React automatically re-renders your component without refreshing the page. In other words React.js reacts to your changes
State is an object that is directly tied to rendering the component. The reason why you can't change State directly with say this.state.foo='bar' is that React would have no way of knowing that it needed to re-render the component if you did that. Thus there is a setState method to change the state, which under the hood calls the render function of your component.
Therefore, if you have some data that has nothing to do with rendering the component, you don't want to put it into state, as setting its value will cause unnecessary renders to occur. If you're using class components, you can just put that data on the class directly: this.foo='bar'.
Basically yes! Two examples might be: A - holding a list of items (shopping list, or todo items) that are rendered directly to the UI, that are subject to change as the user adds and removes items. B - a value that determines whether or not you want something to show up on your UI, for example, you might have a state value called 'showNavbar' that is either true or false, depending on whether you want the user to see a navigation bar.
I hope that helps make sense of it in a basic way :)
We use the state for rendering the UI.
Also, I think the State allows React components to change their output over time in response to user actions, network responses, and anything else, without violating this rule.
For this, We use the 'setState' method.
setState() is the only legitimate way to update state after the initial state setup
I'm using ember.js(version 3.7) and I bite confused now. Now, I'm working on optimizing the code part for our app. First I'll try to find What are the things are re-render in components? After getting into this topic I bite confused with it.
In ember they used didRender() method to trigger re-rendering things (jQuery DOM Manipulation, Asnyc function loading,etc...). Right now I don't have much idea about re-render in ember. Can someone explain to me re-render in detail? And, please share if you have any resource about re-render in ember.
Thanks in advance.
didRender hook doesn't about triggering a re-render. It is described as the Guide that you shared the link of:
You can leverage this hook to perform post-processing on the DOM of a component after it's been updated.
You might want to do something about sizes or focuses or scrolls. To achieve that you need to wait till your rendering finishes. Because otherwise you cannot get the exact values and positions of the components. For those cases you can use didRender hook.
For example:
- if you want to focus some parts of the view
- if you want to scroll some parts of the view
- if you want to resize some components
- if you want to call a third-party libraries which tries to access DOM element.
etc. You can use this hook.
For sure, if you do something that affects to component's values, it can trigger a re-render. But this is something that you normally shouldn't do.
Let's have one more clarification of re-render:
As components are rendered, re-rendered and finally removed, Ember provides lifecycle hooks that allow you to run code at specific times in a component's life.
(Ref)
Guide says about 3 main phases (Ref):
Initial Render
Re-render
Component Destroy
In here Re-render means, if an argument or a property of a component changes, it starts to re-render itself. For example, think of a person-card component which displays the properties of a person. Such as {{person-card person=model.person}}. Whenever the person parameter changes, the component will re-render.
I have a React app that takes the user through various steps. I want to have the ability to use the browser's "back" button to go back to a previous step. Now I'm thinking of using react-router to do this.
Currently, I am simply reacting to events and calling setState on my top-level component.
My question: Does all state have to be reflected in the URL, or saved into local storage? Or can I keep the component's state and just have react-router change some props on the top-level component? When I do that, do I risk loosing the component's state (e.g. because React doesn't identify the old and the new components)?
I want to have simple URLs like /step1, /step2... . These do not reflect everything that is going on in the app. Specifically, I don't need or want the ability to directly enter such an URL. There are also privacy concerns. I am happy with having the application's state in the main component's ephemeral state. In other words, my application's state is not a pure function of the route.
I want to mainly use react-router to make the back button act as a glorified undo / go to last step button, and only secondly to navigate to other components. Any idea or small snippet showing how to do that? Or is react-router not suited for this?
When React navigates from one component hierarchy to another (such as react-router links / history navigation) it only unmounts the components that do not exist in the new component hierarchy. State is only lost in unmounted components. If your state is properly stored at the top level which only goes through rerendering and not remounting, you should retain it.
I want to know, what are events, that cause React component to re-render.
I couldn't find full list anywhere, it'd be great if someone writes the list of events, that cause React component to re-render.
I always find the following reference website helpful.
http://reactcheatsheet.com/
Filter by lifecycle events, and you can see the places where setState will trigger a rerender.
__
Update: you now have to filter by "misc"
React component is re-rendered when setState() is called or when props change. You can also force re-render with forceUpdate()
https://reactjs.org/docs/react-component.html#forceupdate
By default, when your component's state or props change, your
component will re-render. However, if these change implicitly (eg:
data deep within an object changes without changing the object itself)
or if your render() method depends on some other data, you can tell
React that it needs to re-run render() by calling forceUpdate().