github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #631] [Feature] Utilize an existing component library to replace loot-design components #7202

New Issue
Closed
opened 2026-04-10 16:54:18 -05:00 by GiteaMirror · 15 comments
GiteaMirror commented 2026-04-10 16:54:18 -05:00
Owner
Copy Link

Originally created by @gsumpster on GitHub (Feb 4, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/631

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

Hey! I wanted to kick off some discussion around how we can replace some of the existing generic front-end components with those from an existing library. This is directly related to this note in the Contributing.md file here: bc3bb6f281/CONTRIBUTING.md (adopt-an-existing-component-library)

I think it'd be great to establish consensus on what we're looking for in terms of component libraries and what are some components that we'd like to target.

Describe your ideal solution to this problem

I personally love the approach that both react-aria and Radix take. I don't have any personal experience with react-aria but I do with Radix and found it super nice to use.

As far as target components, I'm relatively new to the codebase but I think the Tooltip component is potentially a good one (though potentially split into multiple components to avoid overloading it – what is a Tooltip, anyway 😉). Autocomplete is another one that I believe we could dramatically simplify by changing existing implementations to use a different 'core' component.

Originally created by @gsumpster on GitHub (Feb 4, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/631 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? Hey! I wanted to kick off some discussion around how we can replace some of the existing generic front-end components with those from an existing library. This is directly related to this note in the `Contributing.md` file here: https://github.com/actualbudget/actual/blob/bc3bb6f2812d2f9f17a2ea8d9cf7c37894b95e88/CONTRIBUTING.md#adopt-an-existing-component-library I think it'd be great to establish consensus on what we're looking for in terms of component libraries and what are some components that we'd like to target. ### Describe your ideal solution to this problem I personally love the approach that both react-aria and Radix take. I don't have any personal experience with react-aria but I do with Radix and found it super nice to use. As far as target components, I'm relatively new to the codebase but I think the `Tooltip` component is potentially a good one (though potentially split into multiple components to avoid overloading it – what is a Tooltip, anyway 😉). `Autocomplete` is another one that I believe we could dramatically simplify by changing existing implementations to use a different 'core' component.
GiteaMirror added the tech debt label 2026-04-10 16:54:18 -05:00
GiteaMirror commented 2026-04-10 16:54:19 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Feb 4, 2023):

Those both look great! And they seem like they’re unstyled, so the UI can keep its existing looks. Radix seems to be from a startup (WorkOS) while React Aria is by Adobe. I don’t really know what that means in term of future lifespan (since I could easily see WorkOS going under in a few years, or Adobe abandoning React). I haven’t used either so I don’t have any opinions in that area.

<!-- gh-comment-id:1416847988 --> @j-f1 commented on GitHub (Feb 4, 2023): Those both look great! And they seem like they’re unstyled, so the UI can keep its existing looks. Radix seems to be from a startup (WorkOS) while React Aria is by Adobe. I don’t really know what that means in term of future lifespan (since I could easily see WorkOS going under in a few years, or Adobe abandoning React). I haven’t used either so I don’t have any opinions in that area.
GiteaMirror commented 2026-04-10 16:54:20 -05:00
Author
Owner
Copy Link

@gsumpster commented on GitHub (Feb 5, 2023):

Yep, definitely a valid concern with regard to lifespan. It's worth mentioning that Radix is used by some relatively large startups (Linear, Vercel, etc), but I think trying to make judgements on either is difficult either way.

I think with either library, we'll end up running into situations where one doesn't fit in quite the way we want it to, for example, I think if we were to stick with react-aria, we'd need to look elsewhere for a Tooltip implementation, and I'm sure the same will apply with Radix. Maybe the focus here is less about which library, and how can we generally reduce the amount of code that has to be maintained with the Actual codebase. For both the Tooltip and Autocomplete components, there's a lot in there that something like react-popper or react-select could replace.

With that said, after taking a closer look at both, I think a combination might be the best way to go with these things. Radix offers a somewhat larger set of functional components, whereas I think react-aria provides a better set of utilities for managing things like keyboard shortcuts and focus.

<!-- gh-comment-id:1416925819 --> @gsumpster commented on GitHub (Feb 5, 2023): Yep, definitely a valid concern with regard to lifespan. It's worth mentioning that Radix is used by some relatively large startups (Linear, Vercel, etc), but I think trying to make judgements on either is difficult either way. I think with either library, we'll end up running into situations where one doesn't fit in quite the way we want it to, for example, I think if we were to stick with react-aria, we'd need to look elsewhere for a Tooltip implementation, and I'm sure the same will apply with Radix. Maybe the focus here is less about which library, and how can we generally reduce the amount of code that has to be maintained with the Actual codebase. For both the Tooltip and Autocomplete components, there's a lot in there that something like react-popper or react-select could replace. With that said, after taking a closer look at both, I think a combination might be the best way to go with these things. Radix offers a somewhat larger set of functional components, whereas I think react-aria provides a better set of utilities for managing things like keyboard shortcuts and focus.
GiteaMirror commented 2026-04-10 16:54:20 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Feb 5, 2023):

