I am creating a SPA using react-redux and dot net core web api.
I am calling get data in the componentDidMount. I have search functionality as well to implement. So i can do a real time search or search in the redux state that we fetched previously.
Is there any way for the application to be notified about any data changes on the server so that the state data can be up to date?
What is the best approach for such scenario. I need to implement ticketing system as where tickets needs to be updated so that if a ticket is picked up by one user, it should not be visible to other user.
Related
Data usage really matters for my targeted users. So, I am looking for an APPROACH that'll help me reduce the number of data fetching during react rerender cycles in React and React-native App.
Let's say I have a page that renders all the Items fetched from an API. Since the API's data can be updated at anytime, I am obliged to re-call the API whenever the user displays this page.
IS THERE ANY WAY FOR ME TO KNOW THAT THE DATA HAS BEEN UPDATED WITHOUT BEING OBIGED TO RECALL THE API?? Because I think that the less HTTP requests I send the less mobile data I consume (Maybe I am wrong... I don't know)
I thought of implementing a solution with Redux and Socket.io :
I wanted to prepare an event called data-updated that will be managed by socket.io and whenever one of the users performs an action that updates the item lits (The API data), the data-updated event will be triggered and all the connected users will be notified. Then in the data-updated event handler I will update the item list state slice in the redux store.
My worry is that since socke.io keeps the connection between users and the server alive during the whole session, Won't this approach consume even more Mobile data than recalling the server at any rendering??
You can proceed with graphql with mutations and its caching mechanism, its pretty cool and if I mention if it is handled efficiently you can run your application in 2g network also with speed. Checkout its usage and advantages over REST you gonna love it. https://graphql.org/
Another way is by using redisCache but personally I've not used it though you can check.
You can use React-query lib for data fetching, updating, caching etc.you can read more about it but read its docs.
https://tanstack.com/query/v4/?from=reactQueryV3&original=https://react-query-v3.tanstack.com/
I am currently working on a MERN stack application with a React Redux front end. It is an job management system with a calendar showing booked in jobs/events.
I have a question regarding best practices around making API calls and loading data into my app. The database is small scale at the moment so a small amount of data is loaded into my Redux store.
When is best to make GET requests to load my data into my app and handle changes made by other clients? Do I load all data on each page load? Is there a cleaner/more efficient way to do this?
Any help/guidance is much appreciated, thank you
From my personal experience, I believe that if your application will be accessed by different users simultaneously, you could GET the calendar data when a user first accesses his calendar and whenever the user is going to add a new job/event. This way he has access to the latest data before creating a new event. Also when creating an event, if the API returns an error because there is a collision between events you can update the data on the FE. This would be a lazy approach and it wouldn't keep the calendar constantly updated.
If you need data to be fresh you could also set a timer and execute GETs periodically.
I've taken the program at Udacity for react and react native, and it taught me well id say.
Now that I am equipped with the skills and have a good knowledge of the environment and redux etc. Im trying to build my first test app that handles data living remotely.
In the React tutorials we would use local mock data, and try to fetch it and even simulating the delay with a setTimeout call. But the problem is the tutorials worked excellent only for the types of apps they were building. I'll get to this in a bit...
My app description:
At the moment i'm making a test app and so far I can : retrieve a collection of food items ( remote data), render the data, and press "LIKE" on anyone. After pressing Like that food item URL gets saved into another remote file under the authedUser's account under a "favorites" property.
The food data at the moment is in a json file hosted on a github repository.
and so is the users account data.
The thing I noticed in the react course was, Data would be received into the redux store.
from there anytime you dispatched an action which involved data changes like "Favoriting" something, the app would first dispatch an action to server. Once that resolves it would dispatch to the redux store and affect it there.
Now from what I understand... this is a way to keep the data in sync? Is this how other applications do it? or is it when data is changed, you only dispatch the change to the server, and request/fetch the new data into redux once the action resolves? The tutorials would receive the initial data, and like this it would be set and stone and then rely on the dispatches to keep it in sync. would it be better to simply use local state, fetch the data we want. vs using the store?
Im not exactly sure whats best, but to me the idea of receiving the entire data file into the app seems not scalable? like when you use instagram for example, your phone doesn't download the entire instagram database. Im thinking it downloads only your profile? and url's to your friends? etc?
so for this test app that I am trying to make ( described in italic font above ^ )
I'm not sure how to go about it. I definitely don't think its appropriate to receive the entire data file. I know that I want the user to receive food items onto the screen, but only a handful at a time, maybe through a search it modifies the results on screen. then the user can like a food item.
This is the first time i'm working on an application of this sort, and I do think i'm missing something.
It would be a good idea to not integrate Redux at first. Just build the application in plain React.
Now talking about your app. As you said, is a bad idea to download the entire database. When you have to fetch a lot of data a common pattern is to use pagination. It works like this: your app asks for 10 food items. The server returns those 10 and tells you that there is more data and you should make another request if you want to fetch more. It doesn't make sense to fetch 1000 products if the user can see only 10 at a time, right ?
Let's say you like a food item. After you press "like" it is not enough to update your app state, you also need to make the change on the server. How you do this ? Usually you have a food item id(let's say 123) and you maybe you make a POST to https://server.com/like/123. Now that request may fail for various reasons and the server will not register your like. This is way you update the local state only after you successfully updated in the database. In addition you may want to update the number of the likes(maybe other users liked that food item since you fetch) so the server will return the updated number of likes.
Where does Redux fit here ? In React every component has its own state. They can share data between them using props. But this doesn't scale and you will usually end up in a situation called Prop Drilling. Redux store is some kind of global state. For instance:
<FoodItems>
<FoodItem key=1/>
<FoodItem key=2/>
</FoodItems>
Let's say somehow you update the description for the first FoodItem. How do you tell that to other components ? In Redux you dispatch an action and modify the store. Now other components can connect to the store and get the value from there.
I'm currently building an e-commerce react application, where users can sell pre owned stuff to each other. A typical workflow from a user perspective for creating and managing ads can look like this: A user creates an Ad -> The Ad is uploaded to a database -> The user fetches his ads from a database and views them in a list -> He decide to change something in an Ad, clicks it and gets a form with the ad data (fetched from database) that can be edited.
My problem here is that I'm really confused about what to keep in redux? The purpose of redux is to simplify data flow, data that is needed in multiple components should be stored there. But if I always fetch the data i need from database (as for example when a user fetch a list of his ads or the ad data that can be edited), isn't redux just an unnecessary step then?
I want to be consistent throughout my code about how I'm fetching data. Right now I've been using redux to store all my data fetched from database, keeping all my API calls in different actions. The data fetching however get really troublesome when it comes to fetching data from the database that then should be editable by the user. To make fetched data editable, it has to be stored in the components local state, so storing the data both in redux and local state feels very inconvenient.
I've searched the web for specific guidelines for the but I'm not getting any wiser. To be honest I don't think I've understood how to use redux properly. I would be really grateful for some advice on this matter.
Primarily its used for application state management. You need to consider your usecase and yourself simple questions i.e
Do you need that state for rest of the applications?
Will other components get affected by these states?
How often your data will
change?
Are there other users using the same data and can update it?
Do you need to cache the data to prevent refetching?
The view built on top of it is a reflection of that state, but does not have to exclusively use that state container for everything it does.
For example, in your case, you will need to keep your api's responses into redux state if you want to pass that state to other components and you dont want to do the same API call again and again.
But, if your data changes so often and you need refreshed data everytime you should not keep it in the redux. Otherwise you will end up having stale data on different screens.
Note :
There could also be other possibilities that can be consider but this is some very basic info that I thought will be useful for you to take a decision
Lets say we want to have one instance of the application and multiple tenants trying to access same features but also have some level of customisation and of course data isolation. In short Basic SaaS model.
Tenants will probably be identified by subdomain/domain and/or by querystring.
So the main question (which is rather specific):
What are common approaches onto implementing a multitenant environment using React + Redux ?
Thinking loud:
How to approach/structure the Application Store.
How to deal with tenant specific configurations
Do I need to have some sort of a TenantContext available somewhere at hand.
How to ensure proper level of isolation and avoid race conditions?
What else should be kept in mind while developing it?
Any thoughts, ideas, past experience, advice, are highly appreciated.
Thank you!
A typical Redux store usually only reflects persistent data, and contains application-specific data, like which tab is active or what is the value of that field. But in case of persistent data, that's an interesting question. I believe React and Redux are simply not for that. But even though, there's an interesting solution for that: Relay and subscriptions.
Relay connects your components to a GraphQL source of data (typically remote), and then you simply access props that are seamlessly injected into component and given values from the data storage. With subscriptions, any update in the data storage causes its delivery to a connected component via a subscription established between the app and the GraphQL server.
Now, you can add an extra layer for multitenancy and synchronize data between nodes on a lower level, completely unrelated to React. The only thing now is that you'll need to listen to every update and send subscription updates, and there's no nice "single-click" solution for that yet.
You can see this discussion to get an idea how you can update a subscription. Good thing is that, on the client-side, the app will simply react to updated props with a connected component being re-rendered with new props.