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.
Related
I would like to create simple forum where users would be able to add/delete/modify posts stored in database. I have simple auth app: client(react app) - server(express). Is it possible to force client side to rerender for one user when there is a change made by another user while both are loggedIn?
It should be simple enough. When a logged in user is on a page that you want to keep synced, open a websocket to the server. Then, when any user makes a change, the server can update its database, and then once that's finished, it can send a websocket message to all users with connected sockets on that page, containing the new data to render.
In the client-side React, create the socket and subscribe to its message event. When a message is sent from the server, call the state setter with the new data.
This mechanism is somewhat similar to how Stack Overflow pushes "An edit has been made to this post" notifications when a post gets edited - anyone looking at the page will see such server-sent notifications through the websocket connection to Stack Exchange.
Websockets is one approach you can follow. If you think this will be complex to implement, you can poll for the data every minute or so.
This is very useful library tailored for React:
useQuery- https://tanstack.com/query/v4/docs/reference/useQuery?from=reactQueryV3&original=https://react-query-v3.tanstack.com/reference/useQuery
You can use it for polling/caching and making regular network calls as well. Lots of utility is provided that you can leverage; especially, considering the use case you seem to be tackling.
There is a slight learning curve, but its worth it if you're a react developer.
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.
How to register for cloudkit push notifications in react-native android?
Thanks!
I'm not sure what the influence of react native is, but generally speaking CloudKit would function like this:
If you are using the webservice api, then you can only modify subscriptions. You can not register for a subscription. See: https://developer.apple.com/library/ios/documentation/DataManagement/Conceptual/CloutKitWebServicesReference/Introduction/Introduction.html
If you are using the javascript api, then you can also subscribe. See https://developer.apple.com/library/ios/documentation/CloudKitJS/Reference/CloudKitJSTypesReference/index.html#//apple_ref/javascript/struct/CloudKit.Subscription
I assume that the javascript subscription will only work as long as your application is active and your created subscription is active. I have no experience with this, so I could be wrong.