-
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
Follow up to comments on PR1559 #1756
Conversation
Sorry thought I had taken this out of draft but I must have forgot. Updated! |
HOME: '', | ||
SETTINGS: 'settings', | ||
SETTINGS_PROFILE: 'settings/profile', | ||
SETTINGS_PREFERENCES: 'settings/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.
NAB: Random thought; these could be nested to make them a little more organized.
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.
Only problem with that is that ROUTES.SETTINGS
is already 'settings'
so what convention should we use then? Perhaps something like:
SETTINGS: {
ROOT: 'settings',
},
I'm kind of partial to the underscore 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.
Cool, works for me!
key: PropTypes.string, | ||
})), | ||
}).isRequired, | ||
|
||
// The current view object that has a render method to call | ||
// Object containing descriptors for each route with the route keys as its properties |
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 love these verbose comments!
* a screen, otherwise any child navigators won't be connected to the navigation tree properly. | ||
* | ||
* @returns {Object} | ||
*/ | ||
getCurrentViewDescriptor() { |
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 remember I wanted to comment about this in the original PR, and I never did, and then when I remembered about it, I couldn't find the spot. So, sorry this is a late comment!
My thought was that it looks like this could be a functional component and just have this logic as part of the function before the return
. I'm fine with this being a NAB, but I just didn't think there was any benefit to making this a class component and wanted to get your thoughts on 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.
Sure, this is an easy enough change to make and enforces the preference to use function components.
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.
Thanks!
throw new Error(`The path must start with '/' (${path}).`); | ||
} | ||
|
||
const normalizedPath = !path.startsWith('/') ? `/${path}` : path; |
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 could have sworn we had a utility for adding slashes to the beginning of things, but for the life of me, I can't find it. I can't remember where it was used either... Does anything come to your mind? If not, then ignore this comment.
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.
There is one used in config.js I think, but it adds them to the end not the the front
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.
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.
Ah yes! That's the one. It might be nice to add these to Str
some day.
src/libs/Navigation/linkingConfig.js
Outdated
@@ -7,79 +9,79 @@ export default { | |||
initialRouteName: 'Report', | |||
screens: { | |||
// Report route | |||
Report: 'r/:reportID', | |||
Report: `${ROUTES.REPORT}/:reportID`, |
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.
Does the /:reportID
work with react-navigation? I was trying to find this in their docs and couldn't really find anything. This is what lead me to ask you about the second param for navigate()
the other day.
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.
My concern with this is that there is route information here that is not contained within ROUTES.js
so it's not apparent when /:reportID
should be used and when it shouldn't. It looks to me like the only time that ROUTE.REPORT
is referenced is when checking that path has r
in the array (I always see it with includes()
) so I wonder if there is a better way to do this to still maintain the functionality that is needed.
One solution that comes to mind is having:
// ROUTES.js
{
REPORT: 'r',
REPORT_WITH_ID: `r/:reportID`,
}
which would allow all information about the route to be contained in that file. 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.
To answer the first question.... yes! The /:reportID
does work with react-navigation
there's some more information here:
https://reactnavigation.org/docs/configuring-links/#passing-params
As for the second comment, you raise a good point and I think it does make sense to document these paths as constants with the parameters we expect to use with them. We might not run into too many cases where we are using ROUTES.REPORT_WITH_ID
, but it seems like a good way to document how the routes will be used for now.
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.
Cool, thanks for linking that!
@@ -9,8 +10,11 @@ const propTypes = { | |||
// Array of additional styles to add | |||
style: PropTypes.arrayOf(PropTypes.object), | |||
|
|||
// Returns a function as a child to pass insets to | |||
children: PropTypes.func.isRequired, | |||
// Returns a function as a child to pass insets to or a node to render without insets |
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 love how this solution turned out. It's much better than the dual components that I suggested.
Thanks for the comments @tgolen ! Updated. |
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 awesome!
@Beamanator do you want to go through this and take a quick look? Once you approve it, you can go ahead and merge it. |
@tgolen yeah i'd love to check it out this morning! i'll merge when i'm done :D |
Nice updates @marcaaron ! Especially love the change to |
Details
cc @tgolen I'm not really sure why I didn't put these in an actions file. Maybe subconsciously was not sure where exactly they even belonged... I don't mind that action files are the only things that should set Onyx data. But still think it's often not clear how to group stuff.
Fixed Issues
Addresses Slack Comment here and @tgolen post merge review on #1559
Tests
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android