FE: Lovell support multiple list pages for event, stories, and news

[swirtSJW]

Handle lists for Lovell

List pages for the following content types, need an approach to handle Lovell list items that appear in Lovell, VA, Tricare

• Stories
• events
• news release
• ~staff~ staff lists work differently and do not need special handling

AC's - Option C added 9/12

CMS side

Build three Lovell flavors of the list pages (both, va, tricare)

• [x] Stories
• [x] events
• [x] news release
• [x] staff

FE

• In the build step (where bifurcation is already happening) copy the list data from the 'both' list
• For each of the list type pages in Lovell
  • [ ] Stories
  • [ ] events
  • [ ] news release
  • [-] ~staff~ Removed from AC 9/22/22
• Do the following.
  • When building Lovell TRICARE list pages, grab list items from Lovell Federal (both) and append to list item data on the page.
  • When building Lovell VA list pages, grab list items from Lovell Federal (both) and append to list item data on the page.
  • list data might need to be re-sorted after appending (not sure if sort in graphql results figures into on-page rendering)
  • some list data will need to be re-pathed after appending.
• Delete the page Lovell Federal (both) so that the page does not get built
• All platypus code lives in the build step with the rest of the platypus code

outdated items ignore all below this.

~This one needs discussion. (meeting being set up with facilities, pws and sitewide) - 8/15 meeting had. This solution of multi-select will NOT be rolled out to all lists.~

~I will thread out some options in comments below.~

[swirtSJW]

Meeting concluded with multiselect not being a solution that would be rolled out to all lists in all systems. Our solution will have to just be limited to lovell.

[swirtSJW]

Option A

• Create separate lists for Lovell VA and Lovell tricare
• Expand all items to allow multi select but then override for any that are not in Lovell to behave like single select (JS magic)
• Alter FE list queries to support multi select
• Would need graphql changes to all list types

Cons:

1. Tech debt on the CMS editorial interface side.
2. A lot of graphql and frontend work (but not tech debt)

Pros:

1. Impacts all list content types and their associated graphql queries.

[swirtSJW]

Option B

• Exempt Lovell lists from the existing build.
• Generate all the json data for both events, and then make the static pages use the same data source
• Create widget to consume / parse the json.
• Widget gets put on lovell and lovell tricare list-like pages

Cons:

1. A lot of custom code scattered about.
2. No real existing patterns for this

Pros:

1. Gets us closer to a model we want for all list pages in the future
2. May be able to use NextBuild for this as a POC
3. Data is open as it would have static data source file exposed.

[swirtSJW]

Option C

• Build three list pages. (both, va, tricare)
• In the build step (where bifurcation is already happening) copy the list data from the 'both' list
  • append it to the Lovell Tricare list
  • append it to the Lovell VA list
  • list data might need to be re-sorted after appending
  • list data might need to be re-pathed after appending.
• delete the "both" list so it does not get built by itself

3 list pages, VA, Tricare, Both For example, When a person creates an event it can appear on THIS location page - need to create a placeholder BOTH page that is never built, but from which the individual pages will populate when they are built

• Locations
• News Releases
• Events
• Bios/Staff lists
• Stories

Cons:

1. ??

Pros:

1. All platypus code lives in the build step with the rest of the platypus code

[davidmpickett]

Sounds like Option C is the winner!

[swirtSJW]

Updated ACs to remove staff lists as they function differently and do not need special handling.

[swirtSJW]

Adding this diagram that I created for PR feedback so that we can refer back to it in the design