crockagile / legislator-lister Goto Github PK

Currently, the address input list leaves the user input state management to each child component. However, because manipulation of the address input list components destroys their children's input states, the state should be moved up to be owned by the address list. Currently blocks #2

Currently columns are unlabeled which leads to confusion. The user input should be clarified in someway.

Ideas:

• Have first element prefilled with example address and resolving officials to the right
• Add headers to the columns

Upon clicking an officials query result, a popup layer should display as much information as the Civic API provides.

Currently the number of address inputs is statically set to 10. The input list should be dynamic to allow users to set whichever size is convenient for them.

As a means to re-familiarize with redux and simplify operations, the state management should be transitioned to redux.

Currently, the Civic Query result parsing assumes that each civic office is filled by only one official. Although this works for the minimum use case, it will need to be fixed before #4 and #5

Specifically, the following code in components/CivicQuery.js holds the incorrect assumption:

queryResults = this.state.offices.map((office, index) => {
  const official = this.state.officials[office.officialIndices[0]]; // <-- Gasp!
  return <CivicQueryResult official={official} office={office} key={index} />;
});

Currently the civic levels queried are statically set to "administrativeArea1", but the Google Civic API supported list is larger:

• "administrativeArea1"
• "administrativeArea2"
• "country"
• "international"
• "locality"
• "regional"
• "special"
• "subLocality1"
• "subLocality2"

However the main user likely only will be using "administrativeArea1", so the selector should default to that selection.

Currently the civic roles queried are statically set to "legislatorUpperBody" and "legislatorLowerBody", but the Google Civic API supported list is larger:

• "deputyHeadOfGovernment"
• "executiveCouncil"
• "governmentOfficer"
• "headOfGovernment"
• "headOfState"
• "highestCourtJudge"
• "judge"
• "legislatorLowerBody"
• "legislatorUpperBody"
• "schoolBoard"
• "specialPurposeOfficer"

However the main user likely only will be using "legislatorUpperBody" and "legislatorLowerBody", so the selector should default to that selection.

The main user has asked if importing a CSV file would be possible. The exact format of it is still undefined, but they will provide an example file in a few days. This issue will be updated then.

Because the main list component is effectively the main data store, the query component should not own the results of the address search. Instead, successful data should be passed via callback to the component owning the addresses.

The query component should have following states:

1. pending search (request in flight)
2. search result received and passed to callback

In order to reduce network requests as addresses are typed, the input should be debounced. To fill this roll, a DebounceInput component should be made with the following behavior:

Properties

• debounce, the duration of time in milliseconds by which the input should be debounced
• inputHandler, the callback function which should be invoked when input passes the debounce period

At some minimum width resolution, the legislator query and its results should begin to stack vertically rather than horizontally.

The main user would like to be able to export the list in CSV format. Apparently client only file saving has a complex history of deprecation and browser support. Initial research seems to point at using the File Save polyfill.

Another option may be to just output the CSV text into a textarea and leaving the user the option to copy & paste as needed.

When debounce component unmounts it should cancel its timeout if active.