#w7d3

Today I Learned: how to use Flux

React and Flux AWESOME!

Today we had a brief lecture regarding the use of Flux in combination with React. There are a few core pieces of Flux: actions, dispatcher, store, and views. Data flows in one direction from Action --> Dispatcher --> Store --> View.

An action is an object that would change a store. A dispatcher holds callbacks and trigger all the callbacks when an action occurs. A store provides access to the models/database. A view is responsible for rendering the component in the UI.

We were able to use Flux and React today to create a cool Organ/Piano Grinder. My partner and I had a lot of fun with this project and we were able to set it up so that you could record a "track" as you played on the keyboard.

Today was our first day with Flux, an architecture for writing React frontends for web apps.

First, we learned about the fundamental components of the Flux architecture: the Dispatcher, Stores, React Views, Action Generators, and web APIs. Within React, we have to have some way of ensuring that our React components will re-render to reflect any relevant change in the state of our overall app or in response to user input, and these components allow us to do this. Crucially, however, information within the Flux architecture only flows in one direction: Dispatchers only ever send information to Stores, Stores to React Views, React Views to Action Generators, and Action Generators to the Dispatcher.

Within Flux, each React view registers a callback with whichever stores concern it when that view is mounted. Then, that callback is called by the store whenever that store's contents change, which is achieved through a call to its __emitChange method. In turn, each store is initialized by passing-in a dispatcher as an argument, which then sends a data payload to every store when it is insructed to dispatch an action by an action generator. And action generators are, in turn, called by React views in response to user input or changes in the app's overall state that need to be reacted to. So, when something happens that needs to be reacted to, an action corresponding to that change is generated and sent to the dispatcher, which then dispatches the data from that action to all stores, which then decide whether or not that data is relevant to what they store. If it is relevant, the store updates itself and then calls all of the callbacks that React views have registered with it, which in turn causes all affected views to re-render, thereby updating the state of the DOM. Although they're not always a part of this flow of data, Web APIs often play a critical role, as they allow the Flux architecture to access server-side resources (which are very often necessary for properly updating the state of our frontend) through Ajax requests.

Class Ramblings

Another day, another app, another trip through Backbone. I believe we are operating near fullstack - we have Rails for the back end, and Backbone for the front end. Which sounds unintuitive now that I wrote that out. 

After yesterday's project of making a pokedex, today was app was making a journal app. At this point I recognize many of these features are essentially the same thing - create a text object, call it Todo, Post, or Comment, then link it somewhere. Creating functionality is the game here - can I show it?  Can I show a lot of it? Can I make it, can I edit it, can I destroy? Linking all these up is a huge feat which  i hope becomes easier over practice. 

We worked on making things from the ground up and making routes and views. I actually really enjoy making these projects, it's just that I'm not as fast as I'd like - the problems I encounter aren't too mystifying. I feel all the pieces are there, and I have to piece them together. Time is the resource I unfortunately don't have much of...