Selector Ingestion Design Document

Owned by Mikah Pinegar
Last updated: Jan 13, 2023
3 min read

Introduction

We are close to ingesting the MCCC, SCCC, and eventually WCCC. In order to do this we will need to update the front end to be more dynamic

Big Picture Changes

  1. The user will need to choose state (will infer council → region) → zone on application start up. Example: MCCC → Iowa → Adams

    1. Modal? Landing page?

    2. Ideally use IP address to guess zone and have an option to switch councils

  2. Info sheet will need to be generated dynamically

  3. Some features will need to be shown/hidden based on the council

  4. Will need to update about, help for each council

Questions for Brian / Sarah / Steven / Chris

  1. Can we make calendar view the default instead of list view for all regions? This would make the default flow more similar to the MCCC

    1. Yes

  2. Can we make the selector the default tab instead of the explorer? This will also make the default flow more similar to the MCCC

    1. Yes

  3. If yes to the above two, is it enough to have the default flow build the output the MCCC would expect but also add on some of the other features of the NECCC

    1. Map seems like they said was a deal breaker

    2. Explorer

    3. List view for selector

    4. My cover crop list

  4. Do we need to change the color theme and show the logo for each council or can we have one homogenous front end and not show logos?

    1. Yes we need to have colors match the council eventually

    2. v1 logo switch colors stay the same

  5. How much do we need to engage with all the councils as we’re making these changes?

Big Unresolved Questions

  1. Are we responsible for hosting MCCC site

  2. Do we need a national front end that has no logo or branding

  3. Does each council need it’s own unique tool hosted by us

Restructure How Data Dictionary is Used

Currently the data dictionary is used in

  1. TooltipMaker.js → only uses the goal descriptions, should be passed down as a prop or live in global state

  2. CropSidebar.js → uses the data dictionary to generate the sidebar object, should be done on the backend

  3. Header.js → filters to only return goals d.Category === 'Goals' && d.Variable !== 'Notes: Goals' from the data dictionary and then sets it in redux. generation should happen on the back end

  4. InformationSheetDictionary.js → uses all info sheet values where dict['Information Sheet'] === true || dict['Infromation Sheet'] === true should be filtered on the back end

  5. MyCoverCropComparison.js → only uses the goal descriptions, should be passed down as a prop or live in global state

We will probably want to make routes that return the subsets necessary for the above components or fetch the data dictionary once on zone change and store it in the global state

API Call Restructure Flow

We’ll need to get rid of the legacy object API calls and replace them with a sequence of smaller API calls

  1. Select state → (infer council, region)

  2. Get zones → select zone

  3. Get possible new route saying what features to show/hide

    1. Example MCCC has no map but NECCC has map

  4. Get goals (new route gets goals for council, region, zone combo) → select goal(s)

  5. Get filters (new route, returns list of filter and their descriptions. eliminates the need for TooltipMaker.js, Header.js, MyCoverCropComparison.js data-dictionary calls, handles generateSidebarObject logic on the back end) → generate sidebar

  6. Get crops → show list of crops, object contains all filters

  7. Get information sheet (new route, no longer legacy data dictionary, only returns values needed to build info sheet, excluding filters, description, sources, comments, etc) → on click of crop

  8. Get data dictionary (new route? generates object used to explain groupings of attributes) → on click of data dictionary