frc1418 / tbago Goto Github PK

First issue to address: backward compatibility. In an ideal world, we could just iterate the version number and everything would be good to go.

A quick fix for now could be to create a different client struct called something like TBAClient.

For example, when invalid arguments are passed.

Match data is quite complicated, and handling it through a statically typed language like Go can be troublesome.

The score_breakdown JSON property is particularly problematic here. A typical match request might yield the following JSON:

"score_breakdown": {
    "blue": {
      "adjustPoints": 0, 
      "autoFuelHigh": 0, 
      "autoFuelLow": 0, 
      "autoFuelPoints": 0, 
      "autoMobilityPoints": 15, 
      "autoPoints": 15, 
      "autoRotorPoints": 0, 
      "foulCount": 0, 
      "foulPoints": 0, 
      "kPaBonusPoints": 0, 
      "kPaRankingPointAchieved": false, 
      "robot1Auto": "Mobility", 
      "robot2Auto": "Mobility", 
      "robot3Auto": "Mobility", 
      "rotor1Auto": false, 
      "rotor1Engaged": true, 
      "rotor2Auto": false, 
      "rotor2Engaged": true, 
      "rotor3Engaged": false, 
      "rotor4Engaged": false, 
      "rotorBonusPoints": 0, 
      "rotorRankingPointAchieved": false, 
      "tba_rpEarned": 0, 
      "techFoulCount": 0, 
      "teleopFuelHigh": 8, 
      "teleopFuelLow": 0, 
      "teleopFuelPoints": 2, 
      "teleopPoints": 82, 
      "teleopRotorPoints": 80, 
      "teleopTakeoffPoints": 0, 
      "totalPoints": 97, 
      "touchpadFar": "None", 
      "touchpadMiddle": "None", 
      "touchpadNear": "None"
    }, 
    "red": {
        "same properties as blue"
    }
}

The issue is that the properties of blue and red are different across games.

The only solution I can currently see to this is to write every possible property into the Match struct.

Currently we use this horrible placeholder.

        ScoreBreakdown struct {
		Red  interface{} `json:"red"`
		Blue interface{} `json:"blue"`
	} `json:"score_breakdown"`

We should not stay with this terrible solution.

There are a great many TBA endpoints which allow fetching of a list of keys rather than a list of data. These are unsupported thus far by tbago.

The endpoint team/frc1418/event/2017vahay/matches supports this; but it's impossible through the current library structure.

Currently we direct users interested in a full list of available requests to look in the source code. This isn't terribly hard, but we should provide a list up front in the README.