This repository has been archived by the owner on Feb 20, 2023. It is now read-only.
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.
For #24855: Allow updating and deleting an existing address. #25031
For #24855: Allow updating and deleting an existing address. #25031
Changes from all commits
cee194f
7837fd8
6be7a11
938412a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is out-of-scope for now, as it we're pretty far along in the implementation of this entire feature. Seeing this got me thinking though: why are needing to pass data between simple screens through navigation arguments?
I think we're intending to model the design of this feature after credit cards. However, I believe the intention moving forward is to follow the architecture defined in the
lib-state
module in A-C.If we had created a
Store
that was scoped to this feature (using aStoreProvider
to share it between fragments), it would have allowed us to avoid this kind of thing as well as the kind of delegate-chaining we see in the controller/interactor. The resulting side-effects in those classes could have been moved instead into Middlewares attached to the Store.No actions needed, just sharing some thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe only
AppState
is the onlyStore
that persists in memory. So, creating a newStore
that is shared between fragments won't actually persist the selected Address between fragments. You would still need to pass the selected Address and inform the newly createdStore
of the state, which gets recreated every time you navigate to the fragment. My current mental model is that aStore
only lives for as long as the fragment does. However, I can totally be wrong about all of this and I have never looked into this deeply enough to confirm these claims - there are people who can provide an answer if we asked in a team channel, which I think would be a nice thing to do.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to use nav args when data is passed from a single fragment to a "child" fragment ( by child fragment in this context I define a fragment that is accessible only from the one fragment) and the data is not really needed in other fragments /places in the app. We could save all things in a store/state only for the one screen, but that would be overkill IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you're right,
StoreProvider.get
is fragment-scoped. My thinking is still being influenced some by my last position, here's some details as to why if you're curious:The last project I worked on was multi-module, which informed some of the architecture. We typically would have a parent fragment/activity as an entry point to a module, which allowed us to create well-defined entry points as well as share data between child fragments in the module.
For example, imagine having a
Settings
(or evenAutofillSettings
) module that had aStore
scoped to the lifecycle of a parent fragment.We could also theoretically add a
StoreProvider.get
method that used theHomeActivity
to share stores between fragments, but I'd worry about memory bloat. We'd probably need to think through lifecycle retention pretty deeplyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don' think we actually needed this
menu
variable. Even inCreditCardEditorFragment
I didn't think we needed it because it was done so that we can callmenu.close()
inonPause()
, but the menu never really opens, and I think we just ended up copying code from logins without fully understanding it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The menu opens if the toolbar text is long enough and the device screen is short. I think it will be good if we keep the same pattern everywhere. Also, we could add some tests for it if we keep it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Should we add the
menu.close()
handling inonPause()
in this PR as well? Otherwise, we just have thismenu
that isn't doing anything currently.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should pass the address through the
bind()
instead? This seems cleaner to me instead of having a nullable property inAddressEditorView
. Also, it just follows the current CreditCardEditorView convention.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to have the
address
as property because we also use it in other places (thesaveAddress
method) and I would prefer not to pass it around as param from method to method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that makes sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite sure what to think about this. Instinctively, I feel like this should be called through the usual interactor/controller, but I don't know if I have a strong opinion about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the pair interactor/controller usage as a bridge between the actions in the interface and the store and sometimes state. Showing a UI piece (a confirmation dialogue in this case) should be the responsibility of the fragment/view IMO. This would also allow for additional testing of the dialog behavior in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally agree with your stance. Where I would say I differ or don't hold a strong opinion on is the exact scope of what should be handled in the controller - I think handling all
Store
interactions in there makes sense, but otherwise, I would be looking to extract as much functionality out of the Fragment to make functionality easier to tests. Otherwise, I would say the Interactor is called for all user interactions, which is why I am on the fence since this is technically called through a user tapping on the "Delete button", but it's also called through the menu options.The View in this case does satisfy the fact that we aren't putting the dialog responsibility in the fragment and thus making it easier to test. So, I could've gone either direction.