Additional summary field for canceledTrips

[partisaani]

Is your feature request related to a problem? Please describe.
I am in the process of creating a general alert/canceledTrips view for HSLdevcom/digitransit-ui. The core idea is to render the alerts and cancellations in simple card form. In case an alert affects several entities of same type OR if there are multiple canceledTrips, we'd like to group those under a single card or element and present them a bit like the following example:
🚌 [12:30] [12:35] [+2]
🚃 [10:00] [10:15] [+3]

However, in case of canceledTrips the grouping is not representing the overall status of the transportation system correctly if we cannot present the user with the exact amount of how many cancellations of certain mode the system holds in total. To underline the case let's take the following example where the system is set to query canceledTrips(first:5) and presents them to the user:
🚌 [12:30] [12:35] [+4]
🚃 [10:00]
But in reality the following page has 1...n more canceledTrip items for trams, metros and ferries that are not conveyed to the user in any way. The endpoint does return hasNextPage property which could be used in conjunction with a Load more CTA to query for more results, but this does not solve the issue of UI momentarily presenting the user with erroneous information about the system. The user would "just have to know" that even though the tram only lists one canceled trip, there may be more hiding somewhere. A weird loot box mechanic of sorts if you will.

Goal / high level use-case
A view with paged results is able to convey a more accurate state of the system to the user without having to fetch all of the results

Describe the solution you'd like
canceledTrips endpoint - or perhaps all of the endpoints which return paged data - is enriched with summary property which returns a high level snapshot of paged information i.e.

canceledTrips {
  pageinfo { ... }
  nodes { ... }
  summary {
    total: 72
    modes {
      bus: 50
      tram: 20
      metro: 2
    }
  }
}

Describe alternatives you've considered
Querying canceledTrips without first|last parameter but this is risky as there may be 1...n canceledTrips.

[optionsome]

I discussed this with @partisaani and re-read a bit of the Production Ready GraphQL book. I think we should have some filters for the query (just mode filters for now) and just one field that tells how many objects there are in total. The filters could look something like:

canceledTrips(
    ...
    filter: CanceledTripsFilterInput
  )

"""
A collection of selectors for including or excluding trips from canceled trips search.

The `include` is always applied to select the initial set, then `exclude` to remove elements.
If only `exclude` is present, the exclude is applied to the existing set of results.

Therefore, if an entity is both included _and_ excluded the exclusion takes precedence.
"""
input CanceledTripsFilterInput {
  """
  A list of selectors for excluding canceled trips.
    
  An empty list or a list containing `null` is forbidden.
  """
  exclude: [CanceledTripsFilterSelectInput!]
  """
  A list of selectors for including canceled trips.
    
  An empty list or a list containing `null` is forbidden.
  """
  include: [CanceledTripsFilterSelectInput!]
}

"""
A list of selectors for including or excluding trips from canceled trips search. Null
means everything is allowed to be returned and empty lists are not allowed.
"""
input CanceledTripsFilterSelectInput {
  """
  Canceled trips from these transit modes should be included/excluded.
  """
  modes: [TransitMode!]
}

And then we could add an optional (we might reuse the type later and not sure if we want to guarantee that it always exists) totalCount field (it seems to be a standard naming convention for it) to the TripOnServiceDateConnection type.

[partisaani]

Filtering is a valid improvement as well as it would further prevent the weird lootbox "we do have some canceledTrips in store for you, we just don't know which page they are on" -mechanic.

[leonardehrenfried]

Presumably the idea is that you if you want to know how many trains and busses are cancelled then you call the resolver multiple times, a bit like this:

cancelledBusses: cancelledTrips(mode: BUS)
cancelledTrains: cancelledTrips(mode: TRAIN)

Am I correct?

[optionsome]

Presumably the idea is that you if you want to know how many trains and busses are cancelled then you call the resolver multiple times, a bit like this:

cancelledBusses: cancelledTrips(mode: BUS)
cancelledTrains: cancelledTrips(mode: TRAIN)

Am I correct?

Yes, and we would display n results from each mode and some (+136) button which would then allow you to paginate more results for the given mode like @partisaani described in the description.

[leonardehrenfried]

That's quite elegant and extensible. I like it.