Skip to content
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

Closed
wants to merge 27 commits into from
Closed

Conversation

cpojer
Copy link
Contributor

@cpojer cpojer commented May 7, 2019

Summary

Continuation of #24687

Issue: Polish the "new app screen"
This is the pull request for the new intro screen proposal in react native as directed by @cpojer

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:

type 1

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label May 7, 2019
@cpojer
Copy link
Contributor Author

cpojer commented May 7, 2019

@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?

@cpojer cpojer changed the title Polish app screen Polish the new app screen May 7, 2019
@react-native-bot react-native-bot added the Type: Enhancement A new feature or enhancement of an existing feature. label May 7, 2019
@orta
Copy link
Contributor

orta commented May 7, 2019

Yeah, this looks good to me.

I don't know if it's your plan, but I'd love it if the index.js from this was the file in the template in your app, so you see some examples on how to do styling, platform checking, ScrollViews etc. ( e.g. not just render() { <NewAppScreen/> } in user-land code)

Libraries/NewAppScreen/index.js Outdated Show resolved Hide resolved
@cpojer
Copy link
Contributor Author

cpojer commented May 7, 2019

@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?

@orta
Copy link
Contributor

orta commented May 7, 2019

My opinion, based on the idea that this is also "sample code" for when you first see react native. Move anything too 'complex' into react-native which is privately exported (and not considered the API):

Making the index.js' header more like:

import {View, Text, StyleSheet, ImageBackground} from 'react-native';
import {Header, Section, LearnMoreLinks, colors} from 'react-native/components/new-app-screen';

Which would contain the components we see today:

  • Header
  • Section
  • Learn More Links
  • colors
  • An abstraction that combines the Fragment, and the two SafeAreaViews?
  • I'm 60/40 on moving ReloadInstructions and DebugInstructions into it too.

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:

  • Using a ScrollView
  • Using a StyleSheet (and how it hooks up to the style prop)
  • Using a Text and understanding how the text is a child of it
  • (Ideally) Using a TouchableOpacity to show how to do something which interacts (from reading the current code, this looks tricky)

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',
};

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

Copy link
Contributor

@eliperkins eliperkins left a 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',
Copy link
Contributor

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.

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,
Copy link
Contributor

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} />
Copy link
Contributor

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 SafeAreaViews. My understanding is that the SafeAreaView with the children should handle both top and bottom safe area insets.

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?

Copy link
Contributor

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!

Copy link
Contributor

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',

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.

sectionTitle: {
fontSize: 24,
fontWeight: '600',
color: '#000',

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use Colors.black.

@cpojer cpojer force-pushed the polish-app-screen branch from 7f9c95f to efc40bc Compare May 8, 2019 13:41
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a 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.

@cpojer
Copy link
Contributor Author

cpojer commented May 8, 2019

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:

@cpojer cpojer mentioned this pull request May 8, 2019
5 tasks
@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @cpojer in 6b393b2.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label May 8, 2019
facebook-github-bot pushed a commit that referenced this pull request May 9, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. p: Facebook Partner: Facebook Partner RN Team Type: Enhancement A new feature or enhancement of an existing feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.