Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am taking this course building a chat app with react and firebase as backend. The problem is when I got to connecting react, redux, and firebase the whole process became so complex that got me wondering what's the point of Libraries, Frameworks, and SDK if not to make the development process easier or faster at least. Please is there other alternatives to using Firebase as backend with react. (Without so many add-ons, helper-functions, and enhancers that I need to connect)
There are quite a few alternatives: PubNub etc.. but all of them will require some setup and config to make it work with react. firebase by itself is not complicated, but make it work with react piles up the complexity a bit.
Just try it a bit more and once you are done with config and setup it way more fun. Here is a simple example to try: https://www.codementor.io/#yurio/all-you-need-is-react-firebase-4v7g9p4kf
The title doesn't explain your problem. I think its not firebase thats getting in the way, but in-fact redux/ react-redux-firebase.
If you're just learning react, you should not be trying redux. Redux has a steep learning curve, and will get in the way of you understanding the real part of react. Kent C. Dodds has said:
guess what, you probably don't need a library like Redux anymore
This might be speculation, but redux might not be as popular in the future, so you might not even have to learn it in the future. You can just use Context. People often abuse redux.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We are a small company, using emberjs as the main frontend framework for our projects. The frontend architect sticks to it like liquid glue sticks to paper, because he doesn't know any other frameworks. The main reason that is forced is the slogan: 'convention over configuration'. And there are reasons like emberjs is faster in larger scale applications.
Anyone can reason pro-contra for emberjs, angular, react etc.. (hopefully someone who knows all of them, at least emberjs, and another)? We are having meeting sessions about this, where junior frontend devs try to convince the architect about the other frameworks. In my opinion this should not be a technical issue, all of the frameworks are capable of developing 'larger scale' applications. The real reason should be the recruiting, we would find react/angular devs more easily.
Thanks
I was in the same situation and managed to migrate to react+redux toolkit+nextjs.
The way I started my introduction is by explaining what is react. React is a rendering engine. I compared it to glimmer components and ember components. I then explained that most of our components were ember components wich are deprecated and need to be migrated anyway
I then explained that we could just live with ember data, ember cli and react.
Then I showed why ember cli was old and there was this new cool kid embroider that we will need to migrate in the future. I explained what was embroider and how it compared with nextjs. I pointed out that I had experience with react and nextjs but not with embroider.
Then I pitched that Ember Data along with nextjs and react was a viable solution. I also showed that the standard stack with nextjs and react was to use in place of ember data: redux toolkit (you could choose react-query depending on your needs)
At the end of this meeting, people were excited but still had questions.
I then had to do different presentations and discussions about architecture and costs. I produced swot analysis, risk analysis, benchmarks on component libraries (we went with zendesk garden), cost of development per feature..
It's a long process but if you take time to discuss. Remove any passion from the discussions and at the end focus on reducing costs, you'll get your migration.. and yeah the fact we were struggling to recruit ember experts helped with my arguments :D
I should write a blog post about that xD
PS: regarding "convention over configuration", you can find this concept applied by nextjs and redux toolkit
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am a student trying to learn web development along with the ReactJs library. But I have a huge struggle selecting between React Context and Redux state management. I have never worked on real-time huge projects. So everyone is suggesting I should go with React context. Even my friend who is working on a real-time project in the IT field is using React Context instead of Redux in their project. So he suggests I should just stick with React Context. But I think Redux was there even before React context and is really suitable for huge projects. So a lot of the older projects may be using Redux. But Redux is really hard compared to React Context.
Can anyone give me a suggestion on whether I should just stick with React Context or I should learn Redux?
Depends on the scope of your project. There can be some problems with React Context with high frequency updates, but if it is mostly low frequency ( theme changes, authentication ) then just use React Context because it's simply better if you plan to use the data only in ReactJS and it's additional packages
Actually it is a good idea to know both. I would start with React context which is much smaller and easier to grasp, and out of the box.
Then you can switch to redux - and do some work with it. You will learn both since both are not that difficult.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I started to work with React Native using Expo and I am trying to figure out what the best practices are. Due to my previous experience, I would like to avoid performance issues before they going to be difficult to handle. I've read some articles about Pure Components which seem to help to improve the performance. My question is whether Pure Components are compatible with the expo or if it even has something to do with Expo? I couldn't find any relevant information about it online.
Pure components has nothing to do with Expo. They are part of the React fundamentals.
It is impossible to teach you through a comment here the react lifecycles and performance optimizations so my best advises to you are:
Read a little bit about the react life cycles and understand when component gets rendered.
Use functional component and hooks as they will make your life much easier and it is the "modern" way to use react.
For performance improvement read a little bit about the RN bridge and learn "useMemo", "React.memo", "useCallback". The best way for me to get deeper understaning after reading documentation was watching YouTube videos. I really recommend the "Web Dev Simplified" channel.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm recently getting into React.js and learning with a small project.
While studying, I couldn't figure out clearly why I used react-saga or react-thunk.
It is said to process redux state value asynchronously.
But don't we already have async / await?
Shouldn't we call api from a component file using async / await to get a value from the server and store it in the redux store?
I've seen a lot of articles on why to use react-saga, but the question hasn't been answered yet.
Why is there a clear reason to use redux-saga?
Saga deals with more complex async flows. Thunk is the simple tool for async redux actions that is probably enough for 90% of projects. I'm a bit biased here because I think saga is often introduced as a shiny new tool into projects without an actual need. I have yet to see a project where they clearly needed saga (and not just thunk).
To your first question: Yes, we could handle async things in components and use async/await to dispatch actions around api requests, but it's bad design, since you're concerning the React component with things it shouldn't care about. It should contain display logic and be testable with only that.
Getting the data from api responses into the redux store should be handled outside of components because it's simply not a concern of the view rendering abstraction layer in your app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Working on my personal project and want to use hooks inside.
I've seen a global state implementation using hooks and my question is:
which one is better to use? Redux vs use-global-hook ?
It seems super easy to manage with the global hook, but what about performance? What are advantages, disadvantages over redux?
I've built apps using both methods and didn't notice any difference in performance; although Redux bindings are supposed to prevent unnecessary renders, I'm not sure how much of an impact this would make on the final performance of the app. Furthermore, Redux offers a time travelling debugger as well as a middleware API. The following article discusses this topic in more depth:
https://frontarm.com/james-k-nelson/when-context-replaces-redux/
If you're planning to build a sizeable project of any complexity, Redux is going to provide a feature-rich store and state management via a unidirectional flow, actions, reducers, middleware, asynchronous thunks, etc. Redux is a mature pattern (based on Flux) with a great deal of "road-testing" and a thriving community. Also with Redux you'll be able to use fully stateful React class components and leverage the component lifecycle.
Global state hooks seem like a great upcoming solution for simpler components and problems where you want to keep your components functional and pure. I don't see any signs the performance would be any different, the only way to tell would be via empirical profiling.