Conversation

• I Indiekit Demo Indiekit Demo remote 2 hours ago You are here

  💬 @rmdes — PR #1016 : feat: filter the list of posts by post type and text

  Commentaire de pull request · PR #1016 feat: filter the list of posts by post type and text · @rmdes

  All three done, and a suggestion on the fourth.

  1. Filters in a details. The search is inside one now, collapsed unless a search term
  is in use. I left the post types outside it, as a row of links rather than a select:
  choosing one is a single click, it takes one row, and the current filter is visible without
  opening anything. Collapsing them would surface the current filter only once you are
  already filtering, which is when you least need telling. Happy to move them inside if you
  would rather.

  They reuse the navigation component with a navigation--filters modifier, which already
  has the markup and the a[aria-current="true"] styling, so this adds a modifier and not a
  component. The colours are the --color-offset / --color-on-offset pair tag uses, and
  the current link swaps them, so the contrast is the same in both colour schemes.

  

  2. Heading and page title. Both done. On your worry about this not adapting to further
  filters, I think there is a rule that avoids the problem: the heading states what the
  controls do not already show. A post type is marked on its own link, so the heading need
  not repeat it in a sentence; a search term sits in a collapsed details, so it does get
  played back. Any filter added later follows the same rule without new sentences.

  613 posts
  Note · 613 posts
  Note · 613 posts matching “lunch”
  Note · No posts
  No posts matching “lunch”
  

  The document title is that text prefixed with the page heading, exactly as you described:
  Published posts: Note · 613 posts matching “lunch”. The empty states take the same shape,
  so the title still says which search found nothing — your No posts found matching ‘[QUERY]’.

  That needs three new keys rather than the twelve a sentence per combination would need,
  reusing the two empty-state keys already on the branch.

  The post type is a prefix rather than part of the sentence for a second reason: post type
  names are not translatable. Every post type plugin hardcodes an English singular name
  ("Note", "Article", "RSVP") and none ships a locale file, so “613 [TYPE] posts”
  renders in German as “613 Note Beiträge”. As a standalone label it reads as a label in any
  language.

  3. Localisation. Yes please to Localazy access — that would be very welcome. en.json
  carries the three new keys and I have not touched the other fourteen files.

  Two things follow from that, both worth knowing before you look at it in your own language.
  Until the keys are translated, a non-English admin UI shows the English counts next to
  translated controls — “Articles publiés: Note · 2 posts” in French. And noneMatching
  keeps its existing translations, which do not interpolate the search term, so those read as
  the unqualified sentence: true, just less specific than the English.

  There is also a one-line i18n commit on the branch, which is why. A key that exists only in
  en.json was rendered as the key itself in the other locales rather than as English —
  defaultLocale covers an unknown locale, not a missing key inside a known one — so a
  French page showed a literal posts.posts.count. retryInDefaultLocale makes it fall back
  to the English string, and an existing translation still wins. Every locale file is
  complete on main today, so it changes nothing visible; it just makes the window between a
  new key and a Localazy sync harmless. There is a test for it.

  It also saves me guessing plural categories, which I would get wrong: Polish needs
  one/few/many and Serbian one/few/other, while Chinese and Indonesian need only
  other. Localazy knows CLDR; I do not.

  4. The range suffix. I have left (showing posts 1 to 40) out and would suggest leaving
  it out, but it is your call. Paging is cursor-based, so a page does not know its own offset:
  working out “41 to 80” means a second count query on every page load, on top of the total,
  for something pagination already covers with next and previous. If you do want it, it is
  one extra countDocuments.

  Two things I noticed while in there.

  _count is not new — it is yours. You added it in f42a9869 (“include private count value
  in endpoint responses”) in June 2022, and 9bc6a357 removed it a year later when paging
  became cursor-based, but the consumers added in cb541d42 stayed. So endpoint-posts has
  read micropubResponse._count as undefined ever since, and endpoint-files still does.
  This branch restores the property and uses it, applying the same string-uid guard
  getCursor applies so it never reports posts that paging cannot reach. I have left
  endpoint-files alone, since it has no filter UI to show a count in.

  Separately, limit is not carried into the next and previous links, so paging from
  ?limit=1 falls back to the default page size. main builds those hrefs as ?after=<uid>
  with nothing else, so this is not from this branch and I have not touched it.

  Two follow-ups I would rather keep separate, both needing a decision rather than code:

  • Counts on the post type links. These count the collection, not the query — a count
    that moved with your search would be the wrong number for deciding where to look. That
    makes them a different thing from _count, and no Micropub extension defines a surface
    for them.
  • Status and sort controls. q=source has no parameter for either.

  Ouvrir sur GitHub →

  
  source