Add the ability in the form to include a category and description for debt paybacks.

Updated accounts from YNAB without import transactions checked and the line graph didn't redraw itself. I had some accounts hidden prior to import.

Perhaps we pull out the iterator in resolveAccountChart and throw some tests at it? If we return an empty values array, we don't want to graph it. It appears it is being graphed with an empty array. This creates incorrect output on the tooltip.

Currently, we rely on vanilla js taking care of our math. Long term, this poses a much greater chance to introduce bugs. Plan to move to using big.js.

We have a state and form that allows recursive elements in to compute a "dynamic" value instead of just entering in a static one. It is worthwhile to add some more cypress tests around this functionality as the abilities are rather open ended.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: baseBranch not found
Message: The following configured baseBranch could not be found: css-in-js

We currently show some of the common metrics with "FIRE" on the cash flow analysis. It seems like this makes sense to split out in the long term. We will likely have more in-depth calculations and simulations ( / variability analysis type math) which make sense on their own page. The interest calculations only do simple interest as well currently.

We should create the ability to load up templates / examples to see what different setups might look like. It may also be useful as data to run tests against.

Currently, the dates are just manually entered as text. There are plenty of datepicker react component libraries that we can choose from, so it should be an easy UX win.

As a minimum threshold for testing our code, every function on resolveFinancials should be tested.

It would make sense to alpha order the accounts. Even better if we can click the headers and have each of those trigger a sort on the column.

Currently, we have the download/upload buttons right below charts. There is also an import from YNAB at the bottom. The intent is that we have many different options for storing and retrieving your own data. I think this should be split out more and set up that we can easily plug in new data storage options.

