-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(www): add OS and version information to the contact view data form #1725
Conversation
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.
@daniellacosse Where do you think shared / utility libraries should live? I don't think this should live here but there's no clear better place to put these right now. Any preferences?
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.
infrastructure!
052a98f
to
090b667
Compare
Codecov ReportAttention:
📢 Thoughts on this report? Let us know!. |
090b667
to
6aaeea5
Compare
…tactView` property.
…n client and manager variants.
… button to clear the entire element.
…values more declaratively.
…he `ContactView` component.
6aaeea5
to
9cdf436
Compare
434c3ca
to
fa8a7c9
Compare
@@ -289,3 +295,12 @@ export class ContactView extends LitElement { | |||
} | |||
} | |||
} | |||
|
|||
function getOperatingSystemValue(): string | undefined { |
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.
We should add this to infrastructure as well!
What's your rationale behind separating the boolean constants and the strings? Why not just a getOperatingSystemValue
that returns an enum/string union?
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 is specific to the form values that Salesforce expects. They shouldn't be re-used elsewhere. In fact, I'm going to update them once I get the correct API values.
I went with a boolean as its a fairly common pattern for this type of check; it's slightly more efficient, but mostly it allows for more readable re-use if we want to use it elsewhere. Compare:
if (IS_ANDROID) {
doSomething():
}
if (getOperatingSystemValue() === OperatingSystem.ANDROID) {
doSomething();
}
I could created a shared infrastructure function that returns an enum, and then map the enum values to the form strings as a second step. Seems a bit more convoluted though, so I'm hesitant to add it just for the sake of it? But I can be convinced.
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.
Yes I do find the whole approach a bit anemic - ideally we'd have a UserAgent singleton class that has these methods on it e.g.
const agent = new UserAgent();
agent.isAndroid();
which could then be extended later
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.
infrastructure!
9cdf436
to
f28a638
Compare
7cd4c2a
to
330fd53
Compare
Going to abandon this PR after doing some more exploring. Version, OS, and build are already available elsewhere. |
No description provided.