Feat/request payment modal 16736 #16744
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cuteivist
requested review from
micieslak,
caybro,
alexjba and
a team
as code owners
Jenkins BuildsClick to see older builds (48)
|
caybro
reviewed
Nov 13, 2024
|
Build fails on all platforms |
alexjba
reviewed
Nov 19, 2024
micieslak
previously requested changes
Nov 19, 2024
There was a problem hiding this comment.
Definitely good job in general, however I have several concerns regarding the architecture which are worth amending imo:
- The modal should be fully decoupled from
StatusChatInput.StatusChatInputshould only emit signal with request to launch the modal instead of managing it internally, because it causes thatStatusChagInputdepends on everything the modal depends on now and will depend on in the future. Those two things become tightly coupled unnecessarily. RequestPaymentStoreis probably not needed at all. Broadly speaking, the store is not intended to be a container to move stuff around UI components. It's to expose backend's functionality. And every backend's mode/signal/function should be exposed only once via a single store.- The
RequestPaymentModalshould be a plain UI component taking some models and emitting some signals with no dependency on any store. Also transformations like that done byTokenSelectorViewAdaptorshould not be done internally. Instead the modal should depend on the model. It's up to the caller to compose data using any adaptor that's needed.
In case of any doubts please ping me, I will be happy to discuss about that.
2 tasks
Cuteivist
force-pushed
the
feat/request-payment-modal-16736
branch
from
cfc1b4c to
6556a35
Compare
|
I refactored the approach according to your guidelines.
|
caybro
requested changes
Nov 27, 2024
alexjba
reviewed
Nov 28, 2024
Cuteivist
force-pushed
the
feat/request-payment-modal-16736
branch
3 times, most recently
from
9ec0703 to
21e7fae
Compare
micieslak
reviewed
Dec 3, 2024
virginiabalducci
approved these changes
Dec 3, 2024
There was a problem hiding this comment.
This looks good!
Testing feedback here: #16833
The pending issues are not related to this feature.
Cuteivist
force-pushed
the
feat/request-payment-modal-16736
branch
from
21e7fae to
eb90211
Compare
jrainville
force-pushed
the
feat/request-payment-modal-16736
branch
from
eb90211 to
e19831a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #16736
What does the PR do
Affected areas
Architecture compliance
My PR is consistent with this document: Status Desktop Architecture Guide
Screenshot of functionality (including design for comparison)
Impact on end user
What is the impact of these changes on the end user (before/after behaviour)
How to test
Enable request payment feature flag, go to any chat on mainnet.
Risk
Described potential risks and worst case scenarios.
Tick one: