Validate a Football Starting Eleven from Lineup Data

Let the team sheet determine the lineup

A squad list and a confirmed match lineup answer different questions. A player can belong to the squad without appearing in a specific fixture, and a substitute can appear in the lineup response without starting. Build a starting-eleven view from the match lineups operation and its is_starter values, using the selected match ID as the scope.

Check coverage.lineups_available before presenting the result as supported. Then inspect the returned teams and players. An empty list does not justify copying the previous match's eleven or promoting likely players into confirmed starters. A prediction belongs in a separately labelled feature with its own evidence.

Separate identity, role and display position

The lineup response includes player id, name, position, shirt_number, grid and is_starter. Use the ID for joins and is_starter for the starting distinction. Shirt numbers can change and names can collide. Position and grid can be null, so a list view should remain usable when a pitch diagram cannot place a player reliably.

The example partitions one synthetic team sheet into starters and substitutes and rejects a repeated player identity. It deliberately uses only three players to demonstrate the transformation. That fixture is not a complete eleven, and the returned list length must not be represented as proof of a complete real team sheet.

Run the reproducible example

This Python 3 example uses deliberately synthetic inputs, not a downloaded match or a forecast for a real fixture. Save it as example.py and run python3 example.py. It uses only the standard library and its assertions check the behavior discussed here. Replace the fixture inputs with validated API records when connecting your application; demo identifiers are not production lookup values.

def partition(players):
    ids = [p["id"] for p in players]
    if len(ids) != len(set(ids)):
        raise ValueError("duplicate player in team sheet")
    if any(type(p["is_starter"]) is not bool for p in players):
        raise ValueError("starter flag must be boolean")
    return {"starters":[p for p in players if p["is_starter"]],
            "substitutes":[p for p in players if not p["is_starter"]]}

players = [{"id":"player_a","is_starter":True,"position":None},
           {"id":"player_b","is_starter":True,"position":"D"},
           {"id":"player_c","is_starter":False,"position":"M"}]
result = partition(players)
assert len(result["starters"]) == 2
assert result["substitutes"][0]["id"] == "player_c"
assert result["starters"][0]["position"] is None
try:
    partition(players+[players[0]])
except ValueError:
    pass
else:
    raise AssertionError("duplicate accepted")
print({k:len(v) for k,v in result.items()})

Read the result

The projected fixture produces two starters and one substitute, preserving the unknown position. The duplicate test fails as intended. The example validates partitioning and identity rules, not whether a real match has published its final team sheet.

Model completeness separately from rendering

For a normal association-football starting lineup, eleven starter entries are a useful expectation to inspect, but hard-coding every response into an eleven-player picture can hide incomplete or unusual data. Store a state such as awaiting team sheet, partial observation or observed lineup according to your validated product rules. Display the actual returned entries while making incomplete coverage clear.

Formation is a returned display value, not a guarantee that every player has a valid grid coordinate. Keep a list fallback, show the team identity beside the entries, and avoid inventing coordinates from names or shirt numbers. Null coach or formation values should not break the rest of the view.

Refresh without mixing fixtures

Key each saved lineup by match ID and team ID. When a user moves to another match, clear or visually separate the old response so a slow request cannot paint the previous team sheet onto the new fixture. Retain the retrieval timestamp and replace the snapshot when a newer validated response arrives.

Test missing coverage, an empty team list, null positions, duplicate IDs and a complete synthetic eleven. Keep player-statistics joins separate: starting a match does not itself prove a particular minutes total or performance. Those observations belong to the player-statistics operation and may arrive or change on a different schedule.

Connect this to your project

Connect the transformation only after resolving a real fixture. Inspect the lineups schema in the public contract, keep the list fallback, and test your loading states alongside the successful response. The existing fixtures-widget article provides a useful server-to-browser architecture for keeping credentials private.