We need to add a code of covenant. The Contributor Covenant is the best that I have seen and most prominent. Eventually, we will want to add this directly on the website, but a good first step would be to add it to the master branch so it is visible for anyone arriving at the root of the repository. (It means we will need to merge master into next before we merge next, but it seems that it will be some time before that possibly happens.

Long term I think it makes sense to switch off of using Bulma as it won't quite encapsulate all our needs and it's difficult to extend. It seems like switching to styled-components as a base would be in our best interest (and possibly use Rebass, a library of components similar to Bulma, to jumpstart the switch).

We currently have a day that effectively sets when the scheduled transactions start to schedule on. This is also the date that your accounts were last updated. The only way to elect to save the date with your output file is too make sure that date is not the current date which is some poor UX.

We currently have three ways a user can opt to end a transaction reoccurring early, and none are represented on the form. The first, a simple end date, would not be involved. However, we can also end based on the number of occurrences (two types, added in #4). Do we allow the user to select only one? Can a user actually opt for all three? How do we represent this in the form without making it cluttered and still keeping it understandable?

If you have a lot of accounts and you want to drill down the chart to investigate one or two, it is currently rather onerous to hide each one that you don't want to see. Add a button to hide all accounts. Also consider a couple buttons to hide groups of accounts (not sure how best to group theses, maybe by type?).

We have been considering adding "logic" when computing a value to show which would be particularly useful in regards to credit cards. I am leaning towards more "value if true otherwise it is 0" kind of style. I think trying to do branching logic could get complicated.

I am also kind of thinking that if we want to do "unit tests for finance", we kind of want to compute this amount of every day (which could get CPU intensive...), but then you could apply logic like, if my checking will drop below 0, then show a transfer from the emergency account. Using the interest, for example, it would need to reference the current balance at that time rather than the starting balance. So I believe we would need to regenerate the value every time it shows up. In the case of the "emergency transfer", it would generate every day as zero unless your reference account value drops below $X. Since this reaches between different accounts and at different points in time, this may be a separate implementation from the simple logic noted in the first paragraph.

Transactions have two form fields that are just named after the variable names: rtype and cycle where rtype stands for the repeat type. The variable names are probably sufficient, but the form needs to better explain these fields. This is especially true since the definition of cycle changes based on the rtype.

Currently they mess up the grid on small form factors.

We added two different occurrence types in #4: generatedOccurrences and visibleOccurrences. This allows us to end transactions after X occurences of a type. We can also mirror this as starting criteria: beginAfterGeneratedOccurrences and beginAfterVisibleOccurences. This would allow us to pick up a transaction occurence with a different 💰 value after a previous one had ended. For example, in paying off a credit card, you may pay off the balance on the 1st visibleOccurrence, but then want to pick up from with there a minimum budgeted amount to beginAfterVisibleOccurrence.

The homepage could use some attention to properly sell why there is value in creating and using finatr.

The bar chart will begin at a slightly different position depending on the time of day. This includes overlapping the Y axis at certain times. We are effectively ignoring the time so we should just default / fix it to a certain spot.

We should add some form validation to prevent entries from transition the app into a bad state. Likely worth using whatever formik (the form library we use) suggests.

The YNAB import overwrites the existing accounts which normally would not be a big issue, but it clobbers any paybacks if you had added them.

We have recently upgraded the version of YNAB which added functionality regarding transfers. We have some outstanding bugs with the current import as we should deal with positives/negatives better. We only should have a negative for transfers, and transfers should import as two transactions. I don't believe transfers were identifiable before.

We should switch to a Link component so it retains the state if you click it.

We are using a library called Microstates to manage the global state. We do take care of some local state in various components but that is a state that isn't needed throughout the app. As we've built up the initial architecture of finatr, earlier versions of Microstates led towards having many of the methods on the root app model. As both finatr and Microstates have matured, we are looking to split this up into smaller, more composable pieces. As it stands right now we have all of the reasonable features for the initial stable version of the cash flow analysis. Everything currently implemented in Microstates should meet our needs, and we either need to just start using the feature or we can add a function ourselves. There is one element that is on an experimental branch which we will touch on though. The next steps here will just improve the maintainability of the code and won't add user-facing features.

Part of the maintainability of the code is that someone without familiarity with the code can come in and quickly get up to speed, adding pages or tweaking parts of the state to add functionality. With many of the methods up at the root, it's hard to understand what pieces are coupled to what lower-level classes. The way that Microstates composes can be compared to a tree with branches. The root is the trunk, and classes reference other classes going further and further down the branch. One of the issues that we are seeing is that data that is needed by multiple branches ends up living at the root. If we want to perform side effects on execute functions against that data, it means we also have those methods located in at the same point in the branch or above it.

One of the more recent features that we have started utilizing from Microstates is relationships. The plan with it moving forward is that we will pass a path to a piece of data to create the reference. This is still on an experimental branch/repository and hasn't yet moved over to the main repository. We are using the alpha version of relationships which does not implement this path feature. This will let us reach across these branches in a way we couldn't before. So with this, we can put data further down the branches and split up all of these methods. We will still be able to access them if needed from other branches. This will let us compose pieces and split up the methods into the actual branches that they act on.

Another plan is to slowly migrate towards using the Microstates directly. In earlier implementations of our state, we called the .state method to just return the JavaScript object. This lets us work with basic JavaScript and use functions baked into the standard library that weren't already existing in Microstates. This also meant that we were jumping back and forth between plain JavaScript and a Microstate often which can get confusing. As Microstates has matured, all of the functions that we generally need/have used are now implemented in Microstates so that we can write our functions to expect a microstate instead of expecting JavaScript objects. As we move methods and the data further down the branches, we can also begin to rewrite the functions to expect Microstates and bounce between these two things less.

One of the remaining items is that we use a lower-level library called big.js. We may consider switching it out for a more currency focused library such as dinero.js. Effectively all of our use cases for a library that fits in this "place" is to chain a bunch of functions together that return a value that we want to use. With newly added Microstates features (since we began using it), we can, instead of mapping each of these functions to a transition in Microstates, give Microstates a function to return and have that encapsulated into a Microstate. This would let us take an existing microstate, run a bunch of big.js functions on it, and then return a value to be encapsulated into a microstate. The value of this is that we can perform multiple functions with our lower-level libraries and only we return one actual transition.

This presumably will help with performance and will reduce the amount of "fighting" that we currently have with Microstates. When we first started using Microstates, any transition would return with the AppModel root and we would need to drill back down to the original branch we start on to run another transition if need be. A newer implementation of Microstates returns the branch that the method was transitioned on, e.g. the model that the method was called on. This did reduce some of the depth we needed to drill back down. However, we still end up calling transition after transition after drilling down a level or two when all we want to do is perform a chain of functions.

Ultimately we want to set up the code where it's as relatively easy to switch out the lower level math functions. If we choose to switch to deniro.js or stay with big.js, I would expect that we stick with that library for quite a while. However, just having this separation of concerns makes the code easier to reason about.

To summarize, we split up the methods on the AppModel (the root) more by using the planned new feature with the relationship function to reach across branches for data. We rewrite methods and the lower-level functions to expect a Microstate instead of a JavaScript object making it less confusing with which we are working. Lastly, we use a function in Microstates to return only one transition based on a function or chain functions for the Type comprised of big.js or dinero.js. All of this ultimately is just for maintainability of the code, separating concerns, and making it easier for somebody new to the library to jump in and help out.

As the type of information we show rather lends itself to a table, it may be worth adding/switching to react-table to get the "free" features.

It seems that the cash flow is pretty generally tied to a budget. That budget is the culmination of many little expenses that are planned or intended at varying intervals. There is value in adding a budget to finatr to help describe the higher level planning and how planned costs are built up. The budget can be as many levels deep as needed that eventually have the summation represented in the cash flow analysis in some manner. I expect we will want to keep this more loosely coupled with the cash flow analysis, but some thought will need to go into it

In #3, we added the ability to input a string which refers to another field on the transaction. This is handy for paying off an account balance or recent activity on a credit card. Unfortunately, this is difficult to deal with in the forms. We need both the ability to add/modify the special referential fields as well as provide the ability in the form enter in a number or refer to a field.

Paybacks are directly tied to debt accounts, and entered/modified in that section. However, these also spawn off transactions. It would be useful to list these in the main transaction list, but graphically differentiate it that it is known to be from a payback.