Currently, we fetch all unapproved transactions.

The web UI doesn't let us generate unapproved transactions 😔 (Those are for imported txns from banks, etc, that haven't been approved by the user)

The get-transactions API supports filtering on nothing, unapproved, or uncategorized.

For now, let's just make a checkbox which controls whether or not we only fetch approved transactions. Perhaps then, we can build an "unapprove" button that undoes an approval (and lets us create test data more easily 😎).

Currently the approve button just tacks on "(approved)" to the transaction name.

Add an unapprove button, and, wire them up to the API.

Expected result: can approve / unapprove transactions.

The transactions list shouldn't need to worry about whether or not it's loaded. Let the container worry about that. The list should just react to changes in a passed in observable list.

If the process env doesn't have the YNAB_ACCESS_TOKEN entry then a class cast exception occurs when casting it to string.

Fail more gracefully, for example assert its existence before trying to use it.

(What about auth errors? 🤔 At least those should come back in the network console)

When a transaction is already split, change the split icon to unsplit. (make button style secondary as well?)

Add this icon to a layer: https://fontawesome.com/v6/icons/slash?f=classic&s=solid

Unsplit should pop a modal asking to pick which category to unsplit into.

I deleted these by mistake and don't know how to get it back just yet.

Recording this so it doesn't get lost.

Pop up a modal, or whatever KVision allows(??), to edit the category on a transaction. It should be something simple like a drop-down of category names. (cat-group > cat-name)

Also: hide this button for split categories (see #16 for the unsplit work there)

After #12 , we update the app's data store from the YNAB API response, which triggers a re-render.

In the meantime (in between issuing the call and getting the result) we should lock up the transaction with a loading state.

Right now, it uses nullability to indicate the unloaded state.

We compute the split percentages ourselves. I guess we aren't rounding right (maybe truncating? dunno). Because the sum isn't 100% even if 123+333=456.

To enable editing the category, we need to first fetch available categories so we have the name/id pairs. Then we can populate a categories data store, and display it below the transactions for debugging purposes. Eventually we'll wire it into the app properly, and remove it.