- Big commit implementing additional test cases to make the test suite as comprehensive as I can.
- That doesn't mean it is fully comprehensive
- Addressed feedback
- Resolved insufficient rest test case issue
- Implemented `testing.T``t.Logf` test level logging
- Implemented pure `zap` debug logging for all relevant filter functions.
## Schedule
- [x] 10:30 – 11:30 : Desktop Send modal review
- https://meet.google.com/pow-qyes-pcv
- "A meeting to dispel doubts about the design and current state of SendModal."
- **Attendees:**
- Michal C (Facilitator)
- Alisher
- Ben
- Brian
- John (Lea)
- Sale
- Myself
- **Summary:**
- Discussion clarifying the rules and requirements of the desktop designs for sending tokens.
- No agreement yet on where to capture the rules
- Initially some confusion on the distinction between multichain send "without bridge" and "bridging"
- Confusion as sending over multiple chains requires bridging
- Clarity eventually given; references to "bridging" is a term for a specific UI action and not an implementation behaviour.
- ie in the UI context bridging refers to the user pressing a "bridging" button to perform an explicit bridging action.
- ⚠️ Attention. Devs and QAs particularly should be mindful of this.
- Emphasised that the app should mint `ERC1155` rather than `ERC721` tokens
- Confirmation that this is the case was suggested.
- Highlighted that there is an inconsistency with the current desktop app functionality verse the intention of the design.
- Locking behaviour for values on specific chains does not work as the product design intended
- Full requirements not yet provided, expected to follow.
- Additional clarification and validation likely to be needed
- Discussed that `ERC1155` tokens of the same kind should be grouped together.
- Unclear if designs and requirements for this feature exist in the form needed by Desktop UI.
- Dario has mentioned in chat: > "*This is mostly a backend effort with relatively high complexity (define a special kind of token for these "community ERC721 we want to treat as ERC1155" ones, do the grouping backend-side when fetching them, do the un-grouping backend-side when sending, ensure no side effects in activity). I see low chances of swap-team being able to work on + finish that for 2.30, unless it's prioritized over Swap.*"
- So this intent is / has been expressed somewhere.
- Brief update from Brian and me.
- The call expressed a blithesome response to the update that the Wallet Router filter modularisation and test suite was complete and ready for review.
- I'm very nearly finished now. However, I do need reviewers to pay super close attention to the test cases and check that the intent of the functions is matched by the cases.
- The full list of changes is available in the PR commit.
- A very in depth meeting reviewing the send flows of desktop.
- **Key Decisions:**
- Reduce the scope of the Send, Bridge and Swap UI designs for 2.30
- UI and design to work together
- Desktop UI should detail what is feasible for the 2.30 release
- Alisher and Ben are supportive of facilitating a highly iterative framework.
- Alisher and Ben will adapt sending flows as required
- Michal and Sale would discuss the best process for improving the UI while at the same time being able to deliver something. Include Noelia
- Identified distinctions between the concepts of backend `Router` and UI `Router`
- Backend `Router` is a logic model for sending blockchain tokens. This model contains functionality that manages:
- Calculating the best path for any given transaction requirements:
- From address(es)
- To address(es)
- From network(s)
- To network(s)
- From token type(s)
- To token type(s)
- The `Router` is capable of using multiple input tokens and addresses to plan a route to multiple output addresses and tokens.
- The `Router` determines which swaps and bridges may be required to achieve the goal
- Backend `Router` can be called by multiple UI components:
- Bridging
- Sending
- Swapping
- Backend `Router` handles all of these transaction types internally.
- UI `Router` is a complex high level UI component that allows a user to plan with great detail which tokens, addresses and networks they wish for a transaction (or series of transactions to take).
- UI `Router` is part of the UI bridging functionality.
-`filterRoutes` is a very complex function, and it is very difficult to read. I've split it apart and named the levels of filter after what they do rather when they happen.
- [See here for details](./analysis/wallet/Router/code/filterRoutes.go)
- I raised an axe to the crew meetings, swung hard and true. Toppled and prostrate they settled motionless. Tonight we revel in the light of their embers!
- I began work on reading and building context of the Route `status-go` logic.
- This work is tricky to track, but I have begun making notes of the logic. I plan to continue to build out a description or documentation detailing the analysis.
