-
Notifications
You must be signed in to change notification settings - Fork 24.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
Polish the new app screen #24737
Polish the new app screen #24737
Conversation
@eliperkins @elucaswork @gengjiawen do you have any current feedback before landing this? If not, please approve it. I can then land it, and if you like you can send more PRs to polish it. @orta could you give this a spin and tell me whether it matches your mockup to the point where you feel comfortable shipping it? |
Yeah, this looks good to me. I don't know if it's your plan, but I'd love it if the |
@orta I'm trying to figure out what a good middle ground is for the App template. On one hand I don't want to increase the app size a lot or bloat the template but on the other I do want there to be more than a single React component that is inlined. Do you have any recommendation on a good balance? |
My opinion, based on the idea that this is also "sample code" for when you first see react native. Move anything too 'complex' into Making the
Which would contain the components we see today:
If this is the sample code to give you a feel for what your React Native app will look like, then it's good to show:
As these are kinda the primitives for making an app at all. Given that RN ships untranspiled, an editor should be able to jump to the 'hidden' components in RN to read. |
light: '#DAE1E7', | ||
dark: '#444', | ||
black: '#000', | ||
}; |
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 are mixing color names (white and black), hierarchy pattern (primary) and color states (lighter, light, dark). Think would be better to use only one pattern to name colors here, it will help to understand the code.
Suggestion:
export default {
bondiBlue: '#1292B4',
white: '#FFF',
whiteSmoke: '#F3F3F3',
pattensBlue: '#DAE1E7',
charcoal: '#444',
black: '#000',
};
I've used this site as a 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.
LGTM. Sounds good to land this as is, and iterate from here. There's a couple of odd things in there, but I can submit other PRs to clean them up after if we'd like.
backgroundColor: Colors.lighter, | ||
}, | ||
backgroundLogo: { | ||
position: 'absolute', |
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'm fine landing this in for now, but I definitely fear other folks learning RN and styling for the first time picking up on using absolute
to style things.
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.
Definitely agree with this, is position: absolute
required here? I hardly use it.
opacity: 0.2, | ||
alignItems: 'center', | ||
justifyContent: 'center', | ||
height: 540, |
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 these heights need to be explicit? What does this look like in landscape or on tablets?
const App = () => { | ||
return ( | ||
<Fragment> | ||
<SafeAreaView style={styles.topSafeArea} /> |
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'm still a bit confused why we need two SafeAreaView
s. My understanding is that the SafeAreaView
with the children should handle both top and bottom safe area 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.
@eliperkins I used two safe areas because I wanted the top safe area with the color of the header and the bottom with the color of the screen background. There is another way to do 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.
Ah, interesting! I hadn't thought about that use-case. This totally makes more sense why we would reach for multiple <SafeAreaView>
s now.
One option could be to use ScrollView
's contentInsetAdjustmentBehavior
: https://facebook.github.io/react-native/docs/scrollview.html#contentinsetadjustmentbehavior
To do this, we would have to move the ScrollView
up to be the root view (that is, outside of the SafeAreaView
this is currently containing it) and this will let UIKit take over on adjusting the insets for the safe areas. Then, by setting the background of the ScrollView
to be Colors.lighter
, we could accomplish this all without SafeAreaView
at all!
I put a Snack up of this here: https://snack.expo.io/@eliperkins/lonely-churros
The downside to this approach is that the end of our scroll view would then be the grey color as well. I think the trade off is better than over-prescribing <SafeAreaView>
s!
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 could also use Animated
to change the color of the <ScrollView>
's backgroundColor
while scrolling, but that seems a bit too complex for a sample app.
backgroundColor: Colors.lighter, | ||
}, | ||
backgroundLogo: { | ||
position: 'absolute', |
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.
Definitely agree with this, is position: absolute
required here? I hardly use it.
Libraries/NewAppScreen/index.js
Outdated
sectionTitle: { | ||
fontSize: 24, | ||
fontWeight: '600', | ||
color: '#000', |
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.
Please use Colors.black
.
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.
@cpojer is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Thanks for all your feedback. I'm going to land this so we have the initial version in the repo and we can keep iterating together. @eliperkins @lucasbento: would you two be interested in sending follow-up PRs? I made an issue for all the remaining items, see #24760:
|
This pull request was successfully merged by @cpojer in 6b393b2. When will my fix make it into a release? | Upcoming Releases |
Summary: Related to #24760 and #24737 This simplifies some styling within the components used for the New App Screen to help advocate for best practices when styling with CSS-like styles in React Native, as well as using React Native's own unique components. There's a bit more detail in each commit. Let me know if you'd like me to pull that info out into the PR description here! [General] [Changed] - Polished up new app screen component styling Pull Request resolved: #24783 Differential Revision: D15284851 Pulled By: cpojer fbshipit-source-id: 954db00d39fc0082bbd4dc96afa7d38dfb7f67d5
Summary
Continuation of #24687
This PR was created because the previous one could not be pushed to for some reason. I cleaned up a few small things and added the component as an example to RNTester so we can keep iterating. My plan is to land this, and then polish it and make it the default in a follow-up.
Changelog
[General][Added] - New Intro screen, Icons
Removed Lottie Integration
100% React Native 💥
Test Plan
npm run ios
should build the template app similar to this: