-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PI-1738: Billing Form component: Standard #144
Conversation
Base branch should be |
1d730c6
to
5d6ee39
Compare
Few notes on UI and behaviour:
|
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.
approach and testing looks good. few comments, mainly typos. a few quirks with behaviour as well, see #144 (comment)
.../Style/Default Implmentation/BillingForm/Fields/Postcode/DefaultFormStylePostcodedCell.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/Style/Cell/BillingFormTextFieldCellStyle.swift
Show resolved
Hide resolved
...Default Implmentation/BillingForm/Fields/AddressLine1/DefaultFormStyleAddressLine1Cell.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/Style/Protocols/FormButtonStyle.swift
Outdated
Show resolved
Hide resolved
...m/Style/Default Implmentation/BillingForm/Fields/Fullname/DefaultFormStyleFullNameCell.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/BillingFormCellType.swift
Outdated
Show resolved
Hide resolved
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.
A few opinions and some feedback after a limited, initial review. In my opinion there is more to cover but I am also not familiar with the standards expected so don't want my opinion to get in the way too much either.
Source/UI/NewUI/BillingForm/ViewController/BillingFormViewController.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewController/BillingFormViewController.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/BillingFormCellType.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/DefaultBillingFormViewModel.swift
Outdated
Show resolved
Hide resolved
iOS Example Frame SPM/iOS Example Frame/MainViewController.swift
Outdated
Show resolved
Hide resolved
|
||
struct BillingFormFactory { | ||
// in order | ||
static let styles: [BillingFormTextFieldCellStyle] = [ |
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.
Could these styles just be an enum case?
Lets imagine:
enum BillingFormTextFieldCellStyle {
case fullName
case addressLine1
.....
func getConfiguration() -> BilingFormTextFieldConfig {
switch self {
case .fullName:
return .init(color1: .... , color2: ...)
}
}
}
My initial thought is it would reduce a lot of the syntactic sugar you currently have and may increase configuration options as well as extensibility. Additionally, you could completely drop this styles
property if you make the enum declaration conform to CaseIterable
and end up with a syntax of .allCases
at call site instead of the current styles
reference
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.
Sorry, before resolving can we discuss on it? Or at least open a discussion forum somewhere (Git, Slack, anything), so we can try and not forget 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.
@ehab-al-cko to Create Tech investment ticket to address this in new PR
import Foundation | ||
|
||
// Header Cell | ||
public protocol BillingFormHeaderCellStyle { |
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 certain if the comment above the protocol provides any value? The type naming should clearly convey it, and if we want the user of the syntax to flag some helper comment, we should at least use the description marker (///
)
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 going to lie, going ahead with these comments above the class/protocol declaration makes our publicly exposed code look unfinished.
It would be nice if our exposed code would make CKO appear knowledgeable and professional, not showing useless comments. This occurs in a few places, happy to flag them if we decide to do something 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.
Fixed
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.
As it stands I think the lack of cell dequeuing is something that absolutely must be documented if intended or fixed.
UITableView. dequeueReusableCell
For performance reasons, a table view’s data source should generally reuse UITableViewCell objects when it assigns cells to rows in its tableView(_:cellForRowAt:) method
...Default Implmentation/BillingForm/Fields/AddressLine1/DefaultFormStyleAddressLine1Cell.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/View/Field/BillingFormTextFieldView.swift
Outdated
Show resolved
Hide resolved
Tests/UI/New UI/BillingForm/Validator/AddressLine2ValidatorTests.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/DefaultBillingFormViewModel.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/DefaultBillingFormViewModel.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/ViewModel/DefaultBillingFormViewModel.swift
Outdated
Show resolved
Hide resolved
...rm/Style/Default Implementation/BillingForm/Header/Cancel/DefaultCancelButtonFormStyle.swift
Outdated
Show resolved
Hide resolved
...rm/Style/Default Implementation/BillingForm/Header/Cancel/DefaultCancelButtonFormStyle.swift
Outdated
Show resolved
Hide resolved
Source/UI/NewUI/BillingForm/View/Field/BillingFormTextField.swift
Outdated
Show resolved
Hide resolved
return view | ||
}() | ||
|
||
private lazy var headerLabel: UILabel = { |
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 can't see this field used outside of the creation and setup, so I wonder if we need to have this property, or when we create it for the view, we just create, customise, add to view and allow to lose local reference.
Probably other similar UI components are doing the same thing?
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.
Resolved on slack
Source/UI/NewUI/BillingForm/View/Field/BillingFormPhoneNumberText.swift
Outdated
Show resolved
Hide resolved
a425692
to
f8036a8
Compare
f8036a8
to
0634474
Compare
@@ -1 +1 @@ | |||
github "marmelroy/PhoneNumberKit" "3.3.3" | |||
github "marmelroy/PhoneNumberKit" "3.3.7" |
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 know this review dragged longer than it was expected, but for visibility 3.4.0 was released just few hours ago 🙈 . It has added encoding and decoding strategies, so if that is something of interest we may create some separate maintenance task to review that functionality.
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.
-> Revert to 3.3.3
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.
Should be reverted to 3.3.3
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.
Done
Source/CheckoutColor.swift
Outdated
} | ||
|
||
extension UIColor { | ||
fileprivate convenience init(hex: String, alpha: CGFloat = 1.0) { |
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.
Might be nice to have this internal and unit tested with valid colour, invalid string, as well as with / without # .
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.
Done
let bundle = getBundle(forClass: forClass) | ||
guard let urlPath = bundle.url(forResource: self, withExtension: "pdf") else { return nil } | ||
guard let document = CGPDFDocument(urlPath as CFURL) else { return nil } | ||
guard let page = document.page(at: 1) else { return nil } |
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 document this page 1, as the method currently is slightly unclear. I'd expect that given a string, it will convert a pdf file from resources to an image.
Technically, we are converting one page at a time, and if I was to reuse this for an actual PDF document, not just an image file it would deliver wrong expectation
As I was documenting this comment, I realised using assets in SPM is more what you need and all of this could be avoided to begin with?
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.
TODO: a new ticket to refactor and test this change
"billingAddressTitle" = "Billing address"; | ||
"city" = "City"; | ||
"cancel" = "Cancel"; | ||
"done" = "Done"; |
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.
Do we have a tracking option to ensure the localisation is being followed after this PR is merged?
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.
This will be solved by @patrick-hoban-cko and @deepesh-vasthimal-cko
navigationController?.pushViewController(addressViewController, animated: true) | ||
return | ||
} | ||
navigationController?.present(viewController, animated: true) |
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.
Outside of the scope of this PR, but @harry-brown-cko , @deepesh-vasthimal-cko , I think the animated value should follow the decisions of the user of the SDK.
I would say we should offer it as a customisable option, that defaults from user device UIAccessibility.isReduceMotionEnabled
. May be worth checking if maybe OS overrides anyway, but there are many very valid reasons for animations to be disabled for an app (mostly accessibility but not only), so the SDK consumer may appreciate us following their approach or even improving 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.
Feedback from @patrick-hoban-cko
|
||
struct BillingFormFactory { | ||
// in order | ||
static let styles: [BillingFormTextFieldCellStyle] = [ |
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.
Sorry, before resolving can we discuss on it? Or at least open a discussion forum somewhere (Git, Slack, anything), so we can try and not forget about it.
import Foundation | ||
|
||
// Header Cell | ||
public protocol BillingFormHeaderCellStyle { |
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 going to lie, going ahead with these comments above the class/protocol declaration makes our publicly exposed code look unfinished.
It would be nice if our exposed code would make CKO appear knowledgeable and professional, not showing useless comments. This occurs in a few places, happy to flag them if we decide to do something about it.
import UIKit | ||
|
||
// Label element | ||
public protocol InputLabelStyle { |
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.
Before resolving, would you mind providing some form of closure to my argument? I would even settle for a follow up somewhere else.
All of this code is public facing, and I'd like to hope many dev teams would use it. I would like to know that when the likes of NewDay
or other fintechs with large iOS teams dig into our exposed code, they will be excited and trust us. Not make us look like we have a weak grasp of Swift / iOS functionality and question the dependency in the first place.
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.
Tried running locally. Not sure what state the functionality progress is in, but I got this.
Some opinions on this screenshot alone:
- the * in the label name is not matching the expectation of being compulsory or not
- Country appears twice, once compulsory, once with lower case letter
- It is not possible to dismiss keyboard by tapping background
- screen is dismissible by simply scrolling down the list too far by mistake
Additionally, there is a memory leak. In screenshot you can see Billing not presented, but 6 VCs in memory and a number of other entries.
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.
Approved but do not me merge as the base branch needs to be origin/release/4.0.0_RC
ccef6cb
to
b538fde
Compare
URL:
https://checkout.atlassian.net/browse/PIMOB-956
Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Frames Ios?
Put an
x
in the boxes that applyChecklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...