GIPHY Capture: Lessons Learned From Flux

September 20, 2017 by Mike Nolan

Jumping into native app development from a web development background can be a monumental task for many. The web development community provides an incredible and seemingly endless supply of resources, free and open source tooling, packages and frameworks to help even intermediate developers build scalable and maintainable interfaces.

Given the ubiquitous nature of the web we have ended up seeing lots of thought go into the tooling and creation of paradigms for maintaining increasingly complex user interfaces. Tools such as React and Redux along with design paradigms such as Flux have helped make managing complex UIs significantly more accessible. Most importantly active web development communities have created mounds of documentation and blog posts explaining concepts, benefits, and drawbacks to these paradigms.

GIPHY being a predominantly being a web focused company sometimes has our full stack devs dip their toes into some native app development when the need arises. When our application logic becomes more and more complex, as with any application, refactoring and rearchitecting becomes a necessity.

GIPHY Capture as with most video editing programs deals with a lot of state represented in a temporal manner. It must keep track of all of the edits the user has performed, find where the user is currently within the video preview and then render the correct preview and UI elements based upon all of that. As we began to add more tools to edit our increasingly large state, we began to realize that we were seeing an increasing amount of cascading effects.

We would have different views call out to parents and sibling views to notify a change, and they would take that data, mutate it and hand it off to other views which needed to know of the information. It became increasingly difficult to understand what the state of the project was and bugs started cropping up.

Coming from recently working on a large React/Redux project, I began to see the benefits of the one way data flow that architectures such a Flux push. Instead of fragmenting our state across many components we could share them in one big store. When the UI triggers changes to that state we could create actions and send them to dispatchers that will update our store, and therefore update the relevant components.

This ended up becoming incredibly helpful because at any point in time you can export your entire project to a serialized edit decision list and inspect your state. As we create new features for editing your GIFs, it minimally increases the complexity of our codebase.

 

 

Flux’s one way data flow architecture can often times simplify UI and prevent the cascading effects that you can possibly see crop up in large MVC applications. Perhaps most importantly, Flux isn’t constrained to React based javascript applications. It helps compose our UI into more hierarchical components, describe a semantic API of how we modify state, and perhaps most importantly for myself, give a good jumping off point to dive into the scary world of native app development.