Add conventions document

[bchrobot]

Is your feature request related to a problem? Please describe.

It is difficult to work on a large codebase with missing or competing conventions.

We have prettier to enforce a single code format and eslint to enforce some style choices/conventions but they do not capture everything.

Describe the solution you'd like

Add a conventions.md document with codebase conventions and style guidelines to capture things that prettier and eslint do not.

Describe alternatives you've considered

Custom eslint rules.

Additional context

Running list of things to include:

• Component props interface names should be [ComponentName]Props, not just Props.

[bchrobot]

@politics-rewired/spoke-rewired thoughts on what else to include in the first draft of this?

[bchrobot]

• Exporting props type definition for components

[bchrobot]

How we handle GraphQL errors under different circumstances.

• fetching data for display: inline list of errors, using MUI <Alert> component
• performing an operation from a button -- modal with error? MUI <Snackbar> component?
• performing an operating from within a modal -- inline errors at top of modal?

[sync-by-unito]

➤ Benjamin Chrobot commented:

• Directory structure

[ajohn25]

How we handle GraphQL errors under different circumstances.

• fetching data for display: inline list of errors, using MUI <Alert> component
• performing an operation from a button -- modal with error? MUI <Snackbar> component?
• performing an operating from within a modal -- inline errors at top of modal?

Just mentioning #1270 to link the discussions together

[ajohn25]

• Up to a single style for inline CSS - otherwise use makeStyles hooks. See feat(campaign-interaction-steps): add save button to top of section #1610
• Affirmative variables for component behavior (show, enable, etc.). See chore(10dlc): update notifications #1606