Is it oaky to use React Context alongside with Redux Provider? - reactjs

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.

Related

Best place to handle sockets in a React application using Redux

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!

How React context API works in case of nested components?

I have some Question in mind while switching to context API in react js .
What is the advantages of New context API in React js .
Can we use Redux along with context api ?
What are the overcome of context api on redux if any ?
so here is the answers to your questions.
With context react now have builtin support for state management so you don't need third party lib like redux or mobx.
Yes, you can but not required, however, you can use reducers with context to handle complex state management.
Less boilerplate code, especially with hooks and not dependency on third party lib and for small project context, makes it very simple and easy.
If you are looking for example then I created this repo to demo and check other branches to explore more ways of using context.
https://github.com/smkamranqadri/react-hooks-context-todo

what is a generally acceptable way to structure a service layer in a reactjs project?

I'm using axios.get() to call an api endpoint in one of my components. I need the ability to encapsulate this endpoint call so I can reuse this implementation by calling it from several different components.
What is a generally acceptable way to structure this type of implementation in a React project? For example, would it be generally acceptable to group related api calls into js files in a src/services directory at the same level as src/components?
It would be acceptable to create a utils or services directory and group related API calls. However it is important to remember that with async requests you need to consider the components calling the api service utils might un-mount. This might result in warnings or errors if not handled properly. A possible way to handle this might be to only execute callback functions if component is still mounted tracked via a state variable in a useEffect hook.
A more modern react approach might be to leverage hooks and react context for data handling. You could create a DataContext with a useReducer hook to fetch or push data for example.
(see https://reactjs.org/docs/context.html)
There are many way to do this.
Redux. It's old way is that you need to use redux style.
Hooks. Starts from React 16.8 version.
I will recommend to you use hooks. It's more useful and guarantee true way.
3 years ago i lived in Redux paradigm and every time write the monkey code thinking about consistent Redux store state.
Please try this one react-async package.

React (Native) Architecture and state management

Trying to understand the best practice for React/React Native state. Coming from the Java world, I tend to follow MVC/MVVM in my applications, but reading about other approaches makes me wonder if I am designing my application properly.
Premise:
App mostly for consuming video and audio content, storing user statistics and progress
React Native Firebase from invertase.io
Redux used for storing data structure from Firebase Realtime Database
My current approach:
If a React Component needs data, it gets it via Redux or parent component via props.
If a component needs to manipulate/fetch more data, I have separate viewmodel classes (Typescript files with no dependency to React/RN) that are accessed in a component.
If the viewmodel gets new data from somewhere, the component state gets it via Observer pattern by implementing an interface
If data needs to be persisted to Redux and/or Firebase, the viewmodel does it. I pass the Store object from the component
Approach I read/heard/discussed:
All data from/to components is received/sent through Redux
All data manipulations are done in Redux Actions
No separate controllers/viewmodels
I don't have too much history with React Native, so I am trying to understand whether the latter approach is actually superior for some reason.
These talks helped me understand Flux at a fundamental level. The basic idea is unidirectional data flow. Watch the talks and pay attention to them.
You don't need Redux to implement Flux– I used Alt.js instead.

How to make a Socket.IO instance available on different pages with React Router

I am trying to make a single page application that includes react, react-router, socket.io. I am using babel to compile es6 and jsx to plain js.
I want to make a socket instance available in many different components, on several different routes.
When the user connects, I must create a socket instance (I do this with
import io from 'socket.io-client', and then const socket = io()). I then want to be able to access this socket object from different components on different routes (of react router). I want to keep the same connection as the user moves between pages.
I currently have a hack that works. I put all my react components on the same page, and at the top of this page, I put const socket = io(), to create the socket instance. I can then use this global socket within all my components. I don't think this approach is very good though, because it requires having all the components in one file.
Can I define the socket in the state of the App component (the component that has the <Router>)? I could then pass it down as props to all the route components.
It seemed like contexts (https://facebook.github.io/react/docs/context.html) could be useful, except that link mentions that I should not use it. I have also come across redux, but I have a feeling it's unnecessary complexity for what I want.
If there is anything I can add or clarify, please let me know. Thanks so much for any help!

Resources