molnard
commented
11 months ago Noble Author,
Your Quest has been selected for further progress! The devil is in the details - so you need to elaborate and show your quest is not evil. We only embrace quests that are leading us to the light! To prove that you will need to add the following Sections to the Quest description above:
⚠️ Sections to add to the Quest descriptions
- Team involvement: [ui / code / integrations / marketing ] can be one or more.
- Subtasks. Try to break it down as much as possible. Think about teams and jobs that can be done in parallel. Phrase it like a Todo list with elements. If something is not clear yet do not forget to add a task - "research this or that"...
ℹ️ Tips
- Try to break down the task to Teams and then to Subtasks.
- Try to be as detailed as possible.
- Do your best to estimate or to get an estimation from the right ppl. If required you can arrange a meeting and invite team leaders or ppl you believe could be involved or have something to add.
🕐 Please make this the utmost importance - we do not have much time left!
Pule08
nopara73
📜 Preamble
Transaction History Filters by @ichthus1604
📖 TL;DR - Too Long, Didn't Read
No one needs to see their transactions from a year ago in the main UI. Introduce filters in the transaction history by date / send or receive / labels / transaction type
🌟 Specification, Scope, and Features
Add an (expandable/collapsible?) filter panel on top of the transaction history view. This would affect only the list and not interact with anything else such as the privacy / balance tiles.
By default, it could show only the transactions from last 30 days and hide anything before that. This way, if a new transaction comes in, the filter would include it and it would show up in the list, maintaining the current behavior where newly processed transactions are highlighted.
If the filter is set by the user to the past, or any filter option which does not include the newly processed transaction, the UI notification should be smart enough to show some message like "click to show" and give the user the ability to intentionally click on that and have the filters reset to default.
⚔️ Motivation
Endlessly scrolling through the transaction history (in whatever form, even if it's not a datagrid like @soosr proposed here) makes no sense and is no good UX. If I'm searching for whatever happened in 2022 I should be able to search by dates, months or years and have that information readily presented and filtered out from the rest.
It also introduces many performance considerations as we're right now loading the entire lifetime of every wallet (in a multi wallet UI) in order to show the transaction history.
📜 Rationale
Recent findings by @turbolay show that we could significantly reduce memory usage by simply making transactions (and the related support objects that we use to show them in the UI) use less memory. How about letting them use 0 (zero) bytes of RAM by simply not loading them unless requested by the user? On top of that, loading the entire wallet history of transactions shouldn't be necessary to display the current wallet state. Balance and other "current snapshot" data could be stored in the Sqlite Db and updated in an event-driven fashion.
This also goes in line with #10 (Optimize wallet performance for mobile)
🌌 Backward Compatibility
We already achieved migration into Sqlite in the past, we can do it again, this time for transactions and wallet state data.
📚 Reference Implementation (optional)
Pretty much every fintech application in the world has some sort of filtering of transactions.
🧑🏫 Team involvement
VDG Team Lead: @ichthus1604 UI/UX Design: @soosr UI Implementation: @ichthus1604
Code Team: I propose @kiminuo take the lead in the Code side of things as he's already been working in what's required to make this happen
💪 Subtasks
This project can be divided into 2 large milestones:
🚩Stage one Subtasks
[ ] Create UX/UI Designs: @soosr
[ ] Implement UI changes: @ichthus1604 🕐 1 1/2 weeks (subject to Design changes above)
[ ] Define filtering API Contract: @ichthus1604 🕐1 Day
🚩 Stage Two Subtasks:
[ ] Code side changes
[ ] UI changes @ichthus1604 🕐 3 days
Next Steps:
I had a conversation with @turbolay and @kiminuo regarding what's required in order to fully implement this end-to-end.
They are already working on that, but it will take a significant (still not estimated) amount of time due to the heavy refactoring needed to migrate to SQLite.
With this, my plan is to fully implement Stage 1 which can be done completely in the UI side.
Aside from this, I will create the basic API contract that the Client side code needs to provide for the UI for this feature.