18 new jurisdictions via config

[jtmst]

#18

Adds ability to add jurisdictions by modifying the formsources.config file.

Changes:

• refactored main page component
• broke topic cards into their own component
• set up topic section and data query to fetch data based on jurisdiction
• set build up for dynamic routes for paths like /ma and /ma/housing
• add path data to config file
• Moves fetch functions higher in hierarchy to be at page level
• adds pathToServer config which allows assignment of servers to a given path
• Adjusts link tag behavior that that serverUrl is assigned to a given interview

Testing

• Navigate to homepage and not that the default suffolk data is there
• Naviagate to localhost:3000/gb and observe that the greater boston data is rendered
• Click card backgrounds and observer that the correct topic placeholders render
• Click tags and verify that correct app url is linked to
• Verify that tests/build work
• Note that the build output reflects the new pages

Build output log:

Greater boston cards at /gb:

Placeholder component for topics at new route:

Note: Also some changes to images in an effort to get them working on Pages. I dont have a way to test pages deployment locally so there may be some trial and error figuring out what the issue is there

[nonprofittechy]

Just wanted to double-check: it's possible for two servers to share the same path, right? Edit: and conversely, for one server to have individual interviews that go to different paths? See note below about the jurisdiction attribute.

[jtmst]

What do you envision determining which servers are associated with a given path, should that be a seperate config where each path has an array of servers they pull from?

[nonprofittechy]

It's important now that multiple servers can point to the same path, since we're thinking of the path as relating to the jurisdiction. The two example servers we're pulling from here are both in Massachusetts and would be syndicated to the same path.

In the future, we'd like to consider hosting a small number of forms for outside jurisdictions. For example: if we help Minnesota build 3 forms, it would be nice if those could go to courtformsonline.org/mn even if they're hosted on apps.suffolklitlab.org. That would be something we'd just do for relatively small numbers of forms.

I can also see multiple servers around the country having US-national level forms that should all go to the same path, /us/.

To get that outcome, I trust your judgment on the proper implementation.

Here's one path that might meet all of our needs for flexibility:

1. Each path is associated with a jurisdiction code or codes, and will show all forms matching that jurisdiction's codes
2. Each interview can specify the jurisdiction code or codes in its metadata (the JSON endpoint)
3. Each server has a default jurisdiction code, which will be used if the interview doesn't specify one

If this feature is getting too complex, happy to talk it through more and figure out the right tradeoffs.

[jtmst]

Gotcha, thanks for the clarification

[nonprofittechy]

How does jurisdiction correspond to the jurisdiction in the JSON endpoint, which uses the SALI/LMSS location descriptors? Are we planning to say all interviews from a server go to the same path, or can we categorize based on the jurisdiction in the endpoint, with perhaps a default path for each server since not all interviews will have a jurisdiction in the metadata?

E.g., US states look like:

NAM-US-US+MA

And Berlin looks like:

EUR-DE-DE+BE

(You can browse interactively here: https://webprotege.stanford.edu/#login).

Just want to check for consistency here--if this is jurisdiction, maybe we want to match the two formats, and map the jurisdiction code to a path. if it's just path, using the same variable name perhaps?

[jtmst]

I may just be using the term jurisdiction wrong. In this case I'm using jurisdiction to denote which path/server we are looking at. Rather than jurisdiction, what term should i use for the path (previously subdomain) ie /ma/ or /pa/. I'm assuming they wont always be by state or I would use that.

I do have this set now so that path to server is 1 to 1, but I see now that we need to allow multiple servers' data within a path. I will adjust and get those changes up

[nonprofittechy]

I think "path" is fine. Just think it will be helpful, if the path isn't identical to the jurisdiction code, to not use the word "jurisdiction"

[nonprofittechy]

I like these changes--looking good! Just two notes: consistency of the meaning of "jurisdiction" and double-checking that we can combine multiple servers into one "path", made inline.

[jtmst]

I like these changes--looking good! Just two notes: consistency of the meaning of "jurisdiction" and double-checking that we can combine multiple servers into one "path", made inline.

I've modified the config that that we can assign multiple servers to a path. I included /gb/ as a path for demonstration purposes, but i will delete that from the config before we go live. Adding new paths should be as simple as declaring in that config, and assigning it servers as they are added to the sources config.

I've also added in the necessary data to track the source server for an interview so that the link path aligns with its source.

Also changed misusage of 'jurisdiction' to 'path' for clarity