ViewPropTypes errorIf you’ve used React Native in the past 12 months, it’s likely that you’ve been using PropTypes as a means of type checking your components. Type checking is a way to safeguard your components and make sure that they’re used in the proper way.
While there is nothing wrong with using PropTypes to type check your components, you probably noticed that using React Native’s built-in PropTypes, like ViewPropTypes, will present a deprecation warning.
In this article, we’ll dive into why this deprecation happened and how to fix this issue.
Jump ahead:
PropTypes was, for a long time, the out-of-the-box solution provided by React Native and looked something like the following:
import React from 'react'
import { View, ViewPropTypes } from 'react-native'
import PropTypes from 'prop-types'
export const Component = props =>
return (
<View style={{ alignSelf: 'center' }}>
<View style={[styles.innerView, { backgroundColor: props.backgroundColor }]} />
<SomeOtherComponent />
</View>
)
}
Component.propTypes = {
numberProp: PropTypes.number,
boolProp: PropTypes.bool,
arrayProp: PropTypes.array.isRequired,
stringProp: PropTypes.string.isRequired,
backgroundColor: ViewPropTypes.style,
}
As mentioned above, this now results in an error message:
ERROR Invariant Violation: ViewPropTypes has been removed from React Native. Migrate to ViewPropTypes exported from 'deprecated-react-native-prop-types'.
Before React Native, React itself also had a huge turnover from PropTypes to external type checkers, like Flow and TypeScript. To understand the reason for this switch in React Native, it’s helpful to understand its history.
Without diving into all the details, there were two major reasons for this turnover that the React Native team confirmed: stricter type safety and compile time validation.
Using PropTypes validates your components at runtime, meaning the code needs to be run before type checking goes into effect. That’s the reason you can only see validation warnings after you start the development server of your application and in the console.
On top of that, the API for creating types with PropTypes is quite limited, mainly covering primitive types and barely covering more complex data types.
Tools like Flow and TypeScript are so-called static type checkers and check types at compile time, meaning that no code is required to run for validation. This means that your components can be type checked at any moment — even in continuous integration — without much overhead. Both options also have much more extensive APIs to provide stricter and safer typings for your application.
For these reasons, React Native started the deprecation process back in 2018. Finally, version 0.68 included a deprecation warning to notify the library users of this upcoming change.
Several months later in June 2022, all PropTypes were removed from React Native in 0.69 and moved to another package, which resulted in the previously shown deprecation error.
While you now know when and why PropTypes were deprecated, it still doesn’t solve the error at hand. In general, there are three different community approaches to addressing it, and what the React Native team themselves have recommended.
The most common option that the community turned to was the most straightforward one: patching the React Native library using something like patch-package. Basically, this boils down to changing the existing library’s code to re-add the removed PropTypes so your existing code works again.
While this was a popular solution among the community, the React Native team was less supportive of it. Patching the library ultimately only masks the underlying problem for short-term gains, which can have significant on the long term maintainability of your project. For that reason, it’s also the least desirable solution on paper.
This doesn’t mean that patching in itself should be absolutely forbidden. In fact, the React Native team also states that it’s sometimes necessary to patch when libraries using React Native haven’t removed their PropTypes usages yet.
But even in those scenarios, patching the libraries on your side should be your last resort when it hasn’t been fixed on the libraries’ side yet.
The second solution is following the advice of the deprecation warning, which means installing and making use of the newly created deprecated-react-native-prop-types library. This package contains all the deprecated and removed PropTypes, but was moved by the React Native team into a new, separate location.
Using the new library requires you to update all your PropTypes imports and make sure that they point towards the new location, instead of the previous react-native. In simple scenarios, search-and-replace should be able to take care of this.
However, if your case is more complex, e.g. large files importing several types and code from react-native, then that won’t work for you. In these scenarios, you should reach out for a code-mod or create one yourself.
Similar to patching React Native, this should still be seen as a temporary solution. While it’s an easy solution that a large chunk of the community will likely favor, it’s once again more of a Bandaid solution, rather than a long-term one.
Even though you’re not hiding the problem like you’d do in the previous solution, you’re basically waiting to address the issue until later. If you don’t deem the issue worth solving immediately, the question becomes when — and whether — you will change your mind and consider it worth your effort.
The most optimal solution, and the one recommended by core React Native maintainer Ricky Hanlon, is to make the switch to a proper type system. As we’ve discussed earlier in this article, there are drawbacks and limitations on what a runtime typing system can do for you.
You’ll see significant, long-term maintainability benefits from a static type checker in the long-term. Whether that type checker is TypeScript or Flow is up to you, as both are perfectly fine choices.
At the moment, TypeScript is by far the most popular choice in the field. However, there isn’t really a bad choice. In the end, the most important thing is making the switch from a runtime type checking system towards a static one.
Obviously, there aren’t only benefits to this solution, otherwise the community would have unanimously tended towards this. The main drawback of this solution in this particular context is the required amount of effort.
Compared to the other solutions, adopting a new type system requires by far the the most effort. For this reason, most developers want to avoid addressing this problem and use other, less-desired solutions because they require significant less time and effort — and in the end, rewriting all of your existing types into a completely different structure and system is not a trivial thing.
Deprecating PropTypes is a step by the React Native team to encourage the community towards static type checkers like Flow and TypeScript, which hold several key advantages over runtime type checkers like PropTypes.
Specifically, they provide stricter type safety, faster type validation, and more extensive options to validate your code and allow typechecking to be integrated into CI/CD — alll of which have a positive long-term impact on the maintainability and development of your project’s code.
LogRocket is a React Native monitoring solution that helps you reproduce issues instantly, prioritize bugs, and understand performance in your React Native apps.
LogRocket also helps you increase conversion rates and product usage by showing you exactly how users are interacting with your app. LogRocket's product analytics features surface the reasons why users don't complete a particular flow or don't adopt a new feature.
Start proactively monitoring your React Native apps — try LogRocket for free.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Fix sticky positioning issues in CSS, from missing offsets to overflow conflicts in flex, grid, and container height constraints.
From basic syntax and advanced techniques to practical applications and error handling, here’s how to use node-cron.
The Angular tree view can be hard to get right, but once you understand it, it can be quite a powerful visual representation.
In this post, we’ll compare Babel and SWC based on setup, execution, and speed.
Learn more →
