-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[User Settings] Add new Preferences view #1716
[User Settings] Add new Preferences view #1716
Conversation
This reverts commit fc03aee.
@shawnborton updated |
Looks great! Perhaps we can make the margin below the first block slightly bigger to creates some more visual separation? Maybe like |
value={priorityMode} | ||
Icon={() => <Icon src={DownArrow} />} | ||
/> | ||
class PreferencesPage extends Component { |
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.
why did you convert this from a functional component? couldn't we keep it as a functional component and pass user
as a prop like we were doing before with priorityMode
?
The state you've added should be handled already by Onyx so as long as the isOn
is bound to the prop user.expensifyNewsStatus
I'm pretty sure it will update properly without the need for this to be a regular/pure component and reference state.
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.
Hey, so this was the direction I went down to follow the "offline first" approach. Basically if it was going purely based off the user.expensifyNewsStatus
then it would seem unresponsive/slow for users with no or slow connections. I guess a nice follow up to handle the errors would be to show a toast & reset back to the initial onyx value but I believe that's out of scope.
I can also revert it back to a func component and go solely off the prop if needed.
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.
Hmm I see that does make sense now but that makes me question whether the User.setExpensifyNewsStatus
should first be setting the data in onyx and then calling the API.
cc @tgolen what are your thoughts on this?
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 like the idea of optimistically setting the value in Onyx before calling the API, yeah. Then if the API fails, the Onyx data can be reset.
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.
Hmm, I'm not sure I agree with this, as I think we're going to end up with a lot of duplicated code with having to handle the case where we don't get a response at all and when we get a failed response (see here). I get that we want to keep that offline first functionality though, so I'm not really sure which is the best route to go.
@marcaaron this didn't get brought up when I first added User.setExpensifyNewsStatus
so I'm curious to see if you have opinions on this.
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 like the optimistic approach here as well. Only thought is that we should consider updating the value of this data with the data returned from the response instead of relying purely on response codes - but it's probably OK with this particular setting being a boolean and all.
I'm also inclined to wait and see how many examples like this we end up with (though I agree it will be a lot eventually). Would love to see a more elegant or baked in approach to this optimistic response pattern soon!
# Conflicts: # config/webpack/webpack.common.js # src/pages/home/HomePage.js # src/pages/settings/PreferencesPage.js
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.
Tested and work well! No idea if this is something we can change but I noticed a funny little animation when we navigate to the Preferences
page and you are subscribed to Expensify news.
Screen.Recording.2021-03-16.at.4.30.11.PM.mov
@NikkiWines yeah, noticed that as well. It looks like it's initialized to "off" and gets animated to "on": but looking at this closer...it seems inefficient that it's doing everything in the render rather than watching for prop changes. it looks like a pretty simple component if we wanted to re-create it and modify it instead of using the package. |
@Maftalion is there a way to customize how the toggle itself looks? In our mockups, we have the toggle at 50px wide by 28px tall, with the inner button at 22px by 22px. |
@shawnborton yup, updated the styles on the track/thumb: |
@roryabraham AFAIK the switch component isn't customizable enough to meet the design expectations: https://reactnative.dev/docs/switch. For example you can control thumb/track color but not it's height/width. Also you can't make all platforms render the "iOS switch". But yeah what I'm suggesting is if we don't want to use the 3rd party library, we can just create a components/switch component and implement something similar that's pure JS that fits the needs of design parity across all platforms. |
+💯 We should definitely do this. I don't think it will be very difficult at all. This helps to ensure consistent code patterns in our components which lowers the barrier of entry to other people who need to work on this. |
@Maftalion I also wanted to confirm again if you know what's going on with the picker menus? It looks like this exists on the current app, so this might not be your doing, but the border radius is now set to 0 instead of matching other inputs: |
@shawnborton hmm looks like it's using |
# Conflicts: # src/styles/styles.js
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.
One minor minor comment, but overall looking great! Tested on web and works well
@Maftalion do you mind adding that variable back in? It should have a value of |
@shawnborton sure! added that back in: |
Looks great, thank you! |
# Conflicts: # src/libs/Navigation/AppNavigator/AuthScreens.js
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.
Looks good!
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.
looks good overall just one thing I think we should do with the switch component.
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.
actually I'm reversing course on my last comments, I think your points are valid and not worth the refactor to functional component with so many unknowns or potential drawbacks.
# Conflicts: # src/styles/styles.js
nikki had already approved and the only new changes are fixing merge conflicts so i'm going to merge. marc and I also chatted about this PR 1:1 so i'm considered that an implicit approval too. merging so we get wrap this up as i've caused it to be drawn out for way too long already. |
Details
expensifyNewsStatus
valueFixed Issues
#1677
Tests
expensifyNewsStatus
is being updatedTested On
Video
Screen.Recording.2021-03-09.at.3.48.10.PM.mov
Web
Mobile Web
Desktop
iOS
Android