#w7d3

[worldsokayestmother]

W7 / D3

Okay we had sex yesterday and I am still spotting. I also have that tight menstruation feeling. I know it's probably just spotting from the sex (it's dark brown) and the pain is from my uterus expanding, but it's still nerve wrecking

[worldsokayestmother]

W7 / D3

Will it look suspicious if I eat nothing but ice cream at work?

[psl646]

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.

We submitted our lists for our potential capstone projects today. I hope I get my top choice!

[dylanmeacham-blog]

App Academy: Week 7, Day 3

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.

There are obviously a lot of moving parts to Flux, but as with React itself, I can already see how advantageous using this architecture is compared to cooking up one-off solutions for updating our views' states.

[finalpen]

Music

Today we got keys on the page, it took us long enough, but they made sounds upon pressing keys on the keyboard. Yay! We used the flux pattern for this, which I must admit, probably used a lot more code than there needed to be. But I can see how this could protect a project from getting too complicated in the future.

[keldonia]

Making Music - w7d3

Today, we started to learn how to use Flux in the design and implementation of simple music app that allowed user to play two octives of a piano, play the notes being pressed and update the display at the time. The Flux pattern of development easied the ability to update and interact with multiple stores.

[haasalex16]

W7D3

Today we continued working with Backbone by building a Journal App on Rails. It was real good to start from scratch and see how Rails, JS, Backbone, and jQuery all came together. Other than the basic setup with Rails, we used Backbone for the views, router, and models which allowed us to do some pretty cool things, including an immediate editing option that was triggered by a double click on the field you would like to edit and we would seamlessly which the field to editable input. Today really showed the power of Backbone and how seamless it can make a site run.

[5millionsecondsofcode-blog]

3856121 seconds

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...