I have a little question about Angular Components.
I often read that you should use components only to display data and interact with the user, and for your "business logic" you should prefer services.
So my question is the following (just an example):
Let's say I have made a component to upload files via drag and drop. I have the logic to get the data from the drag and drop and store it in an array (and maybe much more other functions) inside that components typescript file.
Now when I am including this component twice inside one parent component (because I need two upload fields for example), are both referencing to the same or is also the program logic inside that component created twice for each instance?
If so, then I should try to keep as much shared program logic as possible in singleton services so they are only created once at runtime and not wasting memory etc., shouldn't I?
Hope somebody understands what I am meaning :).
thanks in advance!
If you add the component twice into your parent, then two different instances will be created (each owning unique scope).
You should however abstract upload/handling logic into a service. Provide that service in module to make it a singleton. If you want instance per component, then provide it inside component.
If you create two components in your template which are similar for example:
<app cumstom></app custom>
<app cumstom></app custom>
This will result in two objects being created who both have their own model (data) and view. They don't know anything of each other.
If you want them to communicate it is often smart to use a service which you can inject into both components so they can share the same data. If a service is provided in your ngmodule is will only be created once (so it is a singleton).
Well I think what you need is a smart component, where you can put your boths uploads-component and inject your service logic in this smart component. The smart component will be responsible to provide the bridge of the common logic between the two components.
Related
I have a question that has been going through my mind for a while now. Should every component created be reusable??
Let's suppose that we have some html,css and javascript that can't get reused. For example a CRUD table for a specific product ( for example CRUD of users ) that gets updated through methods and watchers and other stuff. It could be created as a component called UsersTable but then that component can't get reused since it has the methods relative to users management through DB.
So for example, should that component be declared as plain html/css and js inside the parent or should it be declared as a component and emit events in order to communicate with its parent?
I am building the clone of a website/app called Kualitee.com. It is a test-management tool used by QA Engineers.
In kualitee, you have multiple projects, with test cases and members. You can add, delete, and change projects and members. There is a header on top which enables you to select a project of which you want the data of i.e test cases and stuff.
the header for changing projects
The approach I used for this is as follow:
1. one service containing all the data
2. one service containing only the project selected...
The whole app uses the data found in the second service. When I make a change in a project, say add a new member, it does display that at that time. After that, if I change the project in the select at the top to another project, the component containing that member does not change, even though the project is a different one now, but as soon as I switch to another component, through routing, and back again, the changes are there.
My point is, is there any way I can add functionality where, if a parent component changes an object in service, the change reflects in a child component also using that same object in that same service, without me needing to change components or refresh.
PS. This is my first time asking something on StackOverflow, Sorry if my question is confusing.
You probably need an observable shared service to share the data between components. Here is how to achieve that: Interaction between components using a service
I think you are referred to Angular life cycle https://angular.io/guide/lifecycle-hooks
Maybe at official flux website I saw a video were mentor said something like:
Only top-level React views should know about stores. All not top level
views should be dump and receive all information as properties.
Question: Is that right? Your argumentation, please
BUT, suppose you have some small React view Button.react that's reused on multiple pages. And suppose Button.react must know about some store data. If we won't fetch all data directly from the Button.react, we get a duplication of code at each top-level component which reuse Button.react. Is that ok for you?
I hope I am understanding your question.
One of the characteristics of React is its one-way data flow. Each component can be used by another component, just like one function can call another function. Just like a function, a React component should typically be able to get all the info it needs to do work (render itself) from the arguments passed into it. This is the function of props in React. When using Flux, sometimes the React Components, which are typically near the top of the view hierarchy, that actually fetch the data from the stores to pass down thru the application are called Controller-Views.
It is not an enforceable rule that every component doesn't become a Controller-View, getting its own state directly from a store, but it is a general practice for good reason. consider the two functions:
function renderToggleButton( isSelected ){
//... render the button
}
vs
function renderToggleButton(){
var isSelected = StateStore.getButtonSelectedState( id );
//... render the button
}
I think you will agree that the second function is more complicated and difficult to test. It has to know from where it is getting it's initial conditions. It also has to know how to identify itself in the context of the application. These are two things the function should not have to know.
Now imagine an application full of functions like this. If one function is misbehaving, it becomes very difficult to trace its inputs; to test it under controlled conditions. I hope that clarifies the guidance given for passing data thru the application as props.
Where can I put the complicated logics when using reactjs to be easy to test with Jasmine?
Should I put them in Reactjs components?
Should I create a separated JS module and include it to components by props?
Should I put it in Flux store?
There're many ways to share the logics among components, and it depends on your scenario and design. Let's say you have Book state in your BookStore. You need to access multiple APIs, get responses and merge them into a Book state object. The logic you merge the responses could be defined in the BookStore, and every component can use the Book state without worrying about converting objects. Because the conversion logic is only defined in the BookStore, it helps you test the logic easily.
So, if your 'complicated logics' mean how you transform data into state, put them in the stores. If they mean how you retrieve your data, put them in your actions. If the logics mean how you process states and affect the UI, put them in your component. If that logics are shared among components, create a separated JS module.
I have just started to use Flux in my project, but I find it difficult to reuse a component (or have multi instances in different places) when it's complex. By "complex" I mean a component includes some smaller components and may involves some interactions of changing some data. For example, a component containing a list, a adding new input and button.
I can come out with two ways of solving it:
Passing all functions that handling change events by props from
parent, so the component will not know which action is really
called. In this way, there will be a lot functions passing down for
different levels' components.
Passing an 'identifier' object when calling
action. In store it will access corresponding data located by the
'identifier'. This way there is added logic and parameter
"identifier".
I haven't found a best way of handling this, basicly because store and action in Flux are singleton. Is there any more elegant way to solve this? Thanks!