I will apply Business rules on my Angular service.
This one is to display news created today only.
I parsed the response of my call like Array<News>.
My question is :
Can I directly apply my business rules in my service? Or I need to apply this in component (after parsing)? Or by other way?
Better would be to perform all complicated process in Service Layer and let Component handle the view ( DOM manipulation, animation etc).
You can have more than one Service Layer to handle different level of task.
Service Level 1 - Handle HTTP Call
Service Level 2 - Parsing and manipulating
Component Level - Display parsed content.
Angular provides you with multiple ways to act here, The most important thing to remember is that Angular is wired with DI, meaning:
You create a service
Register it as a provider
Inject it into a component using the #Injectable decorator to expose functionality between component and service.
There are two ways from here:
One:
You write your business logic in your component, using your service as data transporter - The service will take params, pass it to the server and will return response with params from the server.
Two:
The component layer will take care for the client logic and will only use the service methods, the service will be responsible for the business logic and all the component will do is pass params for the requests, receive params from the response and handle them according to the client's needs.
What is right?
This will depend on the architecture and the course of action you decide to take. Both of them are correct, it is up to you to decide which one will benefit you more.
Related
I guess awake isn't the right word. Say I have a multi-page, large AngularJs application. Is the controller of a page that isn't active right now awake? For example, if I wanted to call a function of that controller with $rootScope.$broadcast, would it be listening for that signal or would it only recieve that signal when I go to the part of the page that requires that controller? Sorry if this makes not much sense.
Controllers have instances per usage, that means that angularJS will make an instance of some controller only if it is in use.
If you need to pass data from one controller to other, the common way is to use some service. As service are singletons which created on the first inject.
So, you can inject a service in one controller (page), invoke some method on it, which will change some data on it, then navigate to other page, in this page, inject the service, and use the data on it.
The question is conceptual, should the dataProvider apply formatting over the data before returning it to react-admin's frontend, or dataProvider must play the role only for data fetcher and must always return the data in the format it comes from the back-end service? What do you think?
What would you do in case you get the data from the back-end deeply nested, in complex structure and you need it simpler for the display? Where would you reduce/format it:
In the dataProvider, right after receiving it from the server and before sending it to React-admin's UI, or
In the UI (a.k.a. Resource view) or maybe
By using a custom reducer: https://marmelab.com/react-admin/Actions.html#using-a-custom-reducer
How is the most elegant and conceptual right way of doing this, in your opinion?
Short answer: you can do both depending on your needs.
This is actually a good question, the answer might be: it depends on the use case.
Firstly, if you are talking of a general data provider related to a specific API format (say ODATA, or GraphQL), it's better to transform the data in the data provider. Even more so if this data provider is open-sourced.
As the documentation says:
[A data provider] is the place to translate data queries to HTTP requests, and HTTP responses to data responses.
That said, if your talking about a specific data provider which is made for your own custom API (or combination or APIs), you can do both: data provider transformations or use custom reducers, or both.
There is nothing wrong to make data transformations in the data provider. You just need to know that React Admin caches the data from the provide in its redux store and does some fancy things like optimistic rendering or undo actions.
We are building our website with react/react-router/redux
We want to server side render our pages that should be filled by the data from our data sources. This transaction has to be asynchronous and unfortunately since we want to server side render, we can not use "componentDidMount" function.
In the redux tutorial page at server side rendering section here, it has been advised to :
If you use something like React Router, you might also want to express
your data fetching dependencies as static fetchData() methods on your
route handler components. They may return async actions, so that your
handleRender function can match the route to the route handler
component classes, dispatch fetchData() result for each of them, and
render only after the Promises have resolved. This way the specific
API calls required for different routes are colocated with the route
handler component definitions. You can also use the same technique on
the client side to prevent the router from switching the page until
its data has been loaded.
This is currently how we handle our data fetch. I personally did not like this approach it looks quite clumsy and it is too coupled to the routing library. Are there any better ways to do it - hopefully with standard react/router/redux components ?
Something like a static fetchData() method is the correct way to handle data fetching with React Router in the general case, though it can reach down into child components as needed (which is e.g. how Relay works).
The reason you want to do it this way is that React Router resolves all the matched routes all at once. Given that, you can then run data fetching for all of your route handlers simultaneously.
If instead you tied data fetching to instance-level handlers on components, you'd always end up with fetch waterfalls, where a component could not fetch its required data until all of its parents receive their required data, and so forth. While that may not be a big problem on the server, it's hugely suboptimal on the client.
If you really want to colocate data dependencies to components, you can consider using something like React Resolver, but this can easily lead to a suboptimal experience for your users.
In my project I have two ng-app's one is for login page and another for home page.
Once login is successful for the user, in ajax success callback I got the some response related to that user and in that callback I am used the window.location="home.html".
As of now I used session storage feature to pass the data to home page.
The best way to do it is by creating a service. The service can be injected into your controllers and other services as necessary.
Create a service and use getter and setters.When you get a response in your first module set the object using setter and get the data using getter in another module.
The best way to communicate between two controllers or say two modules is using services.
According To angularjs examples only one module stands for one project though outof the box you can you can use more than one
but To Achieve this .This Is how i Normally model myproject
**MyProjectModule** (only **one** module)
---> loginController.js (initial page)
(If LOGIN IS Authorised Then Redirect To Desktop->desktopController.js)
---> desktopController.js
---> customerController.js
---> salesController.js
An Ember Component needs to fetch data from serve, however i think put AJAX call inside the component is not a good practise.
Or use the Route to fetch data, then pass data to component.But the route's method can't share easily between different routes.
In general, you are right, it is not a good idea to put ajax calls in components. However, in a case where the data to be retrieved and displayed is intimately connected to the view--auto-completion could be one example--it should not be considered an anti-pattern.
If you think it is important to segregate the ajax call, you could consider using a {{render}} helper inside the component's template, and do the ajax work in a separate controller with an associated view where the results are displayed. Routes are not really relevant here because they are related to navigation and URLs.
A component should depend only on the input that are passed to it.
If component has some internal dependency (AJAX / Other data) for input it is an anti pattern.
Ember way will be
1) Create a Route : (Get data to you application)
Sometime you dont have a route for such data (like in your case). Here you can use application route or any other parent route if have. Use the setupController to inject this data to relevant controller
2) Pass down data to component
Now your data should be a controller. Pass this data like any other to required component
{{my-comp-here data="here" ajaxData=fromRoute }}