Type checking with TypeScript
Last updated
Was this helpful?
Last updated
Was this helpful?
There are 6 main interfaces that you'll use throughout your experience with Modalfy:
- Interface of the modal stack configuration (needed once).
- Interface of the modal configuration options.
- Interface of the modal
prop exposed by the library.
/ - Interface of the modal
prop exposed by the library (specifically for modal components).
- Interface that adds type support of the modalOptions
property (specifically for Hooks modal components).
The 6th and last main interface will actually be provided by you, as Modalfy v2 brought support for modal params type. That interface is going to be used mainly by , and . But for now: let's see how to use the other interfaces we just mentioned.
These interfaces should be the ones you use the less. They're the ones that will ensure the type safety of the 2 arguments . So if we were to reuse the same initial example we say in the , we'd now have:
And from there, the type checker will get to work and let you know if you're doing something wrong.
If you're inside a modal component and not a "regular" component, you should use ModalComponentProp
instead.
If you're using useModal()
Hook, no need to employModalProp
as the Hook itself will take care of all the typing. Simply provide your params interface to the Hook as such useModal<ModalStackParams>()
(explained below).
The main and potentially only use case for ModalProp
then is when you're using a Class component.
#L5
with ModalStackParams
. It's an interface you'll have to build that will represent the complete tree of your modals and the types their params are expecting.
From #L7
to #L11
, we're letting TypeScript know that <PokedexCard/>
expects 3 props that should comply with the types specified in ModalStackParams
. We're doing this to ensure the type safety of these 3 props because we're using them L#24
to open 'PokedexEntryModal'
and pass them as params.
If we were to write ModalStackParams
, we can now guesstimate that it could look something like this a minima:
ModalComponentProp
/ModalProps
should only be used with modal components (rendered by Modalfy)!
If we reuse our PokΓ©dex example, first we'd need to define our ModalStackParams
as explained at the end of the previous section.
ModalComponentWithOptions
is only meant to be used with Hooks modal components. If you're working with classes, simply use the staticmodalOptions
property as explained below.
Starting with v3.5.0
you're now able to omit to provide your equivalent of ModalStackParams
to modalfy's methods. In order to do so:
Declare your own ModalStackParams
type:
Create a react-native-modalfy.d.ts
declaration file. Could be at the same file level where createModalStack
is called and add:
Get full support of types out of the box:
This interface allows you to type check the modal
prop that your regular component will get access to by using HOC. This means that you'll have to keep a few things in mind:
Now that we've covered the gotchas, let's see in action. In this example, we created a <PokedexCard/>
component that's will open a modal with the full details about a specific Pokemon, with its name, type and entry number in the :
Lots of things are happening in this snippet, but if you're already familiar with , this should get you excited! Let's dissect this snippet.
You can have a look at the Example provided and available to see what ModalStackParams
could look like/be used in a real-world scenario.
You'd also realize that we didn't pass ModalStackParams
as a generic to #L42
, instead, we directly provided it to React.Component
#L15
, via Props
created #L13
. As you may know, with TypeScript, React.Component
is a that accepts up to 2 arguments: React.Component<Props, State>
. That's why ModalProp
also accepts up to 2 arguments, your params interface and your component props and returns a type with your props type + the new modal
prop. There are a few things to notice here:
If you have any State
interface, you'll have to provide it to React.Component
as a second argument, not .
If your component doesn't expect any props, you don't have to provide a second argument to ModalProp
. If you want, you can even use it without providing the params type. This means that the most basic way of using is class PokedexCard extends React.Component<ModalProp>
On the contrary, providing your params types to gives you access to some sweet autocompleting experience (try to see what you get when you trigger it on for instance)!
These types work on the same principles as with just some key differences to keep in mind. The first and most important is:
If the component you're working on is not rendered by Modalfy directly/part of your config, you should use instead.
Given that we're in a specific modal component, accepts a 3rd argument, corresponding to the name of the modal the component you're writing represents:
But starting with v3.5.0
, we now have a simplified version of ModalComponentProp
named .
And then, our 'PokedexEntryModal'
modal could look like this (granted ):
Given that you can reuse the same component for several modals, you can replace that 1st argument with a to make everything work.
Although you'll never manually render <PokedexEntryModal>
yourself, / voluntarily expects props types as your modal component could be getting props from some HOCs. ie:
Please check out the /
API reference to have an exhaustive list of what it brings with it.
As we saw in the guide, you have 3 different ways to provide options to a modal. While the first 2 are type-checked during the modal stack creation, only the 3rd one involves typing modalOptions
from within the modal component itself.
To do so, simply pass your component props to and you're done! The interface will also directly take care of the fact that you're using it on a component, so no need to use React.FC
with it. ie:
If you're working with a class, you'll just have to directly type the staticmodalOptions
property with the same we used to type our modal stack. eg: