For some preliminary information, see the deprecated PR #141

Make sure to move all default values, color handling and similar functions from StrapiDataProvider to either vaa-data or the interface between DataProvider and the data model.

Notes from EE 2024 VAA project

In the first implementation, this could also include a proto vaa-data model that enables the functionalities necessary for the 2024 EU Elections VAAs, roughly:

• Election (for the time being, we can just use a single one)
  • Constituency (ditto)
    • Candidate (extends Entity)
      • nominatedBy: Party[]
      • memberOf: Party
      • getAnswer(q: Question)
    • Party (extends Entity)
      • candidates: Candidate[]
      • getAnswer(•)
  • QuestionCategory (includes info and opinion questions)
    • Question
  • Answer
    • asString() (does the same as the getDisplayedAnswer utility now)

These would implement the requisite interfaces of vaa-matching.

DataProvider would return objects that can be converted into these objects.

The Svelte components would accept objects that extend these objects, thus:

// SSR: +layout.server.ts
const dp = new StrapiDataProvider();
const electionData = dp.getElection(); // Get the default election
const constituencyData = dp.getConstituencies({electionId: electionData.id}); 
const candidatesData = dp.getCandidates({constituencyId: constituencyData[0)].id});
return {electionData, constituencyData, candidatesData};

// CSR: +layout.ts
const {electionData, constituencyData, candidatesData} = data;
const root = new DataRoot();
root.provideElectionData(electionData);
root.elections[0].provideConstituencyData(constituencyData);
root.elections[0].constituencies[0].provideCandidateData(candidatesData);

// Component: ElectionCard.type.ts

export interface ElectionCardProps {
  election: Election;
}

// vaa-data

export interface Election {
  /* Props and methods */
}

class Election implements Election {
  constructor(data: ElectionData) {}
  /* Implementation */
}

Open questions

• Whether to enable fancy object arrays with id search
• Whether to contain the data as a prop of the object to avoid copying
• Custom properties
• DataRoot.getCandidates() and similar shortcuts that return candidates in the default or current Election and Constituency.
• Whether it is useful to parameterize all of the objects with a StringType so that the same types can be used for display in the localized Voter App and for editing in Candidate and Publisher Apps.

interface Question<StringType extends string | LocalizedString = string> {
  text: StringType;
  /* Other props */
}

const question: Question; // In the Voter App
const question: Question<LocalizedString>; // In the Publisher App

• In the early draft implementation the constructor parameter FooData is stored inside the Foo object proper and accessed with accessor functions. This removes the necessity to make copies of the data.
  • Check if there are possible issues with this
  • Check if we can use parameterized types to remove as much of the redundancy as possible from Foo and FooData definitions