We are in the middle of migrating a fairly complex web app over to a React/Redux architecture.
One major design question i have not been able to find an answer for, is how is data stored in redux supposed to be 'refreshed'?
For example, say i load a list of items at a route like /items. Now the user wants to view a specific item and goes to /items/<id>.
The flow, as i understand should work something like, on the /items request, we make a API request and store all our items in the redux store. When a user clicks on a specific item, we pick out that specific item from our redux store, not needing to make a new API request as we already have the data.
This is all fine & well. But the question then, is what is the correct pattern for 'invalidating' this data?
Say, the user loads the list of items and walks away from there computer for a few hours. Now the list of items is theoretically out of date with the server.
How does one then, go about keeping the store up to date with the server?
You could use one of the following:
1) short polling (i.e. polling your server once in a while and update the store items)
2) long polling (you open connection, keep it until the data on the server changes, the server then sends you the new data and closes the connection, you reopen it etc...)
3) live updates with websockets, which provide bidirectional communication (this means the server can push data to the client)
Is it when the state changes, react will automatically rerender the component, this might not what you want, but what do you mean by the correct pattern for 'invalidating' this data? like 30 minute it will dispatch an action checkout the state change?
Related
I have a project for food ordering and deliverying. Basically this is a concept of project:
User order a food in some restaurant
That order of that restaurant is showing specifically to the manager of that restaurant
Manager is getting SMS notification about new order
He needs to refresh his dashboard to see new order
The point is in the last step Manager needs to refresh his dashboard to see new order.
I'm using livewire and Laravel 7 framework, is there any way for the manager to get new orders in realtime?
I know for livewire polling but I don't want to use that because it can cause server problems in large quantities of using it. Is there any other way? Something like mount() function or emit ?
I've never used this feature but it seems you need broadcasting
In many modern web applications, WebSockets are used to implement realtime, live-updating user interfaces. When some data is updated on the server, a message is typically sent over a WebSocket connection to be handled by the client. WebSockets provide a more efficient alternative to continually polling your application's server for data changes that should be reflected in your UI.
I have a web application with the following flow:
You are in Investments screen, when rendering it makes an API request to some server and then the response comes as an array of investment objects. Then those objects are displayed as a List in the screen. The user is able to clic on one item of the list to get redirected to the Investment Details screen. The investment details screen has two components who need the information of the current investment to display some charts.
The redirect is handled by react-router using the ID of the investment as a URL parameter.
I was wondering which way could be the best to using the information of the current investment.
I mean. I can redirect the user from Investments to Investment Details and then use the URL param to make a request to the API to get the information related to that investment and then pass it down to the child components, or pass directly the information of the investment selected by the user from Investment to Investment Details as props and the same from Investment Details to its child components.
Am I getting into prop drilling?
Is another call to the API unnecessary in this case?
Thanks in advance.
You got to use both the approaches together for different reasons:
Passing the data already available to next pages. This can be done using state management library most popular one being Redux. This saves you from making another xhr request unnecessarily. Also the data is readily available to your user and the chances of user sticking to your product is much higher when there is no delay is transitioning between screens.
Now assuming you are on the Investment detail page; the data we stored in redux on page 1 will be available as long as user stays in the same app and does not refreshes the page as doing so will reset the store to the initial state. You could persist it in local storage but that's your call based on how sensitive the data is and how big is it. If you decide not to store the data, then you could fetch the data for only that particular investment based on the ID available in URL.
I have a languages table in my database.
If the admin wants to add a new transport (which has to be translated), I fetch those languages from the database, loop through them, then let the admin fill the form n times where n = number of languages in the database.
My friend says to use Vuex store so whenever an app launches it fetches languages and saves them in the Vuex store. Then, when an admin changes the route and goes to adding clothes (which need to be translated too), the app doesn't make the call again to show the admin n-th time fillable form.
When the app is launched, let's say we saved 3 languages in the Vuex store and the admin spends 10 minutes on the same page. When they change the page and decide to add clothes, what if in this 10 minutes another admin added a new language?
When the admin changes the route they will get 3 languages and not 4. He says it's good because no need to create a database call, also all the code will be in store at one place (fetching languages, adding languages, editing languages).
How does Vuex handle this scenario where the admin won't see all of the languages?
Vuex can handle this scenario just fine; it is an app state and data management tool constructed to handle frequent, or not-so-frequent, updates. You are right that Vuex data can fall out of sync with remote data that it is supposed to represent, but it is your job to decide if you want the admin to have, essentially, a live representation of the database, which requires frequent API calls to check for any updates.
I am a frontend guy, but I am working on a project in which I need to process lots of data in my nodeJS backend (my front is reactJS).
But once the data that needed to be processed in the backend is processed, I have the choice of either reprocessing this data in node or in react (knowing that in the end, I need this data in frontend).
Example: An array of links has been created in my backend, but I need to extract a single link from this array, in order to display it in React. I have the choice, pass the array to react and process the data there, or do it directly in node.
Is there a common fashion to fix this dilemma? What should I take into account to make a decision?
It's not good to send excessive information from your backend to your frontend. If you're going to send data to your frontend from your back-end and a lot of it isn't going to be used, then it's probably best to adjust your backend so that it only returns information that's going to be actually used by your frontend.
Alternatively, if your frontend isn't going to use all the the information sent by your backend right away, but potentially might use it later (based on user input), then it's better to send all the data from your backend and process it on the front end as needed to avoid making future requests to your backend.
Taking an array of links as an example:
If the user requests to see a link based on certain criteria, and that's the only link that they are going to see (based on the design of your application), then your backend should process that request and return only the link that your user wants to see to be displayed on the front end.
If the user can request to see a link, but could potentially request to see another link later, then your backend should send a full array of links that might need to be displayed at some point. Then your frontend can display the links at the appropriate time without having to make a request to your backend each time the user wants to see a new link.
In my opinion, if the logic doesn’t need to be done by the browser, then do it on the server. It will help you with reducing the size of your app in the long run. You want your final, bundled .js file to be as small as possible. That’s just one small step you can take to contribute to that.
The short answer is that it all depends on your business logic. Regarding how best to handle an array of items to be sent from backend to front-end, if a user will only ever need to see this one item, for example, then by all means, have the backend parse the array of data on its end and send that single item to the client front-end. If, on the other hand, you anticipate that you'll need to work with an array of items to be presented to the user at some point in the app, it would be reasonable to simply have the backend send the array of items. Furthermore, that array of items could be, for instance, a filtered version of the items that would be relevant to this particular user.
I'm building an app that uses Angular.js for the front and Socket.IO & Redis on Express on the back.
The base usage of sockets is to allow one type of users to push items to lists that are consumed by groups of a second type of users.
A simple example:
Students can push messages into a class list and only teachers of this class can see the list.
I'm trying to sync the list between multiple teachers that are connected at different times,
the lists are stored in a Redis store and I'm wondering if the correct approach to sync clients:
A. Send the list on each update - saving the need of having to manage sync in the client and having potential missmatches.
B. Send the list only on connection and apply incremental updates on successive events.
I'm sure this has been addressed in the past as it seems quite a basic issue with socket communication but I was not able to find a definitive answer.
Thanks!
If the list is not particularly large, then I'd think you want to go with something simple. The simplest thing I can think of is as follows:
Student creates change to the list and sends message to the server (which could be an ajax call, doesn't have to be a web socket).
Server receives message and puts it into the appropriate list storage.
Server then looks for any clients monitoring that list and sends an update message to them.
Teacher connects to the server. Any lists that the teacher is monitoring are sent in their entirety to the teacher and they are subscribed to updates for those lists.
This way, you're never actually doing sync which simplifies matters a lot - you're just doing download list and then incremental updates. There's only one master store. If a client goes off-line, they just get a fresh copy of the list and resubscribe to updates when they come back on-line. Avoiding sync makes the whole solution a lot simpler. This assumes the data is not particularly large so it's feasible to just get a fresh copy of the list as needed.
If you do want to do sync, then a fairly straightforward technique is to maintain one master copy of the store on the server and have every change transaction coin a monotonically increasing transaction ID. Then, each synced copy can just keep track of the last transaction ID that they synced and request all transactions since then. The data store needs to keep track of all changes as transactions (often by writing to a transaction log for each transaction or perhaps a feature in some databases) so any given set of transactions can be played back for any client that is syncing.