Add pagination support to EventsByOrganization query about talawa-api HOT 15 OPEN

Would depend on how the query is modified in the backend. A proper approach should be established first.

I've documented the standard approach to be followed throughout talawa-api for implementing pagination using the graphql connections:- https://docs.talawa.io/docs/developers/talawa-api/pagination

Implement pagination for EventsByOrganization

Again, REST like patterns should not to be followed with graphql, relationships and fetching patterns should be expressed in the graph. This is an anti-pattern:-

type Query {
  eventsByOrganization(organizationID: ID!): EventsConnection
}

The events associated to an organization should be exposed like this:-

type Organization {
  events: EventsConnection
}

On the client side querying for the events within an organization would look like this:-

type OrganizationEventsQuery($cursor: String, $limit: Int!, $organizationID: ID!) {
  organization(id: $organizationID) {
    address
    phoneNumber
    events(first: $limit, after: $cursor) {
      edges {
        cursor
        node {
          id
          ...other event fields
        }
      }
      pageInfo {
      ... fields
      }
    }
  }
  name
}

The advantage here is that you can fetch other fields like address, phoneNumber, name etc., that exist on the organization along with the events associated to that organization. This is more efficient because the client only sends 1 network request to fetch everything that is needed. The server takes care of resolving everything listed in the query.

When the next set of events are to be fetched(connection is to be traversed further) a new network request would be made with a non-null value for the $cursor variable. This time there's no need to fetch the organization fields like address, phoneNumber, name etc., because they were already fetched by the very first network request. This would look like this:-

type OrganizationEventsQuery($cursor: String, $limit: Int!, $organizationID: ID!) {
  organization(id: $organizationID) {
    events(first: $limit, after: $cursor) {
      edges {
        cursor
        node {
          id
          ...other event fields
        }
      }
      pageInfo {
      ... fields
      }
    }
  }
}

To understand how the client implementation would work, take a read:-

1. https://www.apollographql.com/docs/react/pagination/overview
2. https://www.apollographql.com/docs/react/pagination/core-api
3. https://www.apollographql.com/docs/react/pagination/cursor-based#relay-style-cursor-pagination
4. https://commerce.nearform.com/open-source/urql/docs/basics/ui-patterns/#infinite-scrolling
5. https://commerce.nearform.com/open-source/urql/docs/graphcache/local-resolvers/#pagination

from talawa-api.

@aashimawadhwa @rishav-jha-mech @DMills27 PTAL and comment

from talawa-api.

@xoldd This was discussed frequently in the past, however related to news feeds. PTAL too

from talawa-api.

@Azad99-9 @meetulr Do you think this can be implemented without the UI/UX functionality being affected for both Admin and Mobile?

from talawa-api.

@palisadoes For the mobile part the UI should be tweaked to accomodate the pagination.

from talawa-api.

Both the admin and mobile will need to be updated simultaneously according to the changes in the API. We'll need contributors for both. Would depend on how the query is modified in the backend. A proper approach should be established first.

from talawa-api.

1. That's what I figured. We don't want to break the apps.
2. Will we need to modify the newsfeed and its infinite scrolling?

from talawa-api.

When the next set of events are to be fetched(connection is to be traversed further) a new network request would be made with a non-null value for the $cursor variable. This time there's no need to fetch the organization fields like address, phoneNumber, name etc., because they were already fetched by the very first network request. This would look like this:-

Yes we already use a similar approach in organizationsConnection query.

from talawa-api.