Starting with Angular JS,I have read that components cannot access parent scopes, I mean, each component has its isolated scope. I read this is in order a component can modify its own data and not other components data. This helps to avoid situations where some data from a component can be modified from multiple inner components and would be difficult to resolve a problematic situation with data viewing and find which component is the problematic one.
So later, I read that you can pass in some data to a component with "bindings" from parent components, so the inner component cannot access the parent scope but gets information from the parent scope.So untill here, its ok
But I got surprised when I read that with "binding" in components, you can pass in a "property" by reference, so if in the inner component I modify this property, is not I can access the parent scope, but I am modifying the parent scope, right? So, the problematic situations can happen again, right?
Thanks
While accessing $parent in isolated scope is clearly an antipattern, this doesn't mean that modifying objects through bindings cannot cause problems.
It depends if parent component should be aware of changes that are made in this object. If it should, then the problem arises, because deep change detection (e.g. with $scope.watch(..., true)) is costly. In order to avoid this, child component can notify the parent of changes (scope events, & bindings), or use = binding with immutable object (the object is never mutated; any change should result in object being copied to a new one).
Related
Whenever I use Frameworks such as React , Vue or anything else. I see that every value (input value, select value ...) is always being emitted through events to parent. I don't really get why this is good. It takes more ressources / time to pass it to the parent component. Why doesn't the component handle its data by itself?? Why should every single value inside a child component get passed to the state of the parent to make the handling of the data ?
For example, I generally see the loading of the APIs in the parent and then the values of the API get passed down through props or Redux/Vuex. Why can't we get the API values inside the child directly when it's being mounted instead of having to pass it down on many levels or through the local store
It's perfectly valid to have a state inside reusable component, especially if it holds users input. You can still provide it with callbacks in props, which respond to onChange, onBlur or other events based on your needs, or you can communicate with your reusable component via refs, which is fairly flexible way to get user input.
The important thing is, that the reusable component should be as much independent on it's environment as possible. If you don't provide it with a state, the component (in case of your Pickers) will be dependent on props passed down from its parent expressing it's current user input on every rerender and on callbacks updating its current input somewhere higher in component hierarchy on every change, which is not what you want in every case, and it already forces you to make relatively large adjustments in you parent component, which misses the point of reusability.
I have a form (Parent) which contains an input field (Child), which gets its value from a reference table (Grand-grand-child) that is displayed as a modal (Grand-child) which opens up by clicking a button attached to the input field. This is a nested structure that roughly looks like this:
I need to set the value of the input field by selecting a row in the reference table and confirming my choice with a button "SET VALUE", which means I need to pass data three levels up from Grand-grand-child to Parent through Grand-child and Child.
My state is kept in the Parent component. Is there a simple way of achieving that without using external libraries? Please offer a solution using Hooks as all of my components are functional components.
Here is the code: https://codesandbox.io/s/festive-fast-jckfl
See CreateRate component where:
CreateRate.jsx is the Parent
InputField.jsx is the Child
DataFetchModal.jsx is the Grand-child
Airports.jsx is the Grand-grand-child
Pass a change handler function from parent (where state lives) down to the grand child. The grand child should call this change handler when clicking the Set Value button.
If this is too much prop drilling
look into component composition first
if that doesn’t work out, look into context api
Update:
You mentioned your problem was trying to access the state inside Grand-grand-child from your Grand-child. In this case you can lift the state up (to Grand-child). This means lifting 'airports' up to DataFetchModal. Here is more info on lifting state.
https://reactjs.org/docs/lifting-state-up.html#lifting-state-up
Also, it appears you are running into these problems because your code is very nested and not very composable. I would suggest looking into how you could better break up your components. One way to accomplish this is using compound components.
https://kentcdodds.com/blog/compound-components-with-react-hooks
Determining how to break this up better would take some time. However, just looking at this briefly. You may be able to move your DataFetchModal to your parent. Pass a callback to the InputField to fire it off and send the identifying parameters (what input called it). Then, from the parent, compose in whatever modal body using composition. It appears you have a lookup object (objType) inside DataFetchModal. Maybe this could go away by using composition (not sure, and probably separate topic).
Update 2:
I pulled down your code sandbox and made a few changes that may help access parent level state. I moved the modal into the parent. Check it out.
https://github.com/nathanielhall/Test
You are probably wondering what I mean by brothers components, well it's simply 2 different components that have the same parent component.
I am using angular.js 5.11
Let's say I have a parent component with a child1 component and a child2 component. I have a variable vm.active in my child1 component and I wish to use it (in an ng-if if you're wondering) in my child2 view.
Any ideas ? Was thinking of doing two way binding in both 3 components ? What do you all think ? Or maybe considering they are from the same state, probably as a stateParams ? Please let me know if you have any questions
This is the perfect scenario to create a service. Remember controllers have unique instances, but a service passes a common instance around.
https://www.w3schools.com/angular/angular_services.asp
Do not use two-way data binding in this case because you can accomplish the same in a more efficient way. Two way binding setup requires framework overhead.
One approach:
Setup one way binding of the variable (say x) in the Parent component to both of the children.
When child1 makes an update to the variable, pass in an observable reference that the parent can receive. The parent can set the value of x accordingly. Now both the children can see the update.
Here's another:
Use a singleton service. Save the variable in a related service. Use the getters and setter methods to retrieve and update the values.
Well ended up using $scope.$parent.$broadcast in first component and $scope.$on on the second component if anyone is wondering :)
As far as I can tell, if I pass a parent component state down to a child, then that child gets the live state of the parent.
So a change made in the state of the parent is immediately also available in the child via the prop that it came on.
Is this correct?
It's basically the same mechanism as anywhere else in the language, as you'd expect. Primitives are passed by value and variables that aren't primitives will be passed by reference.
React takes care internally of the updating of props, so that children always have the most up-to-date value of the prop.
This is the lifecycle method that is called when receiving new values for props.
However, make sure you respect the infrastructure put in place and the exposed API that React gives you.
Short answer: props are passed by reference.
The reason it can be confusing: if you change the parent's state by hand (bad practice!), the object will change in the child component, too. But won't trigger re-render! (The child component won't "know" that its props has changed.) So you won't see the UI change.
However if you change the parent's state with setState (the preferred practice), the child will be notified, that it must re-render itself.
If you pass down the state of the component as props to its child, then if the state of the parent component changes it re-renders, which will also re-render its children with the refreshed properties. The children don't directly listen for the state change like the parent does, they are simply re-rendered as as result of its parents state change and updated.
Take a look at this - https://facebook.github.io/react/docs/multiple-components.html. It will help you get your head round how this concept works. Hope this helps!
When the state of a component is changed, then the component is re-rendered by React. While doing that , its child components are also re-rendered, which causes changes in them also.
No, they will not be duplicated, you will access to those props by reference, because they come from a single object wich defines them, and then pass them as a reference to the child objects.
You can take a look to the official documentation here: https://reactjs.org/docs/react-component.html.
I suggest to use a stateless mechanism to handle large data, expecially if shared.
Personally I use mobx (https://github.com/mobxjs/mobx) wich is a great framework to create stateless apps.
With this method you can handle data and state updates in a single component, called Store, and use components to render html only, and not to handle data, wich is a great boost on application performances.
Is there a React-okay way to pass new props to children without re-rendering the parent? Nothing in the parent component is changing except that new props are being passed to that component which are being passed through to its children. I thought context might be appropriate in this situation but it seems like the documentation states otherwise.
It depends what you mean by React-okay. You can in fact use contexts for this, but I don't recommend it. It's much easier to reason about and debug props flowing down directly through your view hierarchy, and if the parent isn't changing at all the render function should be quite cheap to execute.
If it isn't cheap, you may want to rethink how you're structuring your components. For example, you may want to split off the expensive part into a separate component that only gets rendered when relevant props have actually changed, or at least secure the expensive functionality behind a conditional props check.