Old Flux, New Flux
Tags: agilewebandappde, softwaredeveloper
Published: 2018-07-25 10:44:08

---
title: Old Flux, New Flux
published: true
tags: Agile web and app de,Software developer
canonical_url: https://apiumhub.com/tech-blog-barcelona/new-flux/
---

If you are not new to [Frontend development](https://apiumhub.com/web-development-barcelona/), you have heard about new Flux, Redux and React, and most likely, have tried it or directly used it in a project. It comes with no surprise since [the popularity of React is undeniable](https://medium.com/javascript-scene/top-javascript-libraries-tech-to-learn-in-2018-c38028e028e6). React’s success is attributable to its simplicity, ease of use and a great community.

What is also true, is that I would bet most of you used React with [Redux](https://redux.js.org/). Both libraries go hand in hand so often, it’s difficult to imagine it’s possible to use React without Redux. Nevertheless, believe it or not, React is a library for building user interfaces developed by Facebook, and Redux is a library for managing application’s state developed by.. Dan Abramov and Andrew Clark, **not** Facebook. Facebook has its own library to do that job, which is **Flux**. Despite Flux being released about a year before Redux, and coming from Facebook itself, the _de facto_ standard to use with React is the latter. 

Moreover, I only met a handful number of developers that actually used [flux’s package](https://www.npmjs.com/package/flux). Which always allowed me to nag about how much I miss the simplicity of the “[pub-sub](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern)” nature of Flux, and therefore having a listener in the View for being able to react to a specific change in application’s state. Something that in my eyes, got lost with Redux.

To achieve this in new Flux, a Store, after processing an Action (event), must “manually” emit a new event, that will be listened in the view, which will allow us to trigger a callback function to react to that change. Despite adding verbosity and certain complexity to the code, it was a beautiful tradeoff to avoid the _connect_ binding of Redux, that although working nicely most of the times, sometimes forces the developer to use **componentWillReceiveProps** lifecycle method to distinguish what props has actually changed, falling into if nightmare inside the method, to check what exactly changed in _props_.

Of course, Redux brought some great concepts, such as reducers being pure functions, immutable state (a new state is generated instead of modifying the existing one), and some, in my opinion, more about cosmetics and ‘good sounding’ statements, such as _single store_ === _single source of truth_.

Recently, when coming back to Flux documentation, I was surprised to see no reference to the pub-sub implementation I mentioned before. It was just gone. Instead, all examples only referenced stores that extend ReduceStore, from ‘flux/ **utils** ’. Doing some digging, I ran into this [closed issue](https://github.com/facebook/flux/issues/448) on flux’s github repository. Basically, new Flux implemented their own version of Redux, where stores implement a reduce method that is a pure function that returns a new state of the store. Because of this, I considered it would be interesting to compare how Flux used to be implemented, and how it is being used now.

In this [public repo](https://github.com/ropre4/flux_example), you have a working example of both data flows. In `AppContainer.js` you can find two React components `AppViewOld` and `AppViewNew` being rendered. To see the full implementation feel free to clone the repository and play around with it. Here, I would like to only focus on the difference that appears in the view component.

In case of the `AppViewNew.js`:

 

[![new flux code](https://apiumhub.com/wp-content/uploads/2018/07/new.png)](https://apiumhub.com/wp-content/uploads/2018/07/new.png)

Here, we find some boilerplate with static functions _getStores_ and _calculateState_, nevertheless, in the components AddItem and ItemList we will have access to the State defined here via this.props. And most importantly, whenever the store updates its state, _items_ will get magically updated. Which in this simple example, looks like a great thing, but when the complexity of the application grows, this can bring some headaches to the developer.

Now, in case of `AppViewOld.js`, what we will find is:

[![old flux code](https://apiumhub.com/wp-content/uploads/2018/07/old.png)](https://apiumhub.com/wp-content/uploads/2018/07/old.png)

 

Here we see much more boilerplate, especially when we manually subscribe and unsubscribe from Actions, using React component lifecycle functions. Nevertheless, the legibility of the code is simpler. We see to what events (or actions) will this particular view react, and more importantly, what will be the effect on the view once these actions happen. In this case, it’s the function _refreshItems_ that applies the only change to the state of the view. Moreover, we could set a different callback for ITEM\_ADDED\_OLD and ITEM\_REMOVED\_OLD actions, both of which interact with the same part of store’s state; something that we do not have with the first approach, where we only know that _items_ have changed, but not if a new item was added, or if some item was deleted from the list instead. In fact, to actually differentiate this we would need to use _componentWillReceiveProps_ lifecycle function, with a quite an ugly IF comparing the old state and the new one. 

 

If you would like to get more information about new Flux, I highly recommend you to subscribe to our monthly newsletter by clicking [here](http://eepurl.com/cC96MY).  

 

## And if you found this article about new Flux useful, you might like…

 

[Scala generics I: Scala type bounds](https://dev.to/apium_hub/scala-generics-i--scala-type-bounds-38)

[Scala generics II: covariance and contravariance](https://dev.to/apium_hub/scala-generics-ii-covariance-and-contravariance-in-generics-5dib)  

[Scala generics III: Generalized type constraints](https://dev.to/apium_hub/scala-generics-iii-generalized-type-constraints-58km)

[BDD: user interface testing](https://apiumhub.com/tech-blog-barcelona/user-interface-testing/)

[F-bound over a generic type in Scala](https://apiumhub.com/tech-blog-barcelona/f-bound-scala-generics/)

[Microservices vs Monolithic architecture](https://apiumhub.com/tech-blog-barcelona/microservices-vs-monolithic-architecture/)

[“Almost-infinit” scalability](https://apiumhub.com/tech-blog-barcelona/almost-infinite-scalability/)

[iOS Objective-C app: sucessful case study](https://dev.to/apium_hub/protected-ios-objective-c-app-cornerjob-successfull-case-study-89e)

[Mobile app development trends of the year](https://dev.to/apium_hub/mobile-app-development-trends-of-the-year)

[Banco Falabella wearable case study ](https://apiumhub.com/tech-blog-barcelona/banco-falabella-wearable-ios-android/)

[Mobile development projects](https://apiumhub.com/software-projects-barcelona/) 

[Viper architecture advantages for iOS apps](https://apiumhub.com/tech-blog-barcelona/viper-architecture/) 

[Why Kotlin ? ](https://dev.to/apium_hub/why-kotlin-language-android-why-did-google-choose-kotlin--639)

[Software architecture meetups](https://dev.to/apium_hub/apiumhub-software-architecture-meetups-in-barcelona-31df)

[Pure MVP in Android](https://dev.to/apium_hub/pure-model-view-presenter-in-android-1736) 

 

The post [Old Flux, New Flux](https://apiumhub.com/tech-blog-barcelona/new-flux/) appeared first on [Apiumhub](https://apiumhub.com).