tsdataclinic / data-gather Goto Github PK

Create a view that allows inputting required information to connect to Airtable.

Airtable requires the following to connect:

• API key (one per account)
• Base ID (unique per each airtable base)

Info should be saved somewhere so repeat information isn't required to be inputted. Probably also want to make viewing/editing behind authentication when that's ready

Also, reading/writing to tables/columns requires knowing the table/field IDs (you can get these from the API docs specific to the account). So need to come up with a way to get that information so interview-app can read/write. Airtable has a metadata API https://airtable.com/api/meta but it is not open access and requires applying to a waitlist https://airtable.com/shrWl6yu8cI8C5Dh3

This is a very broad task. We need a general representation for all types (e.g. an Interview, a Screen, etc.) that we will use in the frontend.

We also need a standard JSON schema for how an Interview will be represented when exported. It's likely that there will be minor differences between the TypeScript types and the JSON schema. For example, in TypeScript we will want any date fields (e.g. if we track a createdDate field) to be an actual Date type, whereas in JSON this will have to be a string). Are there other differences we should expected between the TypeScript types and the JSON schema we need to output when publishing an interview?

Blocked on scoping out what Airtable operations we want to support and how that will translate to "Interview" configurations

Do the same for when "New Question" is clicked.

• Medium
• Notes
• Data Collection
• Default Sequence
• Write information back using API layer

This action is used to skip whatever the next screen will be. In doing so, we can choose to push our own hardcoded response.
This UI is where we can configure what response will be automatically recorded. The UI can be something like this:

After submitting the modal, an Interview should be created in IndexedDB, and we should now be in the Interview page where the user can now configure the entire interview

For example, clicking on an Entry should scroll the page to that Entry in the interview page.

• Toast on save
• Toast on New Interview

• Allow multiple Entry blocks
• Prompt section: type and text
• Response section: ID and type
• Write to db using API layer

Follow the FastAPI docs to set up a basic server: https://fastapi.tiangolo.com/tutorial/first-steps/

• Create the server in a server/ directory
  So our top level will have 3 directories now, looking like this:

public/
server/
src/

• Add a single endpoint for now in the API. By convention we should have a GET endpoint that just tells us that the API is up and running. Add an endpoint at /api/health that just returns text "Server is up"

(A "health" endpoint is a good convention for when you need to set up automated tests, or CI/CD, to validate if the API server is up and running)

• Set up a postgres database and basic SQL Alchemy models.
• We should have 4 tables/models: interview, interview_screens, interview_screen_entries, conditional_actions
  If you go to src/models/* you will see the TypeScript models we've been using. Each of these models has a Serialized* interface that represents what we should be storing in the backend. Use that type to model your SQLAlchemy classes. Feel free to change any member names if necessary (e.g. if Python/SQLAlchemy convention is to use underscores rather than camel case).
• Add some way for the tables to get created. Do you need to add a script? Does SQLAlchemy auto-create the tables when the server starts up? Unsure. But we'll want some easy way for developers to set up their postgres
• Add any necessary documentation if there are commands developers need to run (e.g. to start up postgres).

No need to add any other functionality yet to populate the databases. Just creating the database and tables is enough for this issue!

• Make each screen tab expandable
• List Header, each Entry, and Action when a tab is expanded

• Core UI components
• Schema & type definitions
• Basic API layer with IndexedDB
• My Interviews page
• Adding/Deleting a new interview
• Full UI implementation for the Interview page

• Changes to the milestone payload (currently just an input text box) should persist when saved
• Ask Izaak what this checkpoint means in terms of an Interview, in case there is more UI we need than just a string. For example, is this a freetext string, or are there constraints to it?

• Changes to the checkpoint payload (currently just an input text box) should persist when saved
• Ask Izaak what this checkpoint means in terms of an Interview, in case there is more UI we need than just a string. For example, is this a freetext string, or are there constraints to it?

Even though Actions are now persisted, they do not update on the left side bar yet. We want the sidebar to show Actions similarly to how we expect Entries to get listed there.

As for what label to use, we can just use "Action: Push" or "Action: Skip" (you should be able to use actionTypeToDisplayString to turn the ActionType to a string)

We do not have to follow this hierarchy, but this is an example hierarchy:

class IndexedDBWrapper {
  // wraps Dexie
}

class ServerAPI {
  // does actual calls to our server
}

// this is what the user would call
class API {
  constructor() {
    this.browserAPI = new IndexedDBWrapper();
    this.serverAPI = new ServerAPI();
  }

  getInterview(interviewId: string) {
    return this.browserAPI.getInterview(interviewId);
  }
}

Then in our React components we would never call IndexedDB or Server directly, we would use stuff like API.getInterview()

Then when it's time to switch from the browser to server's API it's as simple as just changing the functions in the class API

NOTE you do not have to use any of the names I just used for the classes. This was just an example to illustrate my point. Name things however you want. And structure things differently if you have a better idea!

Also, now that we use a single "Save", we can simplify the API to just use a updateScreen function that saves the entire thing.

When "Always execute this action" is unchecked we get the conditional operator row. The "Condition" dropdown is currently hardcoded to just show "Response Key 1" and "Response Key 2"

This dropdown should instead use the ids from:

• All Entries. Go through all entries in all screens and extract their ids.
• All Actions whose type is "Skip". A "Skip" action has a payload that stores response data (the idea is that if something gets skipped, this action will insert some default data into the response log). Use the keys of this payload object as response keys to include in this "Condition" dropdown.

Changes to the milestone payload (currently just an input text box) should persist when saved
Ask Izaak what this checkpoint means in terms of an Interview, in case there is more UI we need than just a string. For example, is this a freetext string, or are there constraints to it?

Need to decide where in the design this button should go, but there should be an ability to delete an interview.
After the interview is deleted we should be directed back to the "My Interviews" page

What operations should a user be able to do with Airtable and how does it translate to an "interview" operation?

For example, we know that we need to allow Airtable lookups. What does that mean in terms of our Interview UI?
We will need to add a new Entry type that is called "Lookup" and then what? What configuration will be needed for it? Selecting a table name? A column name? Etc.

What about for other operations? For example, we'll likely want a conditional action to write back to Airtable. How does that get configured?

We need to scope all this out.

• Local ActionCard edits should change modifiedActions
• Add Save button for backend persistence (write back to DB using API layer)
• Add actions to sidebar
• When "Always Execute" is unchecked it goes off container
• Update Payload UI based on selected action type
• Make it scrollable when new action is created

This will require working closely with Pablo to figure this out.

Azure AD B2C is the authentication service that security has approved for us. So far we use it in only one other app and it's in NodeJS. This will be an adventure to figure out with Python.

Blocked on a multiselect UI component being created

Write to DB using API layer

When an Action type is changed, the Payload UI should change. Right now, only "Push" is working. (We let you select a screen to Push. Technically we should let you select multiple screens, but until we have a Multiselect component we will leave it at this)

• Checkpoint, Milestone, Restore: for now all of these action types should just render an InputText
• Skip: for now, this action type should just render two InputTexts. One input text is the Response Key, and the second is the value the user wants to store. In terms of datatypes, the payload will just be a single-item object { [key]: value }

You'll want to update the renderEditor function in ActionConfigEditor after #52 gets merged. That function has a switch block that renders a different UI based off of the action type.