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.
Related
TLDR: Is there a way to signal to NextJS to render a component only on the server (and thus only show the pre-rendered HTML on the client)?
Motivation:
The reason I want to do this is because the render function inside of the component in question runs a lot of (synchronous) Javascript. I'd like for this Javascript to not be included in the client bundle. My desired behavior is that this component is rendered once on the server and the generated HTML is simply displayed on the client; it should never render on the client.
Things that I've tried / don't work:
getServerSideProps
It appears that, even when a page has getServerSideProps, it will still send the Javascript code to the client. My assumption is that this occurs because NextJS (incorrectly) assumes that some state update could possibly occur in the component on the client and therefore the client must have access to the Javascript code to render the component in such an event. Perhaps I'm doing something wrong here?
Static rendering
The page uses dynamic from the URL (imagine something like the delivery status page of a delivery website; there are hundreds of thousands of different deliveries and so it doesn't make sense for them all to be statically rendered)
Conditional Rendering based on typeof window
I don't think this helps with my particular issue as I'd like to skip rendering entirely on the client but still show the component as it was rendered on the server
Thanks so much for any and all help!
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.
I have a react contain that makes an ajax request via #asynConnect. Once that data comes back from the server, this component's render method will conditionally render several components. Some of these components have their own data that is required to render their content. What is the best way to fetch the data for each child component? Do I use componentWillMount? Should my parent container dispatch another action that when received will make the subsequent ajax calls? Should I use some type of middleware (redux-thunk)? I've read multiple posts and comments on this topic and still not sure if I've come across a "best practice". FWIW I'm using this project: https://github.com/erikras/react-redux-universal-hot-example
In our codebase, we have recently migrated a lot of React components to a pure flux architecture. Thus, our data flow looks almost exactly like this image provided by the Facebook team:
(source: github.io)
One issue we're running into is that there's a lot of boilerplate code required to make a call to the server and get a result. The process is as follows:
View propagates an action called something like GET_DATA_FROM_SERVER to an action creator (let's say called ViewActionCreator).
ViewActionCreator dispatches this action, which has no payload in most cases, and then calls api.retrieveData
Upon receiving data from the server, api.retrieveData dispatches an action, in this case called SERVER_DATA_RECEIVED with the retrieved data as the payload.
Stores respond to the two actions dispatched. However, in most cases stores only do something for the second action (SERVER_DATA_RECEIVED), since we've found that optimistic view updates are, with a few exceptions like logging in, not usually required or very helpful.
Hence, my question is, is there any reason why we shouldn't have views call api's methods directly, and have those api methods dispatch actions only upon data reception?
Another related issue we're running into results from the use of constants, generated using https://github.com/STRML/keyMirror. We repeatedly run into an error where we forget to add a constant used in an action creator and store to our constants file, but this doesn't manifest until runtime, since our stores use switch statements to test which action they're receiving from the dispatcher, and when we use a constant that's undefined, this simply percolates down to the end of the switch statement.
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 }}