Let's say I have this blog app. There are posts, pages, menu, and user login.
One way to load the entire application state is to have one api call which will include posts, total number of pages for pagination, menu items and current user state.
The second way would be to have multiple API called, one for each component. So one call for posts and pages, one for menu and one for current user.
Which would be best strategy given the fact react is built around components?
I'll add my 2 cents as answer but still wanting to close as primarily opinion based.
The way I structure my React apps is to have a top level components called Screens or URLs, ie., /list-users should map against the ListUsersScreen component.
In said screen I declare a static method called fetchData, this method returns an object which values are Promises.
{
users: fetchUsersAction(),
someOtherApiData: fetchSomeOtherAPIData()
}
This lends well to both pure client apps and universal apps, as well.
On your server side you'd have to wait until all Promises resolves until you can render something.
Furthermore you can easily cache the values in your application state object and decide if you want to fetch new data or render stale data, also it saves on bandwidth for your user since the user might or might not decide to continue browsing your site.
Related
Within my app there are multiple pages that display a drop down of "clients". The select options are loading via an GET call made in Axios. Every time a page is displayed it makes that get call.
I'm curious if it's better to store those clients in Vuex, and then just load them that way so I don't make a call every time? The only thing I am concerned about is when a new "client" is added the best way to tell the app it needs to make a new get call to update the data in Vuex.
There are many possible solutions to this.
You could use a cache in back-end suchlike Redis, or as you said, cache it in the front-end.
You can abstract this caching with a get function which will check a maximum threshold of cache age.
For example, you can set it to last for 15 minutes. If another request is made before it you could answer with the last obtained data, else it will request the data to the server again.
I'm very new to React + Electron. I'm wondering where most people store basic, component-specific state.
Scenario: I have created a custom component. Basically a type of table. The relevant bit of this table to the question is that I allow users to show/hide columns, or even modify the column order.
I'd like these 'column settings' to persist even if the user closes and reopens the application.
No other part of the application is interested in the column settings. They simply affect what is shown in the custom table component.
The underlying data model is not affected by these settings.
I've looked around at a bunch of solutions. Most will probably work, but not sure which is appropriate.
Redux: I could store these bits of component state there. However, the Redux docs give the impression that it is more targeted towards storing global app state. No other component in my application cares which columns the user chose to hide in this table. Thus, it would seem like a gratuitous use of Redux, when this probably should be something handled locally in the component irrespective of whether Redux is present or not.
Localstorage: This would probably work. Main concern is if the user decides to run multiple instances of the app. There could be a vanishingly rare race condition if both instances decide to save the column state at the same time. I don't consider restricting app instancing a proportionate solution just for something as trivial as these columns settings.
electron-store: Says it does atomic writes. But what if I want to use this component one day outside of electron (say in a web app nb: this is very low priority consideration - i'm very unlikely to use it outside of electron)? Should I tie the component to electron just for this? Also, is using ipc (since e-s lives in the main proc) to save trivial settings like this overkill?
What do people do for this?
I have an app and its going to have these features in it :
SCREENS :
Home { Show recent posts from all categories (API provides 30 posts per page)}
Categories {Show all Categories List }
By-Category {Show recent posts by category (API provides 30 posts per page)}
Post {Show Post Details with Comments }
User-Profile {Show User Profile with their recent posts (API provides 30 posts per page)}
Profile-Setting {Show updatable Fields and Update Button}
Now, Where i am confused :
Should I fill the whole store with API in the starting or should I
make API calls for each screen when they are opened ?
And for updating, like If user likes post then should I show a
spinner or something till API completes OR should I update the local
store value instantly and then call the API ?
There could be many approaches to solve this. mine is:
1) I would create a model/manager to handle the API requests that also have access to the same store. so for example when the screen did mount use Home.Manager.getNextPage(); and it will know already to handle the api request and also know how to handle the paging.
So all the calcs will be in the manager. and when it get the data it will update the store with it.
2) When I built an app that contained likes I have used local data as well. My approach was to set time out of 10 seconds from last like so in case the user liked more than one post I could send a bulk. so the server won't need to handle multiple tcp connection but one with multiple likes data.
The point was first store it locally(for incase the user kill the app before we update the server) and then wait for 10 s' if got new like add it to the data array and wait for another 10 s' if not just send the data to the server. do not clean this local data until server return that it saved on your db
This way you can display animation first without letting the user to wait for a feedback from the server..
The best practice is to make small API calls for each component.
You should load each screen with a loading, then call the API in
componentDidMount after receiving the response shows the data.
enter code here
For this kind of action, first, make the API call, make the like button disable, update the store after successful API call.
Disable the button because of some user double-tap. This kink of APIs is usually fast, so loading does not have a good UX. The loading will be removed before full animation. Always update store data on the response, not the request because you need to revert the store changes if the API calls failed.
I'm new to react-native and redux and I'm creating an app that consists of a survey page and a main page that would display other users depending on how they answered the survey. I use firebase to take care of user authentication and to save the results of the survey and redux to handle the state. I started with hardcoding each question and input field then each question has its own action and reducer to update the state on each change from the user (such as typing a letter for the first/last name field).
The survey component has grown to a point where I was considering using firebase to store all the questions and answers and having the component fetch the data then generate the survey. However, since I'm using redux I'm not sure what the process is for dynamically creating actions and reducer or if that would even be a good option. My thought process for using redux was that all my pages could grab the data from the global state since they aren't connected through a parent/child relationship and I use react-native-router-flux to navigate between pages.
TL:DR: I want to store questions and answers to a survey in firebase and have my component fetch the data and create the questions but I'm not sure what the best practice is for saving the state if I want to use redux since I want other pages to have access to this data.
I'm using Vuex & Vuejs (flux architect) for a CRM single page application.
In contact page i'm showing a list of tasks related to current contact and at sidebar i have a list of task for current logged in user.
These collection of tasks are kept in separate stores. I don't know which is best solution:
After update post request search in both list and update task object if it's present and mutate state.
After update post request use an global event bus and each store should listen and update task object if needed.
It really depends of your requirements, but one thing I can tell is that using two separated stores + bus is defeating the whole purpose of Redux.
If the tasks in your application share the same scope and can be assigned to you or other users that you may be visiting/managing, you can have all the tasks from your scope (your team, for example) and display it on different places using different getters with Array.filter functions.
If the number of tasks is too big to have it all loaded, I'd approach it doing one single tasks list in the store, being populated from a single url.
ie:
- Give me all the tasks I have + the tasks of current user I'm managing
- Give me all the tasks I have + the tasks that matches this search
Although this can get messy if the requirements are more complicated and can get confusing. But try to structure your application with one single store if possible and avoid bus, as it is only recommended for small size applications.