I'm coding my resume and built components for the various sections and they're singletons (there is a single section for job experience, a single one for personal information, etc.).
Each of them have data that is rendered by them (e.g the JobExperience component renders data from an object containing informaiton about my previous jobs), and that data is associated with the components 1-1.
My question is: is it a good practice to put the data inside the components, or is it better to send the data to the components externally? In my case in React, it's either passing the data via props or having it as inside the component file.
I was advised by a professional developer to put the data inside the componentsr, following the smart somponents practice.
Related
I'm learning react and having some trouble getting my head around some code design. I have a Session component that has several Activity components in my project. In the Session component I also have a Timeline component and I need to show the total duration of all of the events. So I need to have the start time for each of the Activities in the Session component and the end time of the last. I know of "lifting state up", but I find it a little strange in my OO way of thinking from C++ to store the data in the parent and not where it "belongs". What if I later need some other data from the activity.. Then I would lift parts of the Activity data up and store some of it in the Activity.. seems quiet messy?
I thought of also having a ActivityData object and store a list of them in the Session and pass that in to each of the activity to display it there. Another way I thought about would be to have a SessionModel object and a ActivityModel object and have this seperate from the component all together and pass these models in for rendering in the component.
I am also just getting into typescript and moving my code into that. I was thinking that I could define a custom ActivityData type in the same file as the Activity component and still store the list in the Session, but then at least its more explicit that the data belongs to the activity.
What is the right (or React) way of doing this?
You are right in your thinking and yes it isn't necessarily an OO way of doing things but more of a functional programming approach
Each component can have state, and it should store that state in it's own component. If that state is then needed by another component you can pass it down as a prop. However, if it isn't a child component that needs it then like you said you should lift state up.
The next problem happens when your app starts to grow. So then you need to make some choices. You should split your components up so they don't get too big. You can have some more logical components and then have some presentational components that don't handle logic but essentially just take props and render the views from you.
However, your app is still growing so at this point you might want to invest some time in introducing a state management tool to your app. React has the context
api built into so you can use that. or you could use a library likeredux. Redux is particularly good at abstracting state to a "global" store and you each component can "connect" to the store to access the state. Really good for apps where you have lots of shared state and lots of components need to know about similar pieces of state
In terms of Typescript then it's certainly a wise idea to include that as the language is heading that way. You can keep types in the same file or keep them in the same directory but have a .types.ts file that you import into your code and declare your types/interfaces in there
I'm working on a large project built with vue. We are using vuex as the state management system but their are some components where I don't need to access their data anywhere else. So, Is it right to store this data in the component data or stick with the convention and store it in a vuex module.
Thanks in advance.
You need to use Vuex store if the data must be accessible by multiple (independent) components. There are several reasons why you shouldn't store everything in Vuex store.
First things first complexity! If you are building a complex Vuex store you can not use effectively as your project grows.
On the other hand if you're filling your store with unnecessary states, all the states will executed in the first load in the initial JS and the more data will increase the payloads and that occurs longer load of the webapp.
So the best thing what you can do it is keep your local states locally until is it possible, und use Vuex when the communication of independent components is needed.
You can keep data with in your components. You can convert your non data sharing components to Functional Components link here.
Vue process functional components faster than normal one. By converting to functional one you will gain some performance boost.
It is totally fine to keep data with in the components if you don't need to access it globally.
When you create more than one Function Components, You must create keys for them too. You can find the whole conversation here. I gave all the details there with code samples as well.
ENJOY CODING....
I have read Redux doc and found out it is like the only way to share data between components, globally, and it seems like it works like on top of contexts.
The question: Can I use Redux Store for data I do not need to share across the application, like, items list got from the network, etc?
What is the best case to use Redux Store?
P.S. Edited the question about Angular as is cannot create a new one
You are mixing up Angular terminology and methodology terminology.
MVC (standing for Model, View, Controller, not Module, View, Component!) is a methodology, which divides an application into three concerns: business logic, presentation logic, and what glues them together.
Within this terminology, an Angular component is a marriage of controller and view: a template that shows how a component should look, and code that specifies how a component should behave.
When I'm sharing data among components should I call that data only once and provide it as #Input() or should I call that data again on every component's cycle?
For example, I have the following components in one page:
<game-info [id]="params?.id"></game-info>
<game-leaderboard [uid]="auth" [id]="params?.id"></game-leaderboard>
<game-progress [uid]="auth" [id]="params?.id"></game-progress>
Where I get the id from the ActivatedRoute and the uid from my authentication service. In some cases, I'm also passing a data input for multiple components in the same page.
One problem I face is that, sometimes, I'm passing data to many children components and it was harder to debug. For example:
game.component.html
<game-details [data]="data"></game-details>
<game-progress [data]="data"></game-progress>
Then, on details.component.html, I'd pass data as an input to another component - and so on. It became a really long chain:
<game-info [data]="data"></game-info>
<game-players [id]="(data | async)?.$key></game-players>
Is it a proper approach? Or would it be better to get those parameters inside of every component?
Another issue, for example, sometimes I need to get the an async parameter (e.g. uid from an Observable) during onInit but it didn't receive it yet. So, I was wondering if I should just call those parameters straight in the component instead of passing them as an input.
PS. I'm not sure if this is off-topic. If so, please feel free to remove it.
Nothing wrong with that approach. Actually, this is 1 of the recommended ways nowadays where your top-level 'smart' components would gather the data and then inject that data to your 'presentational' aka 'view' aka 'dumb' components. Note that data also flows the other way around: all Events are emitted upwards, where they are handled by the containing 'smart' component. See here for a good (better) explanation.
I must say this approach has been working very well for me: code is clean (clear responsibilities, reusability and testability of presentational components...) although I must admit I share your concern that it might become a bit tedious when you have quite a lot of nested components.
A common approach would be using it as a Injectable service.
For its benefits, as it says:
The component can create the dependency, typically using the new
operator. The component can look up the dependency, by referring to a
global variable. The component can have the dependency passed to it
where it is needed.
For angular 1, check https://docs.angularjs.org/guide/di
For angular 2, check the first answer in What's the best way to inject one service into another in angular 2 (Beta)?
It is hard to answer the question since I am not sure exactly what you are trying to achieve but it might be worth looking into services. Services will have one shared space for the components under the component it is declared under(example the app.component or even app.mudule). Then you can pass the new parameters to other components through the service. That would be the proper way of having a shared state and you can pass through many components by just injecting the service.
I have a dropdown <select>-based component that I'd like to be able to drop into any template in the hierarchy of my ember app.
This displays a list of all the Articles (the model) on the site. Whenever I use this component though, the route that I'm in needs to load the data and get passed to the template.
Question :
How can I load this data once and only when the component is rendered?
Also I've been reading this and still have yet to come up with a good solution. I'd like the component to provide the data source, but that seems to be frowned upon.
Would it be terrible to just do an ajax request in my component pre-render?
If you are going to need data preloaded then you can use the initializers to do that for you. You can use this data and inject to any controller , route or all of them if you want. This is a more maintainable way.
For your case you can have a particular controller have articles injected into. Then use this controller data using needs in other required controllers and thus into components.
In this way you have data available for all instance of component. Passing an store object inside the component is mostly an anti-pattern ( depends upon use cases though ) .
Component should be free from headache of data gathering and should focus on logic and presentation.
If want to know more about how to use initializers you can find it here