This method uses url query params to detect when the page should be in
edit mode. There are two issues with the current approach:
1. The url query param is actually a pretty unintuitive pattern. It's
disorienting to hit the back button and have it take you from edit
mode to view mode rather than returning to the main task list.
2. The submit button does return the user to view mode, but caching
results in the need for a refresh to see the updated task record.
This can be solved.
Existing date fields in the tasks table have been changed from TEXT to
INTEGER with mode set to timestamp. This will simplify date storage.
There were a number of issues encountered with storing dates as typed
strings.
The `upsert()` method can both create and update tasks. The method
checks for an `id` propery to determine whether to `INSERT` or `UPDATE`.
A successful operation returns a `ServiceResponse` object with the
inserted task `id`, which can be used to fetch updated information if
needed.
The `NewTask` type is exported for use in form actions, etc.
The only breaking change here is the 'tasks' field is now 'data'. All
other changes were made to improve TypeScripts ability to infer complex
types or internal abstractions that don't affect client consumption.
`getByTaskId()` takes an array of strings. It is parsed into task prefix (e.g.
"TA") and task_id. The database is then queried on an array of task_ids.
The result is wrapped in an object with a status code. Currently, the
code is hardcoded as "ok", but can be fleshed out when additional
features are implemented.
There are a few features missing:
- Validation that each string is the right length
- Validation that syntactically valid prefixes and ids were passed
- A check that all requested records are returned
- A check that task prefixes actually exist in the config (requires
implementing the config module)
- Proper status codes
`getByDbId()` takes and array of id numbers. The database is then
queried with this array. The results are wrapped as above.
Missing features:
- A check that all requested records are returned
- Proper status codes
Both methods return `{status: "failed", error}` when the database
request throws an error.
Database interactions will be handled by service classes. Service
classes will be called by page load functions as well as by API
endpoints. This will allow one source of truth for authorization and
data validation.
One of the sql generations mistakenly looked for a field value of '?'.
Whatever code was causing this to occur is no longer an issue. This does
highlight the difficulty of needing to delete or modify faulty migration
files.
