[PP-1] Create some front-end components to render filters defined by the source

Created on 27 August 2024, 4 months ago

Problem/Motivation

✨ Certain filters should only be shown if they are actually defined Needs work introduces a new PHP API for the source plugins to define which filters they will respect. The sources only define the filters as a data type ("boolean", "multiple choice", etc.), but have absolutely no input or opinion about how they are rendered.

Right now, the frontend does not use the source-defined filters for rendering, nor does it really interact with them, in any way beyond using them as indicators of whether the pre-existing hard-coded filters should be displayed.

The next step is to actually render the filters defined by the source, by creating new Svelte components which can render them cleanly.

Proposed resolution

There are currently two filter types definable by the backend - BooleanFilter and MultipleChoiceFilter. Let's create some corresponding front-end Svelte components (<BooleanFilter> and <MultipleChoiceFilter>) which can render these filters and handle user interaction, and then use those instead of the hard-coded filters we currently show.

This is another case where we don't need explicit test coverage, as long as all the tests in HEAD pass. There should be no visible difference, or interactive difference, between what's in HEAD and the new components. All we're changing is the way they internally operate.

✨ Feature request
Status

Postponed

Version

2.0

Component

Code

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @phenaproxima
  • Status changed to Active 4 months ago
  • Merge request !574#3470540: "Create some front end" → (Merged) created by kunal.sachdev
  • Pipeline finished with Failed
    3 months ago
    Total: 406s
    #279227
  • Pipeline finished with Success
    3 months ago
    Total: 434s
    #279233
  • Pipeline finished with Failed
    3 months ago
    Total: 1370s
    #280154
  • Pipeline finished with Failed
    3 months ago
    Total: 758s
    #284391
  • Pipeline finished with Failed
    3 months ago
    Total: 526s
    #285136
  • Pipeline finished with Failed
    3 months ago
    Total: 1723s
    #285312
  • Pipeline finished with Failed
    3 months ago
    Total: 1107s
    #286257
  • Pipeline finished with Failed
    3 months ago
    Total: 407s
    #290311
  • Pipeline finished with Failed
    3 months ago
    Total: 539s
    #291238
  • 🇺🇸United States phenaproxima Massachusetts

    I think this looks quite close to what I envisioned - great job!

    The only thing that I object to here is the changes to BooleanFilter. I think that passing a set of options to it misunderstands the nature of a boolean filter.

    A boolean filter really should only be a single checkbox, semantically speaking. I understand that Project Browser has shown them, previously, as option sets -- that's a strange decision, but it's one we could account for differently, rather than changing BooleanFilter to work like a set of options.

    So, I'm kicking this back for that, but once that's done, we can work on resolving the test failures.

  • Pipeline finished with Failed
    3 months ago
    Total: 1194s
    #293039
  • Pipeline finished with Failed
    3 months ago
    Total: 477s
    #293236
  • Pipeline finished with Failed
    3 months ago
    Total: 345s
    #293244
  • Pipeline finished with Failed
    3 months ago
    Total: 436s
    #293254
  • Pipeline finished with Failed
    3 months ago
    Total: 435s
    #293272
  • Pipeline finished with Failed
    3 months ago
    Total: 466s
    #294381
  • Pipeline finished with Failed
    3 months ago
    Total: 705s
    #294514
  • Pipeline finished with Failed
    3 months ago
    Total: 320s
    #296799
  • Pipeline finished with Failed
    3 months ago
    #297043
  • Pipeline finished with Failed
    3 months ago
    #297072
  • Pipeline finished with Failed
    3 months ago
    #303083
  • Pipeline finished with Failed
    3 months ago
    Total: 479s
    #303343
  • Pipeline finished with Failed
    2 months ago
    Total: 488s
    #304094
  • Pipeline finished with Failed
    2 months ago
    Total: 402s
    #304961
  • Pipeline finished with Failed
    2 months ago
    Total: 614s
    #305019
  • Pipeline finished with Failed
    2 months ago
    Total: 1013s
    #305048
  • Pipeline finished with Failed
    2 months ago
    Total: 433s
    #305063
  • Pipeline finished with Failed
    2 months ago
    Total: 411s
    #310192
  • Pipeline finished with Failed
    2 months ago
    Total: 1050s
    #310302
  • 🇮🇳India kunal.sachdev

    The current test failure is in tests/src/Nightwatch/Tests/keyboardTest.js in which there is a part where we are testing that when we are on the categories filter and we click tab then it shifts to next filter drop down i.e security coverage. This test is failing now because in this MR we are rendering the filters as it is which is defined from the backend and not hardcoding them. The previous hardcoding was done in a way such that the filters were displayed in the order :- categories -> security coverage -> maintenance status -> development status but now we accidentally in the backend have the filters defined in the order :- categories ->maintenance status -> security coverage -> development status. For now to fix the failure we can fix the order of the defined filters in backend but I think the major problem is that somewhere in the code we have hard coded the tab index for each filter which needs to be fixed (maybe in a new issue).

  • Pipeline finished with Success
    2 months ago
    Total: 346s
    #317031
  • Pipeline finished with Success
    2 months ago
    Total: 431s
    #317059
  • 🇺🇸United States phenaproxima Massachusetts

    Virtually no complaints here. Amazing work!

    I only would like to see a couple of follow-ups filed (one of which seems ambiguous), and using assertSame() instead of assertEquals() in most situations. Other than that, this just needs a little manual testing and then it's good to go.

  • Pipeline finished with Success
    about 2 months ago
    Total: 469s
    #323041
  • 🇺🇸United States phenaproxima Massachusetts

    This code looks good to me. I'm RTBCing it and sending it to @chrisfromredfin for manual testing and hopefully a merge.

  • Pipeline finished with Skipped
    about 2 months ago
    #324456
  • First commit to issue fork.
  • 🇺🇸United States chrisfromredfin Portland, Maine

    Manually tested and re-reviewed. This is a big leap forward to moving out of proof-of-concept land and into "this is a real thing" land.

    I would love to someday see a meta about revisiting all our tests and doing things like moving to assertSame(), but I may leave that for a core gate.

  • Status changed to Fixed about 1 month ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024