That sounds great! There are definitely a bunch of parts of the app that are fairly standard UI components (e.g. the menu buttons and some of the text fields) and others that are very much not standard (e.g. the budget and account spreadsheets).

<!-- gh-comment-id:1417836819 --> @j-f1 commented on GitHub (Feb 5, 2023): That sounds great! There are definitely a bunch of parts of the app that are fairly standard UI components (e.g. the menu buttons and some of the text fields) and others that are very much not standard (e.g. the budget and account spreadsheets).
GiteaMirror commented 2026-04-10 16:54:21 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Feb 5, 2023):

It’s been bugging me for a while that the menu buttons can’t be clicked again to close the menu and that you can’t click+drag on a menu button to quickly select an item, and it seems like Radix does both of those interactions very well!

<!-- gh-comment-id:1417842836 --> @j-f1 commented on GitHub (Feb 5, 2023): It’s been bugging me for a while that the menu buttons can’t be clicked again to close the menu and that you can’t click+drag on a menu button to quickly select an item, and it seems like Radix does both of those interactions very well!
GiteaMirror commented 2026-04-10 16:54:21 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Mar 5, 2023):

Related: in https://github.com/actualbudget/actual/pull/727 we found that <Tooltip> doesn’t track the position of the element it’s attached to if that element animates, but hopefully any library we switch to will handle that case

<!-- gh-comment-id:1455173493 --> @j-f1 commented on GitHub (Mar 5, 2023): Related: in https://github.com/actualbudget/actual/pull/727 we found that `<Tooltip>` doesn’t track the position of the element it’s attached to if that element animates, but hopefully any library we switch to will handle that case
GiteaMirror commented 2026-04-10 16:54:22 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Mar 23, 2023):

For inspiration: https://javascript.plainenglish.io/best-react-ui-frameworks-and-component-libraries-408df66a1f31

<!-- gh-comment-id:1480876530 --> @MatissJanis commented on GitHub (Mar 23, 2023): For inspiration: https://javascript.plainenglish.io/best-react-ui-frameworks-and-component-libraries-408df66a1f31
GiteaMirror commented 2026-04-10 16:54:22 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 16, 2023):

It looks like Radix UI doesn’t have support for autocomplete/combo box components, so React Aria is the one we should be using if we want to be consistent across everything.

<!-- gh-comment-id:1510487364 --> @j-f1 commented on GitHub (Apr 16, 2023): It looks like Radix UI doesn’t have support for autocomplete/combo box components, so React Aria is the one we should be using if we want to be consistent across everything.
GiteaMirror commented 2026-04-10 16:54:22 -05:00
Author
Owner
Copy Link

@trevdor commented on GitHub (Apr 16, 2023):

I’d lean toward react-aria at this point, myself, all things being equal.

I used react-aria for the mobile lists because @jlongster had mentioned it in his initial open sourcing dev notes. It worked very nicely, I thought.

James mentioned not liking their table component. Although I’ve noticed Devon Govett is doing a ton of work on react-aria, prepping a new major version. So things could change. Either way, it’s a very active lib.

<!-- gh-comment-id:1510493252 --> @trevdor commented on GitHub (Apr 16, 2023): I’d lean toward react-aria at this point, myself, all things being equal. I used react-aria for the mobile lists because @jlongster had mentioned it in his initial open sourcing dev notes. It worked very nicely, I thought. James mentioned not liking their table component. Although I’ve noticed Devon Govett is doing a ton of work on react-aria, prepping a new major version. So things could change. Either way, it’s a very active lib.
GiteaMirror commented 2026-04-10 16:54:23 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 16, 2023):

James mentioned not liking their table component. Although I’ve noticed Devon Govett is doing a ton of work on react-aria, prepping a new major version. So things could change. Either way, it’s a very active lib.

We could grab the table component from somewhere else or just keep our existing one in that case, while adopting the rest of the components.

