Pipes - Rebecca - Ada Trader

[rbergena]

Ada Trader

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
How do Backbone Views help structure your code?	Backbone views help structure my code by communicating between the models/collections and the DOM.
Did you use jQuery directly in your Views? How, and why?	No, I used this.$el because I was always working in the context of whatever element my view was set in.
What was an example of an event you triggered? Why did you need to trigger it?	I triggered an event when the quote changed so that the open order list view could then check the open order with the symbol matching the changed quote to see if the open order needed to become a trade.
In what ways is unit testing in JavaScript similar to unit testing in Ruby? In what ways is it different?	They both use matchers to test the expected output of a test and they both use describe and it; however, expect is slightly different.

[droberts-sea]

Ada Trader

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene	yes
Comprehension questions	yes
Organization
Models and collections are defined in separate files	yes
Code that relies on the DOM is located in or called by $(document).ready	yes
Functionality
Quote prices change when clicking Buy and Sell	yes
The Trade History updates when buying and selling a quote	yes
A user can create an open order using the Order Entry Form	yes
An open order removes itself from the open orders and updates the Trade History when fulfilled	yes
General
Has separate views for different parts of the app	yes
Uses events (listening/handling and triggering) to manage different behavior in views	yes - looks OK (and certainly works) but the bus is somewhat overused - see inline comments
Practices good standards for views (ES6 syntax, doesn't directly use jQuery, returns this in render)	yes
Error handling for the Order Entry Form	yes
Testing
Has unit tests for models	yes
Overall	Good job overall! Event-driven programming is an important tool for the modern software engineer, especially in an asynchronous context like front-end JavaScript. It's also very different than the message-driven paradigm we've studied so far Designing such programs is a unique challenge, as is knowing when and when not to use event-driven techniques. Keep studying and thinking about them, always trying to come up with cleaner, more robust designs, and keep up the hard work!

[droberts-sea]

You don't need to wrap the call to forEach with a check that length >= 1. If the list has zero elements, then the loop body will execute zero times.

[droberts-sea]

Instead of using an event on the bus to get the quoteList, why not pass it in as an extra parameter when instantiating the OpenOrderListView? Building an event for it is overkill.

[droberts-sea]

Currently, the workflow for executing an open order looks like this:

1. Quote price changes
2. quote_change event on the bus
3. Handled here by OpenOrderListView.checkOpenOrders()
4. Find OpenOrders matching the quote
5. For each one, determine if it needs to be sold

But we can simplify this! The key observation is that each OpenOrder already knows which Quote it's for - we need this information to validate the OpenOrder. Instead of working through the intermediaries of the bus and the OpenOrderListView, each OpenOrder could listen directly to its Quote for price changes. Then the workflow would look like:

1. Quote price changes
2. Event on the quote
3. Handler in OpenOrder
4. Determine if the order needs to be sold

This eliminates dependencies on the bus and the OpenOrderListView. It also simplifies the code, since we don't need to work with a list of OpenOrders. If there are multiple OpenOrders corresponding to the same quote each will have a separate handler registered, and each will run when the event occurs (steps 3-4).