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.
Instructions
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 withwidth
andheight
. 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 customCard
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 stylingcard
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.