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.
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.
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.
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 building a React.js application that interacts with the WebRTC apis to do audio/video calling. When a call is successfully established, an 'onaddstream' event is fired on the RTCPeerConnection instance, which contains the stream that I as a developer am supposed to connect to a video element to display the remote video to the user.
Problem I'm having is understanding the best way to get the stream from the event to the React component for rendering. I have it successfully working by just dumping the stream into my redux state, but in this other answer, the creator of redux Dan Abramov mentioned this:
[...] don’t use classes inside the state. They are not serializable as is. [...] Just use plain objects and arrays.
Which leaves me wondering, if I shouldn't put these streams in the redux state, is there a better way to react to the 'onaddstream' event and get the React component to update without putting the stream in the redux state?
In my experience things like socket connections and, as in your case, webrtc things, are well-suited for living inside their own middlewares hand-written for your application. You can wire up all connection management here, fire actions to communicate with UI and listen for actions coming from here.
Another solution would be to look on redux saga, which seems to be quite a nice option for handling complex effects as sockets and webrtc.