Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

How to type props of a route with Typescript? #103

Closed
eivindml opened this issue Oct 21, 2022 · 7 comments
Closed

How to type props of a route with Typescript? #103

eivindml opened this issue Oct 21, 2022 · 7 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@eivindml
Copy link

Is there an exported type we can use to type the props?

In Next.js this is type like:

context.params?.id // undefined | string | string[]

app/blog/[id].js

export default function BlogPost({ route }) {
  return (
    <Text>
      {route.params.id}
    </Text>
  );
}
@koka0012
Copy link

Expo Router is based in react-navigation, which that means you can use react-navigation props to type your rote params.
Here's an example:

https://reactnavigation.org/docs/typescript/

@karlhorky
Copy link
Contributor

karlhorky commented Nov 8, 2022

Would be good to get an example of usage of NativeStackScreenProps in a working example app eg. in apps/demo to see if there are any differences with the way that expo-router handles this vs vanilla react-navigation.

Eg. does this example below from the the link from @koka0012 translate 1-to-1 to usage in expo-router?

import type { NativeStackScreenProps } from '@react-navigation/native-stack';

type RootStackParamList = {
  Home: undefined;
  Profile: { userId: string };
  Feed: { sort: 'latest' | 'top' } | undefined;
};

type Props = NativeStackScreenProps<RootStackParamList, 'Profile'>;

For example, one difference that I could imagine would be that the keys would be lowercase in expo-router, eg:

type RootStackParamList = {
  home: undefined;
  profile: { userId: string };
  feed: { sort: 'latest' | 'top' } | undefined;
};

Maybe also in the app/details.js example on the Passing parameters to the routes docs page...

cc @EvanBacon

@JClackett
Copy link

Yes please to exported type for route's!

@danielkv
Copy link

danielkv commented Dec 1, 2022

Having that, directly from expo-router would be awesome 😎

@EvanBacon
Copy link
Contributor

My focus is primarily on getting things working consistently without errors, but I would love to have some fully automated type system in the future.

Off the top, we probably need the following:

  • <Link /> typed correctly.
  • Some guide on manually typing the routes for useHref<...>()
  • Improved types for useLink()

Further, it would be nice to have some automatic typing (far in the future as this is fragile and strenuous to maintain):

  • useLink.replace('...') should autocomplete the available routes.
  • <Link href /> should support autocomplete.
  • Perhaps dynamic routes could be automatic.
  • Could make a TypeScript service for vs code which adds autocomplete for ErrorBoundary and other exports.

@marklawlor probably has some good ideas for this.

@EvanBacon EvanBacon added enhancement New feature or request help wanted Extra attention is needed labels Dec 16, 2022
@karlhorky
Copy link
Contributor

Nice, thanks for the answer!

Do your lists above also include the route parameters, which were the things that the original issue description and my comment above were referring to?

@JClackett
Copy link

JClackett commented Dec 16, 2022

Yeah I think one of the main things I needed was just a generic that would give me the props that each route has, I dont (right now) need type safe route params etc

e.g.

import { RouteProps } from "expo-router"

interface MyParams {
 id: string
}
export default function MyRoute(props: RouteProps<MyParams>) {
   const id = props.params.id // or whatever the actual route props object is
... 

@expo expo locked and limited conversation to collaborators Feb 9, 2023
@EvanBacon EvanBacon converted this issue into discussion #272 Feb 9, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants