Now that my classmates and I have finished the initial release of our first framework, I thought it would be good to explain how TuxedoJS came into existence. In an effort to make it a little bit easier to handle writing about this topic I've decided that instead of writing one massive post, instead I'll break this into a series on the process that will be composed of several posts. The current plan is to write the following posts:
- Why Make a Framework on React and Flux?
- Identifying Pain Points in React and Flux, and Determining Initial TuxedoJS Feature List
- Taking TuxedoJS from Pain Points to Feature Complete Framework
Initial Experience
My first exposure to React and Flux were while working with a group to make the initial client and admin applications for a local San Francisco food delivery company in late September 2014. Initially we started to build things with just React, as none of us had used it previously, which was easy to pick up to thanks to the excellent examples on Facebook's React page. As soon as I got the basics of React under my belt, we added in Flux and my brain went "Wat?". Things had gone from the relatively simple pieces of React to:
- What are actions for and how are they used?
- What are constants and why are they matching key/value string pairs?
- What is a Dispatcher and how do you register callbacks with it?
In order to find answers to these questions I ended up creating a CRUD Todo application several times throughout the project, using React, Ruby on Rails, and PostgreSQL. Doing this allowed me break down what each piece was doing and how the data flowed from one place to the next. This process provided me invaluable insight into how everything came together in React and Flux and I highly recommend it for anyone looking to increase their comprehension.
Takeaways From First Project
As the project progressed and the pieces began to come together I really enjoyed working with React and Flux. For whatever reason the way things are put together really clicks with my brain and I loved working with them. As I gained a greater familiarity I noticed several things that weren't optimal within the React framework.
- Each store has a decent amount of boilerplate code for adding and removing event listeners and emitting change events
- Spelling mistakes related to constants are very common and take unneeded time to track down
- Passing methods and properties down through components was an error prone process
Additional Discoveries While Working on Brainstorm
A couple of months after working on Blooming Spoon, I had another chance to work on a group project with React and Flux while attending Hack Reactor. This time I had more experience and I didn't encounter the same initial stumbling blocks that I had encountered the first time, yet there non-optimal pieces within React were still there. In addition to the points noted in the previous project additional questions arose, that weren't easily answered.
- How do you deal with state properly and where should it be kept?
- Where should common static methods and properties be kept?
- How do you efficiently pass props from parents to children components?
- Why are switch statements used to register callbacks to the Dispatcher within a store?
The more I worked with React and Flux the more I liked it, yet I also thought that were pieces of my experience that could be improved upon and one of my other teammates, Dmitri Rabinowitz, agreed with me. With this in mind I made a note to myself, under potential final project ideas for Hack Reactor, to create a framework on React and Flux.
Hack Reactor Final Project Pitches
The time came to pitch our final project ideas at Hack Reactor and both Dmitri and I pitched the idea of making a framework on React and Flux. Even though I had never made a framework before, I had seen things while working on React and Flux that I thought I could make better and reduce the pain points. One of the easiest ways to find a project idea is to identify pain points or repetition and to then work on making that experience better.
After everyone pitched their ideas, Dmitri and I decided to move forward with making a framework, which was extremely exciting to me. I had enjoyed working with React and Flux tremendously thus far, so the idea of making my experience and potentially others even more enjoyable was extremely enticing. We found two more people that wanted to work on the project, Pat Lauer and Spencer Stebbins, both of whom had never worked with React or Flux. This team combination of two people familiar with React and Flux and two people unfamiliar proved to be very valuable.
Once our project group was formed, we decided to spend time discovering and documenting the pain points of React and Flux. I'll be covering our process for that in my next post.