Repository navigation
[UX improvements] Allow calculations in expense amount field #632
Description
I would find it useful to be able to enter calculations directly in the expense amount field (like 30.5+10.75-12-1.86), like Splitwise allows me to.
This would help for:
- concatenating multiple expenses as one for clarity (like multiple toll fees on a drive)
- removing the shares from some people that are not using the platform in a shared expense (like food ordered with friends you don't share expenses often with)
- etc.
This is also related to the management of negative expense amounts (see #621).
I imagine that the way expenses are stored in the database, only the result of the calculation can be saved as the expense amount, but as a bonus the original calculation could be added as an automatic expense comment (needs #61).
Activity
krokosik commentedon Apr 28, 2026
I doubt I will ever have the motivation to implement that, given how god awful the formatting of currencies is in JS, but yeah would be cool.
FelixDz commentedon May 4, 2026
I imagine this is about dots, commas and spaces having different uses depending on the currency? I suppose you end up converting to a unified formatting for database storage, but indeed this conversion would have to happen before applying operators.
I also agree this is not a pressing issue as it is more about UX and handy helpers than a core feature.
[-][Feature] Allow calculations in expense amount field[/-][+][UX improvements] Allow calculations in expense amount field[/+]krokosik commentedon Oct 1, 2026
@mikimandoki thank you for the PR, thouh I wish you would have discussed with me how to shape it first. I feel quite uneasy about merging almost 900 added LoC that also heavily modifies the core number formatting logic. In particular, I believe this could be handled without even tackling it at all, by treating the expression engine as a separate layer.
I'm not sure how you implemented the UI part because there is no video or screenshot, but I imagine it could work like this:
Current usage
so we have a 2 node state diagram with focusing being the operation
Extended usage
Let us now introduce a third node, which is the expression mode. Toggling into this mode can happen by for example pressing enter and in this mode one can enter mathematical expressions (kind of like in Excel). But, this is not excel, it's a simple app with no backend implementation for even storing the expression, so I believe it is fine for the UX that when we leave this 3rd state, we always have to pass through:
expression eval -> numeric amount -> UI format
mikimandoki commentedon Oct 1, 2026
Hey @krokosik sorry to have come out of the blue with this. I used inline calculations a fair bit on Splitwise and that's what I based the UX on.
Admittedly a lot of my PR is churn from the code review bot that flagged issues outside of my changes (particularly the re-render when switching between currencies with and without decimals). Happy to trim and iterate until we arrive at a shape we're happy with.
Let me chew on your idea for a bit and I'll come back with some demo videos on potential approaches.
krokosik commentedon Oct 2, 2026
I see, I'm not adamant about the idea I outlined and Splitwise is what people are used to. I am just worried about modifying the number util functions so extensively, so lets work something out.
Trimming the PR or splitting the fixes into separate ones will definitely help
mikimandoki commentedon Oct 26, 2026
Hey team, apologies for the radio silence. I revisited this PR and narrowed it down to the expense amount field. I've had another look at how Splitwise does this and this is what I landed on:
I've put up a brief demo video in #785. Will action the robot comments if we are happy with the overall shape and UX. I'm also gonna run this version on my private instance to get some real life testing data.