Game page should show recently edited games

[mliu7]

The game list page should show recently tracked games for easy access.

Right now there is no "game list" page and instead it shows a prompt to search for a team or a tournament. This behavior is good for a new user, but for a user who has already entered events, it should show a list of games that they've tracked stats for in the past.

[cboulay]

Do you plan on including an additional search field in the API (e.g., tracked_by_user_id) or is it up to the app to know this? The way I was planning on implementing the WebSQL store would only allow information to be stored if it is also stored in the API (i.e., it would use the same toJSON() to clear out unsaved attributes). If it is up to the app to store which games were recently tracked then we'll need a new localStorage entry: tracked_game_ids with maximum length 20 and that is always in the order in which they were last accessed on the trackGame page.

Currently, how we might do this is as follows: Upon matching the trackGame route, the app will access this localStorage entry, and if this game_id is already in the array then it will remove it, else it will remove the oldest (if length >= 20). Then it will push this game_id to the top. Upon matching the /games/ route, it will load the 20 game_ids from localStorage then create a new collection passing 20 (skeleton) game models, each model having its id set with one of the game_ids. When the new collection is fetched, it will generate a URI that uses these game_ids.

If the #6 WebSQL layer interprets the URI string parameters as the API does, then this plugin would not work with any other API, and it would require considerably more code. Instead I think the WebSQL layer needs to pass the collection.fetch() off to Backbone's AJAX sync normally, but not until after iterating through the models in the collection and hydrating them individually from the data in the WebSQL store.

[mliu7]

Yes, I plan on including an additional search field in the API. Sorry for making you think about this, I should have described my intentions further.

For any API resource, a user will be able to filter by who created it on a field called "created_by". This field will take in a list of player IDs and return any items that were created by any of those players. For fetching the Player object of the currently logged in user, we will create another resource called something like "me". A GET call on that resource will return information for the logged in user.