Passing props to Cells

Get Help and Help Others
1

I have a cell which lists multiple objects

export const QUERY = gql`
  query ObjectListCellQuery {
    objects {
      id
    }
  }
`;

Is there currently a way to say pass a onObjectClicked: () => void callback function to the cell without modifying the QUERY or the beforeQuery hooks which also keeps TypeScript from complaining about unknown intrinsic props?? i.e.

<ObjectListCell onObjectClicked={(obj) => alert(`You clicked object ${obj.id}`)} />
2

Good evening @zygopleural,

I just stumbled upon the very same issue where I wanted to pass a Component Props to one of my Redwood Cell.

Here’s how I managed it :

  1. I implemented beforeQuery as followed (since beforeQuery's return is your Cell’s variables) :
export const beforeQuery = (props) => {
  // eslint-disable-next-line @typescript-eslint/no-unused-vars
  const { RecordRenderer, ...rest } = props

  return { variables: rest, fetchPolicy: 'cache-and-network' }
}

Note that this comment allow me to ignore the ESLint warning.

  1. Then I tweaked the type of the Success export to include my additional prop :
export const Success = ({
  record,
  RecordRenderer,
}: CellSuccessProps<FIND_RECORD_BY_ID> & {
  RecordRenderer: ({ record }: { record: Partial<Record> }) => JSX.Element
}) => {
  return <RecordRenderer record={record as Partial<Record>} />
}

And finally I could pass my custom Component to my RecordCell !

<RecordCell RecordRenderer={RecordDetail} id={idRecord} />

I hope it helps :slight_smile:

3

Hi @Francois

Yeah that is basically what we ended up doing, just wondered if there was a nicer way or something in the roadmap to not have to ignore the eslint and typescript warnings :frowning:

1 Like
4

I think this issue is very relevant. It really limits the usage of the cells to not be able to do that. I am also surprise because the doc says:

Cells also make sure to funnel the right props to the right component. Loading , Empty , Failure , > and Success all have access to the props passed down from the Cell in good ol’ React fashion

5

Ok, actually, the answer there is working: Passing stuff into cells without adding a parameter to the sdl

6

Yeah, it’s important to realize that all code/types that RW generates is best-effort code that works in the most common scenarios. As you start doing more advanced things you’ll probably start having to modify and extend the generated code.

In this specific example the correct thing to do is to extend the type. You can do it inline like @callingmedic911 showed in the linked PR

CellSuccessProps<GoodPeopleQuery> & { notAVar: string }

Or you can create your own type and use that

interface SuccessProps extends CellSuccessProps<GoodPeopleQuery> {
  notAVar: string
}

export const Success = ({ people, notAVar }: SuccessProps) {
  //...
}
2 Likes
7

Yes, thanks for the clarification. Do you know if there is any good reason for having the result of the query merged with the props? Looks to me like the props should be inside a second argument to these cells’ callbacks

8

Yeah, just because it’s easier to get at them if they’re not inside a separate object

1 Like