lihnick / fantasycivics Goto Github PK

Can be a separate page in app.

Bring together the pages implemented by the rest of the team into a webpage the test users can play during the demo. @geliclub will combine the pages and @vingkan will test and add any finishing touches.

Use the global variable Database.Scoring.DATASET_NAMES to get all of the keys of datasets being used and their user-friendly names. Loop over this map when working with scores to make sure the application doesn't break when different datasets are used.

Show number of wins and losses of users.

@lliu78 the html that needs styling is at master/app/style.html each row of the second table has its own dropdown menu, an example check out lines 110-113, it might be helpful to reference W3School when making the dropdown menus.
There are a lot of rows in the second table, but you don't have to apply styling to all of the rows, first few rows would suffice, or you can delete some of the rows in the second table.

GetMatch does not include the edge dates of the week.

Database.getMatch({
    userid: "TuQ9fy55KOTCN0MDkfbYmIFKI3n1",
    leagueid: "-KdtAsc7h1vKNUAhX9ru",
    on: 1486792800000
}).then(console.log);
// returns error

Database.getMatch({
    userid: "TuQ9fy55KOTCN0MDkfbYmIFKI3n1",
    leagueid: "-KdtAsc7h1vKNUAhX9ru",
    on: 1486792800001
}).then(console.log);
// returns 
{
away: "testuser0005"
end: 1487196000000
home: "TuQ9fy55KOTCN0MDkfbYmIFKI3n1"
leagueid: "-KdtAsc7h1vKNUAhX9ru"
on: 1486792800001
start: 1486792800000
userid: "TuQ9fy55KOTCN0MDkfbYmIFKI3n1"
week: 1
}

Database.LOCK_ROSTERS_AFTER prevents editing on games that start in the past

Since the application is entirely implemented with client-side code, there is no consistent process running to execute tasks like locking rosters and, more crucially, determining the outcome of matches.

Some solutions I have considered and short explanations of why I didn't pursue them further:

• Write a server process to handle such tasks (considering this a last-ditch solution)
• Determine match outcome upon observation by a client (couldn't ensure consistency of information)
• Store event tree and derive outcomes from it (could severely slow Firebase reads)

I have implemented locking using relative timestamps (#10), leaving the task of determining match outcomes, which may still involve saving locked somewhere.

New focus: find a data structure that could store historical rosters for users and allow game outcomes to be derived properties. The trick is to do this without slowing down Firebase reads. The two main threats are deeply-nested data or having to enter a separate Promise to read from another set of nodes.

The data structure could be updated with "fresh" rosters anytime Database.isLocked() is called. This function is used in all methods that modify rosters and it is expected to stay that way. The function is called before the actual change, so this may not be a perfect solution.

Style the roster page from #12.
@geliclub will provide @lliu78 with a fully static HTML page that matches his markup to allow development of styles.

Rank users by record with head-to-head as a tie-breaker.

Fire an event when rosters change in the league to allow the app to know when to update its views for what players are free agents. Listener will tell client when data changed, but not what data changed.

Users should be able to:

• See the outcome of a match

No styles are needed for this task. See long term information in #11.

Can include info about the goals of the game and rules

Putting in a non-Chicago address leaves the Alderman blank with zero points - should create an error

If there's no more game left in the league, an error will be thrown when trying to get the data. Roster page should instead catch the error and get the information but now allow any edits

Users should be able to play a game similar to the game played with spreadsheets in ChiHackNight Demo 1, except as much of the process as possible should be automated.

More specifically, the team is responsible for, at a minimum, delivering these features:

• Show roster
• Edit roster (add/drop and sit/start)
• View free agents
• View historical scores
• View change in scores
• View match outcome

Each team member is responsible for:

• Vinesh: explain database documentation when needed, automate match outcome calculation, facilitate demo
• Nick: implement barebones roster edit page, stitch pages together for demo, observer demo users
• Yuan: implement barebones player data page, observe demo users
• Li: style roster edit page, observe demo users

Users should be able to:

• View their roster, player scores, and player status
• Sit/Start players on their roster
• Add/Drop players on their roster

No styling is required for this task.

Users should be able to:

• View free agents
• View historical scores
• View change in scores

No styling is needed for this task.

If a player moves their own rosters by benching and starting their own players, this will make a change that will trigger the asynchronous function. This means that other users will experience an "refresh" (pulls all player from database, resort, and filter) whenever one users edits their roster which doesn't affect the ownership status of all the players.

Having this update could mean use more of the bandwidth, especially when users change ownership of players by adding or dropping players(when its actually important to update).

Without it could mean that we would not know what the other player is putting on their starter/bench.
If user1 swaps: (player1, benched), (player2, starter) => (player1, starter), (player2, benched)
user2 would not get that update until someone adds/drop so they would still see:
(player1, benched), (player2, starter)

• A proper function to update vue object in the dom

• Event Listener for updates made by other users in the league

• Scoring System Agnostic