I have been creating a Reactjs app. I have encountered a problem and want to know where to fetch data from firebase. Is it better to fetch collections of data in the root component(App.jsx) or in individual components?
For now, I have users, products and sales collections. Some components use data from the same collection. Ex: Payments component also uses Sales collection data for analytics.
Case 1: If I fetch data in the root component I do not have to fetch inside the components.
Case 2: If I fetch data inside components I will fetch the same data twice for different components in different routes.
Please, advice me the better way of handling the situation.
You tagged Redux in your question so I assume you are using it in your React App?
If you are using Redux, place all of your fetching in your actions files. If there are other components that are listening to the state that are affected by the fetch, it will automatically re-render the component data. No need for you to do the fetching twice.
Case 1:- if you fetch all the data from root component. you will be dealing with lot of data in the beginning , will slow down the initial loading of the app (but should be fine for very tiny apps). Not recommended for medium-large scale apps.
case 2:- This approach is fine but will increase a small delay in all the components(for getting the data from API), but if you are concerned about the bandwidth usage & latency. you should think about a unified data store like redux.
Fetch the data once using actions/sideEffects from redux/thunk etc, keep it in the redux store. consume the same data in every other components.
Related
So, I am building an ecommerce app in sveltekit and wanted to implement cart as a global store, so components can query that store for cart status. I pretty much know how to implement it in a single page application, but can't get my head around how to do it with SvelteKit. What will be the best approach to make a reactive cart for such application? Should I store cart at server only and reload cart on each change? or is there a way to implement a global store that works between pages?
Just import the store to whatever page needs access to the store. It's entirely global.
import { motor } from '../stores.ts';
console.log($motor.horsePower);
Where and how you store the data is a design decision with various considerations: E.g. should it persist when an authenticated user switches devices (e.g. from phone to desktop)? Then you would have to store it on the server.
If the data comes from the server you can probably [load it via the topmost layout load function and put it in a store in a context which pages get access.
To have a fully client-side global store that does not lose state on (hard) navigation you can wrap localStorage or sessionStoage, the latter is less permanent. There are libraries that already implement such functionality or you can build your own (the contract for writable stores is very simple: Provide a subscribe and set function. I give a basic outline of a local storage store e.g. here).
If you need a global reactive store you can use a reactive db. Like firestore with rxjs (rxfire).
The nice thing is: An RxJS Observable can act as a drop-in replacement to a Svelte store.
Here you can find some example code. And no need to reload on each change, because it's reactive with the $store syntax.
Let me share the problem with my app:
When user initiates the app, it will directly navigate to Home Screen. While user is in home screen I would like to make bunch of api requests to fill the local db with the data for the "possible" screens that user can go.
In native applications I know that this case can be handled by a different task (parallel programming) however, react native is built in with Js and doesn't support multi threading.
I know there are some libraries that implements WEB WORKER's in react native, however what is the best practice to overcome this problem?
I use redux to overcome this. I will call the api and it will map the data to the redux store. All the screens are connected to the store. Since, the data is already loaded in the store I will just display it.
So recently I started to implement a database in a react app (like any real world app would have). My question is Why is redux needed? I mean if you have a database you can push information directly in a database and retreive it from there. You don't need to save it in a state. (New to react,redux. This was just my point of view)
Database and state management tools such as Redux have different concerns (although they manipulate the same thing: data).
When a client uses your app, it will first retrieve data from the database. At that point, that data needs to be held in memory in order to display it.
You can decide to use the React Component internal state which is component-scoped. Now, this is perfectly fine if you plan on using the data you just retrieved inside the same component.
As your app gets more complex, you'll sometimes need to use the data in different points throughout your app (e.g. if you retrieve the user info, you'll probably need to display it in the header, in the profile page, etc).
This can be tricky to do using the React Component internal state as (if you've tried React a bit) you know passing data is done by passing props down children components.
The common solution when you need to share data between different components is to lift the state up in your app, so you can pass it down to the different components that need it.
This can be tedious and prone to errors as your app grows.
Redux is the solution that addresses that concern. It helps keeping the state you share throughout your app clear and clean by creating a global state that can be accessible anywhere in your application (among other things).
Redux is a state management tool. Redux is for client state, by default it's in-memory only. It is not a 1:1 mapping to your database data but for your views to dispatch actions and then update the store state so other views can react to those data changes. With Redux, the state of your application is kept in a store and each component can access any state that it needs from this store.
talking to database every time is a php kind of thinking, which puts lots of load on the server with huge number of requests... slowing down everything.
with redux you create a mini store cart & fetch necessary data from database for immediate use and keep all of them with the user and remove the requests to the server for those items.
you need to use database not every time but only when needed... to render the app faster and use less resources.
There are multiple reasons to use Redux while using a database. For example you wouldn't save volatile state in a database. You could see everything that should not be shared between tabs as volatile state, like routing or component states like opened menu or form inputs.
I'm looking for a way to move a react component with it's state across windows/tabs to provide an interactive split screen display to our interface.
Currently I have a shared web worker setup where the 2 windows are communicating to each other and passing data between when a component is to be be moved.
What I'm struggling with is passing the react component across and having the new window render it out. I've been thinking about a few possibilities, the first using renderToString() on that component and passing this across via the web worker to the new window however I'm not sure on the correct implementation for loading that component back in as it's done on the client directly. Have also looked at using a redux store and keeping this context in the web worker so the state is remapped.
Ideally I'm wanting a kind of data representation of the component in it's current state which I can encode/decode.
Any idea is greatly appreciated!
You may see React components as a representation of a state.
So what you have to share between your windows/tabs is a state.
The react components will synchronize if your react application handle the state changes.
If you have a backend in your stack, you may synchronize the state with the backend in all windows/tabs.
If you want "realtime" clientside synchronisation, you may go with your shared web worker solution, and just share a serializable state.
If you use redux, you could maybe use redux-persist with a custom "web worker" storage implementation.
So I've been getting in to Flux the last couple of days, and more specifically I have chosen the alt flux implementation to work around. Mostly because of they way it handles server side rendering, which I thought was very nice. I am also using React Router (1.0.0-beta3 for now)
I have a problem with where to initialize my stores with data. My application uses server side rendering, thus I can fetch initial data from the API when a request comes to my server, and depending on the path that the user has entered I can fetch different data. (Is this correct? Seems kinda odd to me, since the purpose of SSR is avoiding the "blank white screen" but now we have to wait for async callbacks before sending back the server rendered DOM?)
But what if my user clicks on the Navbar for example, changing the path in react router? How do I initialize a store with new appropriate data now? If i understand everything correctly, this will not trigger another request from the server. It will simply rerender on the client using the bundled javascript. What do I do in this situation?
Say for example that I have a ProjectsStore that on /projects contains all projects that a company has ever done, but on /company/projects it only contains the projects for that specific company. How would I go about changing the data in this store?