<!-- gh-comment-id:1510495262 --> @j-f1 commented on GitHub (Apr 16, 2023): > James mentioned not liking their table component. Although I’ve noticed Devon Govett is doing a ton of work on react-aria, prepping a new major version. So things could change. Either way, it’s a very active lib. We could grab the table component from somewhere else or just keep our existing one in that case, while adopting the rest of the components.
GiteaMirror commented 2026-04-10 16:54:24 -05:00
Author
Owner
Copy Link

@trevdor commented on GitHub (Apr 16, 2023):

We could grab the table component from somewhere else or just keep our existing one in that case, while adopting the rest of the components.

For sure. James has called out how carefully his existing table was optimized for speed. That’s not to say no 3rd party table will cut it—there are certainly new ones out there that weren’t around back then—but obviously something to keep an eye on.

<!-- gh-comment-id:1510498203 --> @trevdor commented on GitHub (Apr 16, 2023): > We could grab the table component from somewhere else or just keep our existing one in that case, while adopting the rest of the components. For sure. James has called out how carefully his existing table was optimized for speed. That’s not to say no 3rd party table will cut it—there are certainly new ones out there that weren’t around back then—but obviously something to keep an eye on.
GiteaMirror commented 2026-04-10 16:54:24 -05:00
Author
Owner
Copy Link

@everettraven commented on GitHub (Jun 11, 2023):

Hello 👋 - I am starting to dabble with React & JS to learn something new and would be interested in helping with this. Is there a particular breakdown of the components that would be good to start with one at a time or are the Tooltip and Autocomplete ones initially mentioned by @gsumpster a good starting point?

Also just noting that I haven't even began looking at the code base, but figured chipping away at some of the smaller component changes would be a good way to get started contributing.

<!-- gh-comment-id:1586152200 --> @everettraven commented on GitHub (Jun 11, 2023): Hello 👋 - I am starting to dabble with React & JS to learn something new and would be interested in helping with this. Is there a particular breakdown of the components that would be good to start with one at a time or are the `Tooltip` and `Autocomplete` ones initially mentioned by @gsumpster a good starting point? Also just noting that I haven't even began looking at the code base, but figured chipping away at some of the smaller component changes would be a good way to get started contributing.
GiteaMirror commented 2026-04-10 16:54:25 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Jun 11, 2023):

Hi! I think the tooltip could be a good place to start. We made an attempt to port the autocompletes over to a different package a few months ago and ended up ripping it all out because it just didn’t work right, so I would not recommend working on that as a starter project. That said, porting the tooltips would be a fairly large task since they are used pervasively for lots of different effects so you may want to start off on another, smaller issue.

<!-- gh-comment-id:1586174842 --> @j-f1 commented on GitHub (Jun 11, 2023): Hi! I think the tooltip could be a good place to start. We made an attempt to port the autocompletes over to a different package a few months ago and ended up ripping it all out because it just didn’t work right, so I would not recommend working on that as a starter project. That said, porting the tooltips would be a fairly large task since they are used pervasively for lots of different effects so you may want to start off on another, smaller issue.
GiteaMirror commented 2026-04-10 16:54:25 -05:00
Author
Owner
Copy Link

@everettraven commented on GitHub (Jun 11, 2023):

@j-f1 Thanks for the response and additional information! I was looking around the code a bit more and I'll plan to try and find a component that is smaller task. I was taking a look and something like the DateSelector seems fairly straightforward to port over to an existing component library. Is that a component that you think would be good to start with?

<!-- gh-comment-id:1586215131 --> @everettraven commented on GitHub (Jun 11, 2023): @j-f1 Thanks for the response and additional information! I was looking around the code a bit more and I'll plan to try and find a component that is smaller task. I was taking a look and something like the `DateSelector` seems fairly straightforward to port over to an existing component library. Is that a component that you think would be good to start with?
GiteaMirror commented 2026-04-10 16:54:26 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Jun 11, 2023):

@everettraven That’s a good option!

<!-- gh-comment-id:1586241370 --> @j-f1 commented on GitHub (Jun 11, 2023): @everettraven That’s a good option!
GiteaMirror commented 2026-04-10 16:54:27 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Sep 23, 2024):

We've moved many things to react-aria already and plan to continue the work.

Closing this ticket, but feel free to continue discussing this.

<!-- gh-comment-id:2368921551 --> @MatissJanis commented on GitHub (Sep 23, 2024): We've moved many things to react-aria already and plan to continue the work. Closing this ticket, but feel free to continue discussing this.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label tech debt
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#7202
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?