Hi did a good job covering the Redux VS Flux point. I think you'd have to make a pretty strong case about why your home-grown solution is better than Redux to justify the additional ramp-up time for any new hire to be productive. Zero of them are going to know your Flux implementation that you wrote yourself. A lot of developers you might hire are already going to know Redux. Picking a widely-adopted solution gives you a big advantage when it comes to hiring and training a team. The whole Flux community as really converged on Redux as the best choice, so it really simplifies the decision process since it appears to be the only one of that bunch being supported anymore.Īs an aside, as you mention, most of the developers you are interviewing already know Redux. Picking an unsupported library for your projects is likely to cause some pain down the road. Looking at Altjs and Reflux, which were the top Flux libraries before Redux came along IIRC, neither of them has been updated for over a year. Honestly it's kind of a moot point really. If you think Redux adds too much boilerplate (possibly a valid complaint for smaller projects) there are options like Mobx that would be better than using some crusty old Flux library. It's not that Flux is terrible, it's just that I can't think of a good reason to pick Altjs or Reflux or something like that over Redux in 2018. Having used both approaches, I think Redux is a big improvement over Flux. In short Redux takes the Flux concepts of Actions and Stores and reduces a lot of the complexity by adding the constraints that there is a single state store and that state updates are purely functional. With Redux your Store is immutable and new versions of your state are produced by Reducer functions which take an Action (a plain object) and the current state Store (also a plain object) and produce a new copy of the state. Flux has mutable Store objects and you propagate those changes to your components by attaching event listeners. After an Action is handled, your Store object is a brand new copy that represents your entire application state.Īnother big difference between Redux and traditional Flux is the functional style. There is never any question about where a given piece of your state lives or any concern about synchronizing updates across different Stores. Redux removes this bit of complexity and ambiguity by having a single store. This means Stores have to be able to subscribe to updates from other Stores. In Flux you may (correct me if I'm wrong) have some value in Store C that depends upon values in Store A and Store B.
Possibly the most important difference is that Redux has a single Store object whereas Flux can have many. Redux is not exactly "nothing but another Flux implementation." Redux and Flux share a lot of concepts, but there are some key differences. What is it that made so many frontend people jump on the Redux wagon?
A big mistake I see often is that people take Redux as an architecture pattern and implement their own uni-directional data flow architectures that are based on "Redux", when indeed it is nothing but another Flux implementation. Now with Flutters community rising in population you can see that people use react (native) approaches as those 2 frameworks are really similar. The answer was mostly "You do not use Flux anymore, you use Redux". After asking for the advantages and differences, I was kinda surprised that almost none of them knew actually what Flux was and that Redux is an implementation of Flux. They all had several years of experience (5+) in Frontend and when I told them about our architecture most of them said "you should not use Flux, you should use Redux". The next following weeks we interviewed some Frontend Devs for the lead position and I was kinda confused. Now since that pattern is pretty simple I decided to build an architecture based on Flux myself. Since it's a bad approach to apply classic MVP / MVVM / MVC as architecture for the app layer I decided to look out for patterns and found Flux being the most common one with having a very popular framework (Redux) implementing that pattern. Now at the startup I work we decided to build the frontend team, as we had no frontend devs aboard yet I decided to give it a try.Īfter weeks of research and practicing I ended up picking React and TypeScript as our main stack.
#Flux networks vs ae2 reddit android#
I'm a former Android Developer with 6 years Java background and deep interest in software architecture and clean code in general.
0 kommentar(er)
