That's right - without a backend server, I couldn't think of a great way to manage a private API key. That means that users have to sign up for their own keys (instructions on the "Currency Sync" page under "Settings") if they want to use currency sync.
I thought I'd added a description to the error you get if you're still using the default "demo" key - clearly not, I'll add that it.
Oops - I guess that needs to be better signposted...
If you go to the currency page in the dialog (where you're creating USD), there's a "Default Currency" dropdown in the main section on the right. You might need to close out of any currency you're editing, but hopefully it's reasonably prominent once you do.
Nope, no APIs - instead, I've focussed on a smooth workflow for statement uploads and options for manual transaction reporting.
I actually had a look around for APIs, and couldn't find anything that fitted with what I was trying to do: most services are specific to certain countries, and even with the various Open Banking initiatives around the world coverage is still limited and password storage upstream is often required (Plaid is obviously the standout here, although there are competitors and regional equivalents). That's expressly what I'm trying to avoid: ideally all of that could be managed locally in the browser, but until it can I'm not expecting to use it.
That's interesting - I haven't seen errors in quite a while (on Firefox), and I've been using it myself for a few months. What are you doing just before it crashes?
That's a good idea - hard to believe that I didn't think of "min-width" considering the amount of other CSS that had to go into this, I wish I'd come up with it myself 12 hours ago...
I've just updated it, everyone should be getting an updated version now (clearly there's interest!). Thanks for the thought!
I appreciate rapind's point so I won't comment along those lines, but I think it's worth explicitly saying that the UI doesn't work within a certain screen width: it would display nonsensically, and I'd rather display an explanation to someone new to it (and the link to the GitHub ReadMe, which hopefully helps a little) rather than complete garbage. I definitely don't consider this a "feature" - I think it's just the least bad option, given the lack of a proper mobile view. It's also the case that the idea of "urgent access" doesn't work so well without data syncing - I generally wouldn't expect people to copy the export file to their mobile manually, in which case this won't actually have the data from another device.
It's probably true that a summary of features or something would be more helpful for those coming across it anew. In this case though, this is mostly for my own benefit, and it's explicitly out of scope to make money off this: I'd prefer to spend time on additional features for users (ie. me!), rather than implementing something like a product showcase or proper mobile view. Hopefully it's useful/interesting enough when it can be viewed properly, that it's worth coming back to.
Yes, that's correct - it's the price of the data not being synced elsewhere.
That said, I was worried about that too, for myself: I've added in easy file import/export, and the option to sync to Dropbox (I'm using a separate account for TopHat syncing), so that people at least have options for backups.
I definitely have a lot of opinions about this :D. The main one is that RTK was fantastic (as are the docs!), and createEntityAdapter was definitely better than the equivalent that I wrote before finding it... A few more specific thoughts though:
- createEntityAdapter was great, but one idea for an addition: I dislike having numbers as IDs (Will floating point precision bite me? Will I accidentally treat them as actual numbers? Do I need to cast them back for lookups or equality checks?), but I didn't get around to moving to strings, and preserving the sorting and ID generation with that in mind. Maybe RTK could bundle some utilities for managing this, like sorting functions and/or ascending ID generation to save others from my fate? I'll definitely start with these next time.
- I really liked the Slice API in RTK, but I felt like I wanted to run nested slices quite a lot - breaking up serialisable state (ie. user data) and page state, but then breaking down further into individual data types or pages respectively, so that pages could "own" their own state (and maybe get as far as something like a managed Mixin for a page state, like the recurring transaction table). I spent some time writing a way to compose Slices, but I found that it made things probably more complicated than it needed to be - even if you end up with a load of useAccountsPageState-style duplication which is maintained manually. (I'll admit this was a while ago, so my memory of why I decided against this is a little rusty...).
- I definitely got that the expected pattern is createAsyncThunk (or useDispatch more broadly) rather than my separate functions using TopHatDispatch. I spent some time tooling about with migrating over, but I felt like it was an additional abstraction layer that I didn't really need. I eventually went with a fairly strict flow of "Types -> Storage Logic -> Store Definition -> Actions -> Components" which dealt with the circular imports. I'd be interested in other thoughts behind the best practice though - maybe they're more obvious with other people, or a larger project?
Honestly, I haven't really got as far as a license for the code yet - I don't know much about them, and people seem to have strong opinions about the standard options for OSS.
I'd be interested in what folks recommend for something like this, and what the trade-offs are. Seems like MIT is the go-to in many cases?
It's looking at the width, so that some fixed-width elements don't run into each other and wreck the display - if you expand the window a little it should work as expected.
For what it's worth, I'm also running Firefox on MacOS, so I'd expect that to work given the right window size.
I definitely get the annoyance. The problem is, a mobile version of this is a very different thing, to the point that it's essentially a completely new app. Displaying a broken interface just to display something isn't helpful, even if I realise it makes it harder on the Show HN audience - I generally check HN on my phone too!
For what it's worth, I'm not looking at user-agents or anything: it's cutting off at the point where the display starts looking awful. If you zoom out enough (plausible on a tablet, less so on a phone), then it will display as intended.
First off - I know, another personal finance app. However, I found none of the existing options matched what I wanted for myself:
* Privacy-first - ideally a local app, and definitely no cloud storage of bank creds for automatic sync. I found this requires a polished statement upload flow, to save time on manual updates.
* Good multi-currency support - this is bizarrely rare in the space.
* Basic analytics and budgeting - ideally not as rigid as YNAB and friends, but at least something lightweight to tell me where my money is going and how that's changing.
So over a few months during Covid, I put together TopHat for my own use: it's a SPA on GitHub Pages with no backend, where all data is stored in browser storage (plus a Dropbox sync option, which I wanted as a backup). It's a pretty standard stack (React, Redux, TS), and the code is all available on GitHub (https://github.com/Athenodoros/TopHat) - don't judge too harshly, my day job isn't software engineering! That said, I've found it very rewarding to use something which I enjoy and which I've built - not to mention finally "finishing" a project...
TopHat can load itself with some demo data, including an example bank statement for upload (check the notification on the top right). Hopefully this is interesting for folks - happy to answer any questions!
I thought I'd added a description to the error you get if you're still using the default "demo" key - clearly not, I'll add that it.