Lets say we have a basic shopping app with a shopping cart, whenever the user adds an item to the cart a request is sent to the backend in order to persist the shopping cart.
I am contemplating between two approches to this achive this.
The client sends the updated shopping cart and awaits a response from the backend, only after the requests completes the shopping cart is updated to reflect the change, if the request fails an error is shown instead.
When the shopping cart is updated on the client the change is reflected immediately, then if the request failed an error is shown and the state reverts to before the request.
The advantage of the second method is that the changes are instantaneous while the first method has a response time, but the second method might confuse users in the case that a request fails.
I am wondering which method is better, or if there is a better way to go about this?
Is there an industry standard for this problem?
Note: I am working with react / nodejs backend in case this is relevent.
Related
Consider this scenario: Liking a post
When a user likes a post, I want to instantly show the post liked without waiting for a response from the server, instantly update the post's like count, and also display the total count of the user's likes on their profile. That's updating the post entity, postLike entity, and the user entity all in one action.
I care about showing the post liked and the likes count instantly, but don't care about the user's total like count on their profile right at that moment.
The problem
In some cases, the post likes should be shown for a specific user on their profile, while other cases not. There are other limitations and edge cases like this.
I also cannot split the above action in to separate actions to, for example, load the user's likes on their profile when it is mounted.
I have 2 options here:
Put the logic of updating each piece of state in Redux
Offload what isn't critical to the server, and use that response to update the state
Option 1 means having many reducers that have to have the logic in place to deal with the instant updates. So this means putting and maintaining business logic in the frontend.
Option 2 means leaving only what is critical to Redux, and offloading much of the rest to the server, and have the server return the appropriate response with the correct data.
Example
In the above scenario, it's either manually add the postLike, update the postLikes count, and update the user profile in Redux. Otherwise, it's updating only the postLike and the post count, and waiting for the server to respond with the updated user that has the updated count, and have one general reducer take care of updating the entire user.
It basically comes down to having this logic in the frontend or backend. Neither is right nor wrong, but I would like to hear some advice from others on the matter.
What would be a good strategy to take here?
For 3 months I have been learning about React-Redux. Really Redux is very good idea. While I am reviewing about the redux, I got my opinion that Redux seems to be a global variable which is defined as STORE. So on React-Redux application, every component, every custom hooks and others can access the global variable STORE to get and set.
By this thought, I believe that I can reduce the Ajax calling times.
For example, Let’s suppose that there are 2 pages such as users page and rooms page.
users page will display the user list, and rooms page will display the user list in each rooms.
users page (One ajax calling)
#1. getting the user list
rooms page(Two ajax calling)
#1 getting the user list
#2 getting the room list with room-user relation infos
before, whenever the page is loaded (componentDidMount), I made the users page and rooms page to call the ajax for getting the data.
But I would like to call the ajax only one time with Redux. So at only the first time of page load, the ajax call will work.
I think that it is possible with Redux, because Redux store is working as a global variable.
But I have a problem with this idea. The problem is Data sync.
Let’s suppose there are 2 admin users (Admin#1, Admin#2) who can edit the server data.
Now I logged in with Admin#1, and I visited the users page and rooms page. So the user data and room data will save on the Redux Store. After that, the ajax call never need for users and rooms data.
But at this time, Admin#2 added/deleted some of users.
At this case, how can Admin#1 get the synced data?
I think that the websocket seems to be good solution. But websocket function for the whole web app is very difficult.
So what is the best solution for my problem?
I think you can try socketio. When a client delete/add new user, it will broadcast an event to other clients (webapp). You just have to implement a static socketIO client and exports all important functions (also think about callback too) so that you can import and use them in your components
What is the best way to solve problem like this:
we got paginated results on our page (for example, 10 blog posts)
we click LIKE button on some post
how to update new state of page using Laravel & React?
Laravel doesn't support pagination with POST request. Should we send another GET request to refresh our page's state?
Laravel doesn't support pagination with POST request
Pagination are meant to be used in GET request so this has all the sense in the world.
When you make your POST request to update the state of an object (in this case, to like a post), the task should be to persist the change of the state. This shouldn't interfiere with how you refresh your view in order to update the state (visually).
My strategy would be like this:
The user get the list of posts: GET request of paginated list).
The user likes a post: POST request to the endpoint that handles this. This won't affect your view. You just have to make sure to get a success response (for example, a 200 response code from your endpoint).
Update the state of the object "visually": Given the fact that your server has responded that the state of the object has been persisted, you could just mark the post as liked visually, this means apply some classes/CSS to the button for example.
When the user change of page, or refresh the site, your server will send them all the objects refreshed, so this means that your updated object will have the correct state.
I wanted the list of users to always be in sync with the MongoDB database,
I created an action that dispatches a refresh call to refresh the list of users.
What I have right now is an interval that dispatches the refresh call to refresh the list every 1 second, but I think it's a little hack to do that.
Is there a better way to refresh my list and re-render them through my React views?
What you are doing right now is okay but is expensive, specially if your browser tab is not active (please note that setInterval/setTimeout get less priority by browser if the tab is inactive or minimized).
You might need to explore using RxJS which has the capability to create periodic caller functions and you can subscribe to it in your react view.
Example - https://www.learnrxjs.io/operators/creation/interval.html
I'm learning React and Flux and there's something that bothers me about all the examples I've seen so far.
They all are pretty much a CRUD UI.
In them, they always fetch all the data after every change (update/add/delete etc.)
So let's say, we have a todo app, and the user added a new todo item.
In a response, the store will get an action, call some API in the server to add the item and then fetch all the items again.
Isn't that expensive?
I understand why it makes things simpler which is good. But, why not add the item to the store's state. I understand this makes it so you always have the keep the store and the data in the server synced like that but it's not as expensive.
One solution I saw was pagination but in the example they would still get all the items for the new page every time a user changes it.
Why always fetch all the data?
If we use pagination - would we get the new page from the server every time a user changes pages?
It is not necessary to get data after every change. In the apps that I have built, I have always changed the store rather than get all data.
In only one project which involved DreamFactory API, we used to refresh the model (only that model/item) after an update. That was necessary because DreamFactory API pulls all the related data in a single call.