{"id":97,"date":"2025-02-03T15:53:08","date_gmt":"2025-02-03T15:53:08","guid":{"rendered":"https:\/\/kerner.digital\/?p=97"},"modified":"2025-11-21T22:23:59","modified_gmt":"2025-11-21T22:23:59","slug":"timeline-connector-part-2-implementing-record-filtering","status":"publish","type":"post","link":"https:\/\/kerner.digital\/?p=97","title":{"rendered":"Timeline Connector Part 2: Implementing Record Filtering"},"content":{"rendered":"\n

In Part 1<\/a> we built the basic shape of a custom timeline connector: defining the interfaces, wiring up the core methods, loading data, and making the control happy enough to render your records.<\/p>\n\n\n\n

Now it\u2019s time for something users will actually notice: filtering<\/strong>.<\/p>\n\n\n\n

Filtering is the magic that lets them stop scrolling like maniacs and see only the subset of records they care about.<\/p>\n\n\n\n

This part walks through the concepts, the UI, and the backend logic you\u2019ll need to support filtering in a clean, reliable way.<\/p>\n\n\n\n


What filtering means in a custom timeline connector<\/strong><\/h2>\n\n\n\n

Filtering in the timeline connector isn\u2019t fundamentally different from filtering list views or subgrids. The twist is that the timeline expects the filtering logic to live inside your connector<\/strong>, not the platform.<\/p>\n\n\n\n

Your connector decides:<\/p>\n\n\n\n

    \n
  • what filters exist<\/li>\n\n\n\n
  • how they\u2019re displayed<\/li>\n\n\n\n
  • how they get translated into queries<\/li>\n\n\n\n
  • how results are refreshed<\/li>\n<\/ul>\n\n\n\n

    Typical use cases:<\/p>\n\n\n\n

      \n
    • show only records of a specific type<\/li>\n\n\n\n
    • filter by status<\/li>\n\n\n\n
    • filter by date range<\/li>\n\n\n\n
    • narrow the timeline to only assigned-to-me records<\/li>\n<\/ul>\n\n\n\n

      The timeline doesn\u2019t enforce a specific model. That freedom is great right up until you have to design it, because the platform itself has no idea how your data source works<\/strong>. It doesn\u2019t know:<\/p>\n\n\n\n

        \n
      • what backend you\u2019re querying<\/li>\n\n\n\n
      • how your records relate to each other<\/li>\n\n\n\n
      • what your entity schema looks like<\/li>\n\n\n\n
      • whether your data even supports server-side filtering or sorting<\/li>\n\n\n\n
      • or if the source is something exotic like an external API, a custom index, or a flat stream of events<\/li>\n<\/ul>\n\n\n\n

        So the platform pushes that responsibility onto the connector: you expose filters, you translate them, you execute the query.<\/p>\n\n\n\n

        This avoids assumptions, but it also means the entire UX, query model, and edge-case handling lands on the connector developer<\/strong>.<\/p>\n\n\n\n

        There is<\/em> an argument to be made that the platform could improve this. For example:<\/p>\n\n\n\n

          \n
        • If connectors could optionally implement a\u00a0standardised interface describing their schema and sortable\/filterable fields<\/strong>, the timeline could handle some logic itself.<\/li>\n\n\n\n
        • The platform could do client-side sorting when appropriate.<\/li>\n\n\n\n
        • The control could validate filters before they hit your backend.<\/li>\n\n\n\n
        • Or at minimum, the connector could declare which operations (sorting, grouping, filtering) are supported by the backend and let the timeline enforce those rules.<\/li>\n<\/ul>\n\n\n\n

          But for now, the connector is fully responsible. You define the filtering surface, and the platform stays agnostic.<\/p>\n\n\n\n


          Extending the connector interfaces<\/strong><\/h2>\n\n\n\n

          In Part 1 we introduced the basic interfaces. Now we expand them with fields responsible for filtering.<\/p>\n\n\n\n

          At minimum, you will need to enrich:<\/p>\n\n\n\n

            \n
          • getFilterDetails\u00a0\u2013 tells the timeline what filters your connector supports<\/li>\n\n\n\n
          • getRecordsData\u00a0\u2013 actually respects those filters when loading items<\/li>\n\n\n\n
          • internal state objects \u2013 store current filter selections from the UI<\/li>\n<\/ul>\n\n\n\n

            I like to keep things clean so I’ll implement a separate class for doing the filtering:<\/p>\n\n\n\n