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.
Related
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.
In the app on which I'm working I use a REST API with
Angular 1 on the frontend. I use the extendModel function of Restangular in order to initialize the data that I receive. During the initialization phase I create a lot of cross-references and the object becomes cyclic. Here comes my problem. In order to put or post my data back to the server I have to either copy the object by picking just the fields that I need or I can work on the same object and delete all the references that I created and restore them when I get a response from the server. I feel like these 2 options kinda go head-to-head with the intended usage of Restangular. Is there a better way to do this?
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.
I am trying to use Ember data with already built REST api. It works fine for top level routes, for example I have route for courses on api side like following:
app.get('/courses', app.controllers.courses.findAll)
app.get('/courses/:id', app.controllers.courses.findById)
Above works fine and I can easily get data with Ember Data. But problem arises with routes that have multiple levels. For example, courses can have multiple topics and topics can have multiple lectures so routes for them are defined like this on api side.
Topics:
app.get('/courses/:course_id/topics', app.controllers.topics.findAll)
app.get('/courses/:course_id/topics/:id', app.controllers.topics.findById)
Lectures:
app.get('/courses/:course_id/topics/:topic_id/lectures', app.controllers.lectures.findAll)
app.get('/courses/:course_id/topics/:topic_id/lectures/:id', app.controllers.lectures.findById)
So if I want to get all lectures inside a course I need to specify course id and topic id as well (not in the query but in url body, as you can see from url structures in backend api).
In Ember I have models for course, topic and lecture but I dont know how can I specify custom urls so that Ember Data can use those urls when I make requests.
One way could be to manually make ajax requests but this way records will not be populated in Ember Data Store.
Or I could have defined relationships between models in Ember but that would require changes on backend api also which is not an option for me.
So is there any nice way to solve this problem?
I am using:
Ember: v1.6.0-beta.2
Ember-Data: v1.0.0-beta.7
Avoid Ember Data, Ember works just fine without it.
If you really want to use it, make ajax calls then use store.pushPayload('type', data) to sideload the data into the store if you really want it in the store.
I read many Backbone.js tutorials, but most of them deal with static objects.
Of course, I have data on the server. I want a tutorial that shows how backbone.js can communicate with the server to fetch data, post data, etc.
This is .sync, right? I read the backbone.js documentation, but still fuzzy on how to use this feature.
Or can someone show me an example?
According to: http://documentcloud.github.com/backbone/#Sync
Backbone.sync is the function that Backbone calls every time it
attempts to read or save a model to the server.
But when? Where do I put the function? I don't know how to use it, and the documentation doesn't give any examples. When does the data get loaded into my models? I get to define when...right?
You never really have to look at .sync, unless you plan to overwrite it. For normal uses, you can simply call model.save() whenever you want and that will execute a post or put (depending on whether the record exists already). If you want to get the data from your backend, use collection.fetch()
You'll of course also need to specify a URL, do so through your collection attribute, collection.url
You can override Backbones native sync functionality if you override it:
Backbone.sync = function() {
//Your custom impl here
}
After that this function is called whenever you call a backbone function like .save() on models or .fetch() on collections. You do not have to care about data transport anymore.
I would suggest taking a look into Backbones source and look how the default sync function is implemented. Then create your own or adopt your server to support the native function.
They are not free, but the following screencasts both have a piece on backend work and how to send data to and get data from Backbone.
Tekpub is a 9 part screencast about asp.net MVC3, with the whole 6th part about using backbone to write an admin module to manage productions. it shows all about handling routing in MVC3 and sending & receiving data
Peepcode
http://peepcode.com/products/backbone-js about basic backbone stuff
http://peepcode.com/products/backbone-ii about interactivity
http://peepcode.com/products/backbone-iii about persistance (it's this third one you will need for server connection information).