Most places suggest showing spinners or global modals at the top-level inside app component. Regardless of how we manage them, this would mean state change in the top-level component, which would then rerender and then all the children will re-render. Isint this more expensive than say just rendering the modal or spinner inside the component which needs it? even if it means repeating code. I mean we can live with some code repitition as long as we dont have to rerender our whole component tree. Maybe i am not very experienced with react and missing somehting fundamental here
In my opinion it just depends on the context. If you're loading the data that affect the whole app (auth info, feature flags etc.) the loader should be on the top level (since the whole app should actually refresh after the data loads).
On the other hand, you can add the loader modal side by side with the root of the actual component tree, so that it doesn't cause the whole view to rerender, it's all up to the design/requirements.
Related
Let's say I've triggered an update of a single React component & as we know by default it will trigger the update of all it's children components.
BUT
How does it work in combination with browser's reflow/repaint ?
How does the whole process look like (step by step) after we trigger a single React-component's update?
By default, the child components would be updated as well, however, that only happens in the virtualDOM, and not the actual DOM.
Changes are made to the virtualDOM, React then checks to see which DOM elements/components are changed/updated, and only those are updated in the actual DOM, it's part of the reason why your React app is fast.
You can refer to this thread for more information, though I think they are more so on class component, not functional component.
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.
When views DOM is heavy, sometimes it gets some time to render it, especially on older mobile devices. I would like to put a spinner whenever the view is not rendered yet.
I can achieve that using ngAfterViewInit hook but doing it for every view provides a lot of duplicated code.
I was wondering if there is a global hook that is fired whenever rendering of current view is done.
As Jota mentioned in a comment, what you're asking for doesn't exist in angular. Something you could do, which may or may not be appropriate to your situation, is add a single spinner component to the root of your app (say, in app.component.ts) and create a service which can turn it on or off. This way, in each of your child components you could turn the spinner on in ngOnInit and turn it off in ngAfterViewInit.
Another option, if you're using the Angular Router, is to have this spinner component listen for router events: turning on at NavigationStart and turning off at NavigationEnd.
This question has two parts:
Why do prop types check fail in my react-only scenario?
Why does a material-ui HoC interfere with the type checking?
When making UI components, I make the children unaware of each other, by passing props through React.cloneElement in a unidirectional flow. In my approach, the root component updates its screen size state, and it's children must accept and pass it on to the next child, and they can adjust the values according to content area dimension left for it. The idea is that the the leaf child itself can decide how to render depending on the space left.
In my simplified code example, the WithSize-enhancer informs the root component the full screen size, while the BridgedContent-enhancer informs the leaf component how/if it should render:
https://codesandbox.io/s/92vop4oyr4
It turns out that the root component (EnhancedPrimaryUI) gets its necessary props, passed from either parent or enhancer. It's child's prop type, on the other hand, will fail on page load. Running devtools only reveals what's going on runtime, and looks totally OK:
I really have no idea why it has to be like that! To me it just appears to be React inner workings. My tentative workaround is to add defaultProps, either in every child, or in App.js see second example.
I know about alternative workarounds like passing context or connecting child components to redux, but don't see how such could be motivated in this case.
I get even more confused because I implemented Material-UI, and found out that every child component that is styled with the WithStyles-enhancer magically causes no failed prop types! see third example
I know material-ui uses context to pass only theme/classes into withStyles.js, and claims to not modify the component passed to it.
So what is happening here? Does it effect it indirectly by the order React do things? Is it a feature or is it a bug?
While I still haven't found an explanation to question 1 (why the prop requirement is not fulfilled in spite of having props to seemingly flow nicely), I found there are several ways to ensure the props get there safely:
Add initial JSX props in App.js: <SecondaryUI height={0} width={0} isMobile={false}> BridgedContent height={0} width={0} isMobile={false}/></...
Use initial state from wrapper component (like in PrimaryUI), where the wrapper can be a context-provider. (This could be a clue to question 2)
Use default props
On a sidenote, the intended mechanism can be accomplished much cleaner now using React-hooks. See example: https://codesandbox.io/s/71r7l9ppvj
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.