I Am new to angular2. Trying to understand the usage of #Input in a better way. We can pass values from parent component to child using #Input also we can create a service variable and inject it to the parent component and can access them in child components. Which way would be better? I am getting these values through route resolves. I am feeling skeptical to use #Input when there is no binding of it with user input.
Generally there are two types of components - Presentational and Container or also sometimes called stateful and stateless. Here is the expert from this article explaining the difference:
Presentational components:
Are concerned with how things look.
Receive data and callbacks exclusively via props.
Rarely have their own state (when they do, it’s UI state rather than data).
Container components:
Are concerned with how things work.
Provide the data and behavior to presentational or other container components.
Are often stateful, as they tend to serve as data sources.
Presentational components should receive as much data as possible in a declarative way through input bindings. Container components should use DI as much as possible.
I'm just guessing but like anything it depends on the use case.
If your child component is acting like a stateless component but depends on the data the parent container has state-like access then you'd probable want to use input to pass down the data to the child components.
For example one case that comes to mind is the use of form groups and formcontrols
which the container keeps track of sort of the formgroup logic/state and on submit if the form is reactive will send a data object back or least should.
I'm not familiar myself but the use case for input that makes sense is when you have just rendering visual components that need just some data referenced from the parent container.
hope that makes sense. :) or least shed light on one use case hehe
http://learnangular2.com/inputs/
"most developers need to know how to pass data into components to dynamically configure them."
another good pictoral guide: https://www.sitepoint.com/angular-2-components-inputs-outputs/
Well, to be precise #Input() has nothing to do with user input as you think. It is basically used for passing data from parent component to child component. I agree that the name Input() leads to confusion, but its usage is different. Coming to service injection, this is not related to parent-child. Components at any hierarchy can inject services independently as they need. To conclude it, best method to pass data from parent to child is using #Input().
Related
So basically I have an app with a single component tree. App as a parent and then it goes down from there. Initially, all of the states are obviously centralized from the parent component App, as it is normally, and then the state is passed per component via props. We all know this is a hassle as the component tree gets bigger and bigger.
I'm studying React-Redux and just curious if I always have to use connect() and then each create a mapStateToProps and mapDispatchToProps for each and all my components including the subcomponents? Is there a one-off way to do this? Isn't it possible for my many components to just access the entire store without mapping each state/dispatch to props one-by-one, which I find repetitive and time-consuming?
I came from a Vue-Vuex background (although my Vuex experience is limited) and React-Redux is just a whole different ball wax, if not quite a lot more complicated IMO.
Per the Redux FAQ entry on "Should I connect all my components, or just one?":
Early Redux documentation advised that you should only have a few connected components near the top of your component tree. However, time and experience has shown that such a component architecture generally requires a few components to know too much about the data requirements of all their descendants, and forces them to pass down a confusing number of props.
Emphasizing “one container component at the top” in Redux examples was a mistake. Don't take this as a maxim. Try to keep your presentation components separate. Create container components by connecting them when it's convenient. Whenever you feel like you're duplicating code in parent components to provide data for same kinds of children, time to extract a container. Generally as soon as you feel a parent knows too much about “personal” data or actions of its children, time to extract a container.
In fact, benchmarks have shown that more connected components generally leads to better performance than fewer connected components.
In general, try to find a balance between understandable data flow and areas of responsibility with your components.
With Redux you don't have to connect all the components to its store. You only connect the components that really need it. For example, if a connected component has children then it might be simpler not to connect the childeren to Redux but rather let the connected parent drive the updates for its children. Grandkids can be coonected but not their immediate children and so forth. There can be many approaches and every component can still have its own private state in addition to Redux store.
Currently React.FunctionComponents are in fashion and you can use useReducer hook instead of connect though you will have less possibilities to fine-tune for performance with the hook.
Your state in redux store doesn't change, but in order to use it, you should use connect and connect to your store.
If you don't want to use connect,
you can simply pass your states to a child component by props like
<mycomponent data={this.state.data} />
And use your data in your child component
If these ways not satisfying you can read about the context system, but it's parent to the child again, but you can pass data from parent to grandchild without using child
You can read about it here
Hope this helps you.
After a lot of search and working with React and React Native. I still have a pretty vague opinion on which
is best to use and in what situations
Having the parent component be connected to the store and passing as props all data to children functional components. This what I initial though was the "React" way but pretty soon I saw that as the app grow the amount of logic handled by this parent component starting too be to big and messy.Also child components start to have children of its own and so on and so forth.
Having parent component (Screen for example) that is functional and each child that needs information from the store will be connected to it. This is much more "clean" solution but will create a lot of store connection "duplications" which are not necessary.
Using Redux store
My question in general which is more recommended pattern to use and in which use cases, also would be nice to know what is the price for having a lot of connected (containers) components
Not sure i can provide a right or wrong answer for this question as each has its pros and cons.
My rule of thumb is to connect deeply nested components only when their parents are "proxies of props". That is they accepts props only to pass them down to their children.
If i may quote (myself) from this answer:
Avoid connecting components when you can and pass down the props to
the children, the main reason for this is to prevent dependency on
redux. I prefer keep my components "dumb" as i can and let them
concern only on how things should look. I do have some components that
concern on how things should work and these components are mainly
dealing with logic and passing down data to the children, they are the
components i often connect.
When i notice that my app is scaling and some of my components are
acting as a proxy of props (i even got a word for that! "Propxy"),
that is they get props from their parent and pass them down without
using them, i usually inject a connected component in the middle of
the components tree so i can let the "propxy" components down the tree
flow be more lighten and slim
You should also note that one more pitfall with connected components is that each render will trigger the mapstateToProps method. if you got some heavy logic there you should memoize it, usually done with reselect
As for the benefit of connecting a component, well you probably realize that already. you get quick access to the Provider's state via react's context.
Edit
As a followup to your comment:
about the rendering - wont I have much more unnecessary rendering if Ill have a deep nested children (common in medium to large apps) that will be unnecessarily re rendered on each parent update
Well the connect HOC wrapper won't trigger a re-render if the previous object of mapStateToProps is the same as the current object returned. so no unnecessary re-renders to your connected component will take place.
You can read in more details on how it works and how the logic was evolved over time in this article
I use the first option.
The cons you wrote are correct, but i think its easier to debug and understand the data flow this way.
Don't connect a component to redux if the current component doesn't use this data from redux and only passes.
If the component uses data then connect to redux.
If the current component uses data from redux and the next component also uses it then you can pass and don't need to connect the next component to redux.
MAIN RULE:
if there is a gap in the data usage chain from parent to child then don't need to pass data from parent to child
connect(parent) (don't use props) => child (don't use) => child (don't use) => child (using) - better to connect last child. Isuue related to props dreeling
I have some trouble with component communication. Lets say I have 3 nested components.
Parent {{component-a}} -> which has child {{component-b}} -> which has child {{component-c}}.
How can I access component-c directly from component-a, if component-c is not rendered.
Is this even possible.
Thank you
Ember uses a data down action up pattern. This means that if you want to send data from a component to its child you pass it by a parameter, but if you want the opposite direction you should send an action with the data. And when you have 3 components you pass by the one in the middle and this one will keep on relaying the information.
You can find more information here
You'll generally want to use a service for communication across different trees of components or for 'sending data up from a child component'
Services are very easy to test.
Using data-down-actions-up would also work, but beyond a couple layers is known as prop drilling. Prop drilling makes components hard to maintain due to over-inter-connectness
Hope this helps!
Im using Vue and Vuex in my application and I have some components. By the time passing I know I will probably have a few more which is gonna be a lot. So I have a problem with sharing the app state within all the components. So I'd like to know which way should I follow? Either passing the state to all the components no matter child or parent, or passing the state to a parent one that will be used in some of its child components and then passing the state to them as a property (however, I do need to import the mutations methods because props are not reactive)?
UPDATE:
Keep in mind though that if a component is going to be displayed or hidden and the conditional statement v-if is attached to the component custom tag, each time the entire component is going to be rendered again! But not if statement was only on some child tags in the component.
Thanks in advance.
What you are asking is a false dilemma. From the official documentation:
By providing the store option to the root instance, the store will be injected into all child components of the root and will be available on them as this.$store.
(emphasis mine)
Which means that sharing the store between components no matter how deep in the component tree is handled for you automatically by vue and vuex.
It's quite opinion based question, but I would say it is much better way to use Vuex since the beginning if you know that your app can be developed into large scale.
Passing states from parent to child all the way etc is not good way, so it is better to use Vuex now and you will save a lot of time changing your app in the future when you would have no other way than vuex.
The following is from an issue I posted on EmberJS GitHub, but Stack Overflow is better suited for a discussion than GitHub.
I am building a few complex components at the moment including composite components and I hit a roadblock with the extreme isolation components live in.
There are several cases where I don't need the components to trigger an action on a controller, but where a controller needs to trigger a behaviour change on the component.
Problems is that the components don't know about the controller and the controller is not creating the components either: they are defined in a template.
I kind of solved the problem by subclassing the Ember.Component class to offer a way for messages to get through components.
The new component subclass breaks the on purpose isolation of components that shouldn't know about the outer controller.
The 2 less invasive options I found to make component methods calls from outside are:
Cache component / name of instance pairs in a global array like
App.components, then call a component method with
App.components['name'].method()
Trigger events from outside, register and handle them in the
components. However in that case I am passing an eventSource object
to the component, often a controller like so: {{my-component
eventSource=controller}}
My question is about how could we solve this problem in the most elegant and less invasive way possible for components ?
For achieving composite components, using the components like lego pieces, it seems impossible to me at the moment to see how we can achieve that goal without breaking the components isolation.
Any input, ideas, solutions, discussion is very welcome.
Note: By the way, the first method that breaks the component isolation is inspired by the work done on the ember-bootstrap components: https://github.com/ember-addons/bootstrap-for-ember
The author had to solve the same problem of being capable of triggering methods inside the components from outside.
Another note: Just for the record, another way to access a component is to use Ember.View.views['name'] where name is a view name you gave to your component. However I feel dirty to make such calls, even more from a controller.
In general, I would try to solve this by binding properties to your component, which could then change according to computed properties or observers based on those properties.
For instance, instead of trying to call a method like deactivate on a component, bind a property such as active to a property in the template:
{{my-component active=formEnabled}}
I'm hesitant to recommend passing an eventSource to components as a general solution (like your {{my-component eventSource=controller}} example). I imagine this could work with a class or mixin that just emits specific events and is tightly coupled with your component, but I'm struggling to come up with a use case that justifies this approach.