I am new to react and wondering what the best way to have decoupled communication in a modular React based application. Actually my issue is a plain old JavaScript abstraction over a restful API that is consumed by a React application.
I have a need to notify a consumer of the API abstraction that something has happened (session has timed out on the server as it happens).
Ordinarily I would use pub sub / an event bus.
I have considered adding another shared redux layer but that still couples everything together though delegates the coupling into the shared module which I guess is a mediator.
I can't find much about this online.
Anyone got thoughts on this?
Thanks
You could use Redux Saga/ Thunk for the above purpose
Related
I am building a simple real time messaging app using react and socket.io for practice.
Current solution uses React's Context only to store socket.io object and React-Redux to store the rest.
The reason that I'm using the context alongside the redux is because redux cries for the following error when I try to store socket.io object into its state.
I also thought of using an exported socket.io module instead of the Context:
import io from "socket.io-client";
const socket = io(URL);
socket.connect();
export socket;
but did read some thread saying that it is not a great practice of using React ecosystem.
Any inputs, please?
It is absolutely fine to use Redux for state management and Context for dependency injection like you are doing here.
That's exactly what each of these were made for.
I am also working on a real-time chat widget project here in my company, and one thing I will suggest you is, while using react, it is all up to you what are you using and where because react is a library. but keeping one thing in mind your components must be scalable. I made my widget using svelte and managed the Web Sockets using event handlers.
you should give it a try.
one file with all the socket code and event listeners attached to them
2nd file with the custom events written which will invoke the socket operations from 1st file.
Can somebody explain to me why you would ever use a statemanagement tool like Redux or the Provider library instead of just creating your own Singleton class to hold the state of your application?
Redux is so much more than a singleton. It gives you pub/sub, time-traveling to prior states (especially good for debugging) and an open-ended api to plug in your own functionality. It is an especially good place to handle side effects.
In react, you can't just "plug in" your own data structure and expect everything to update properly. React updates on an as-needed basis. In order to do that, you have to use the React api in one form or another (context api, hooks, etc.).
Any singleton implementation you do will essentially be a subset of redux's functionality. In an overwhelming majority of cases, you will need all of redux's features (along with 3rd party middlewares) in a long-term production application.
I am currently working on a react-native real-time application (a chat app) and I was wondering which would be the better place to manage the socket connection and events handlers (using socket.io).
I am using Redux as global state management, and so I was first thinking of managing the socket in a middleware. But then I thought it could be a good choice to implement it using React context API. The provider would only provide the socket itself to children, and so would not directly trigger any rendering (incoming events would dispatch redux actions).
Today React context mainly suffers from poor rendering optimizations, but in this case this wouldn't be a problem.
How do you manage your sockets connections in your React apps that use Redux? Everything using Redux with middlewares? Or do you combine it with the context API? Do you seen any cons in doing this way?
Thanks!
I'm learning react recently. I don't understand why any online tutorial said that react has View Layer only. But I think react has Controller Layer only.
Can any one help me understanding how react has View Layer?
If we think about a web app that utilizes React as utilizing a Model View Controller architecture then your tutorial makes sense. React acts as your view, but interfaces with your server. Your server acts as your controller, but interfaces with your database. Your database acts as your model.
A React application can be written completely in JavaScript files. In this case you would utilize JSX for your template structure and JSS for your styles.
React also gives you the ability to manipulate your DOM using JavaScript. It simplifies this by giving you lifecycle methods to work with, or hooks. Behind the scenes React uses a virtual DOM and a process called reconciliation to make updates to only the components that require changes based on the JavaScript logic you implement. This makes React applications very efficient, and gives you a tremendous amount of control over your UI.
This is a very broad answer, but I think you need to spend some more time looking through the docs and watching more tutorials to understand the framework and how it fits into a web app's stack. Hopefully this helps point you in the right direction. It's a fantastic framework, so stick with it!
I'm not a frontend developer and have not used react or any flux implementations as I'm not sure if they will do what I want. I'm trying to wrap my head around how to use react to render backend changes that are external to the client, ie changes by another user. I see how react works to handle the view when the client takes an action, but I'd like to render changes from the server/other users without long polling (similar to how meteor works with two-way data binding).
My solution was to create a pub/sub system on the backend that will push changes to the clients if they're subscribed to the appropriate channel. This could be accomplished by analyzing database queries/backend actions and their resulting changes as is done with Asana's Luna. My friend told me that I can simply do this with only using an implementation of flux. If he's correct, I must be misunderstanding what flux actually does. To me, it seemed that it only reflects changes based on the actions of the 'current' client.
You are right. Flux is simply a way to manage application state in response to different actions. How you would trigger those actions is out of its concern. pub/sub server in this situation is a right way to go. You can take a look at Firebase - google non relational database that has lots of SDKs for different platforms and can notify client of changes done by other users. But anyway it works as a pub/sub server =)