Open Bug 1799805 Opened 1 year ago

Enhance the "query" endpoint faceting mechanism to support converting/flattening client-side facets to query syntax processed on the server

Categories

(Webtools :: Searchfox, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: asuth, Unassigned)

References

(Depends on 1 open bug)

Details

Once the client-side faceting mechanism in bug 1799802 is operational, it makes sense to support converting/flattening any faceting decisions made on the client into query syntax that's applied on the server. Query URLs with faceting applied locally are basically a "show your work" approach, but in many cases, people won't want to share their work, but instead share the results. Arguably the refinement in the results case should take the form of moving from "fulltext that I faceted down" to "direct link to a query on the identifier/file/symbol in question", but it is probably important to establish the dual between server-side filtering and client-side filtering early on.

Note that the simplest thing we could do is just only ever process things on the server, but my understanding of searchfox usage is that people do tend to search and then scan / ctrl-f from there. I don't know that we'd see a lot of adoption for a faceting mechanism where every click has to round-trip to the server and potentially results in a bunch of weird jank. In general the goal is to keep searchfox latencies low and the JS load low enough so that such an experience might be surprisingly usable, but this is a case where having browser developers as a user-base who are aware of when something they might do could trigger massive latency is likely to impact usage.

Also note that there are somethings like diagrams where my current plan is indeed to only process things on the server, at least initially, because loading up a WASM graphviz on the client is very heavy-weight and the intent in the diagrams is also that most changes are actually going to be doing interesting traversal things. However, for that, maybe we'll find that we are able to have a 2-stage approach with that where we can perhaps just turn some things off in the graph on the client-side since it's SVG, deferring updates until the user flushes their changes or something.

You need to log in before you can comment on or make changes to this bug.