With Expo and React Native, we have to define styling using a plain JavaScript object because of the lack of CSS. In previous exercises, you may have used inline JavaScript objects for each component. This method is great for applying just a couple of styling rules but doesn’t work well for larger collections of rules.

When more styling rules are added, the readability of the code will degrade. This is one of the reasons why React Native created the StyleSheet API. With the StyleSheet API we can write our styling rules separately, and reference them when rendering the components.

// Using inline styling const AwesomeBox = () => ( <View style={{ width: 100, height: 100, backgroundColor: 'red' }} /> );

In the example above, we used inline styling.

With the StyleSheet API, we can pull the inline styling from our AwesomeBox component. By doing that we can reuse the styling rules and keep our AwesomeBox component readable.

// Using the StyleSheet API const AwesomeBox = () => ( <View style={styles.box} /> ); const styles = StyleSheet.create({ box: { width: 100, height: 100, backgroundColor: 'red' }, });

The most important method of the StyleSheet API is the .create method. With that, we can create a nested object with styling rules and refer to the styling rules. In the code above we used box as the reference to our styling rules.



During this exercise, we will use the previous code from the last lesson. Let’s expand the inline styling to experience some of the negative side effects of using inline styling. After that, we will refactor the code with the StyleSheet API.

Change the styling of the red box to implement the card component from the Material Design guidelines. Here is the styling that we want to apply:

width: 100, height: 100, backgroundColor: 'white', margin: 16, borderRadius: 2, shadowColor: 'black', shadowOpacity: 0.3, shadowRadius: 1, shadowOffset: { height: 1, width: 0.3 },

Great! While the styling works, the readability in our component isn’t perfect. When the styling gets more complex, the component will get harder to read.

Some styling properties require objects instead of plain numbers or strings. shadowOffset is one of these properties: it requires an object with width and height. When adding new rules, it’s recommended to check the required value in the documentation.

Add a second View with the styling for the card component.


Perfect! Now, let’s fix the readability with the StyleSheet API.

We can also create a custom Card component for our app, but that doesn’t fix the issue of readability. When the custom Card styling gets more complex, that component will be harder to read.

Move the inline styling to the styles variable, inside the StyleSheet.create method. To help you name things, use these two names:

  • layout for the root flexbox styling
  • card for our two card styling

Awesome! Did you notice the readability improvement in App? We also removed the duplicated card styling by referencing it in different View components.

One of the biggest downsides of the StyleSheet API is that our styles are static. We can’t change the styling based on user interaction from our StyleSheet.create method.

Press Run to continue to the next lesson where we dive deeper into the static nature of StyleSheet and how to overcome some limitations.

Take this course for free

Mini Info Outline Icon
By signing up for Codecademy, you agree to Codecademy's Terms of Service & Privacy Policy.

Or sign up using:

Already have an account?