feat(query-bar): allow users to set the default sort to be recent first COMPASS-6706

[djechlin-mongodb]

Description

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Open Questions

Dependents

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[gribnoysup]

Preferencfes / settings part looks good! I think we might want to move the code that applies the default to the query-bar. There are also some compilation errors in CI that you'd need to resolve

[gribnoysup]

This changes the behavior only for CRUD, but query bar is also used in the schema tab, I think we might want to move this logic to query bar itself so that it consistently applies every time no matter where current query from query bar is accessed

[djechlin-mongodb]

It's debatable. I'd actually lean toward putting it in the "crud" layer not the "query bar" layer.

Firstly the product question -- if I understand correctly, the schema tab basically ignores sort and we should actually get rid of that field because it's not helping users at all. If sort were somehow used, I would say no don't use defaults -- for schema users, it's very important they transparently see the inputs to the validation, so silently joining in a default becomes un-helpful to them, whereas it's a non-misleading nice-to-have in document list.

From there, I actually would view this as a CRUD/document-list feature not a query bar feature. Users are basically complaining the docs are in the wrong order, they're not complaining that anything is wrong with their queries. In particular, the feature request is to not change recent queries or saved queries at all -- users are trying to not think about the sort being applied for them, they want the docs to just appear in the right order. So that suggests a document-list feature.

If you move it to query-bar you get a bit of complexity as we now have to manage the double concept of "what the user typed" and "what the user typed after defaults are applied." CRUD would then execute the latter. Recent/saved queries only care about user input; if you believe my above argument then schema only cares about user input; doc list cares about the defaults. To me it just looks like this is something doc list wants to do, and we shouldn't assume it readily generalizes to other uses or that we get any leverage out of moving it to query bar.

LMK what you think. If we do want it used in schema then yeah it needs to be more general. Can you think of any other reasons query bar or its other users would need to care about the defaults -- maybe logging or something gets affected, noting that we specifically don't want the sorts showing up in recent/favorites? Any other value to putting it in the more general location of query bar I'm missing? At this point it just looks a little lower complexity/less stateful concepts to manage to put it in CRUD.

[gribnoysup]

We already use maxTimeMS from preferences in query bar to validate user input and in other cases provide default substitutions from query bar defined constants when user input is empty when returning a parsed query, so I don't think it's that far off from query bar responsibilities. It is also true though that maxTimeMS itself while used for validation, is not returned as a default value so I agree that at the current moment we can go both ways about it. I have my preference, but I think your arguments are reasonable too 🙂

If you move it to query-bar you get a bit of complexity as we now have to manage the double concept of "what the user typed" and "what the user typed after defaults are applied."

I want to touch on this a bit because I think it's an important part of the state management story. I think there is no extra complexity involved here compared to running this logic elsewhere, just actual states (query bar user input, current preferences values, etc) and a derived state of a parsed query that takes multiple of those sources into account. So if it's only technical complexity that stops you from doing this, I don't think it should. But as I mentioned, your other points make sense, so feel free to resolve this if it still makes more sense to you to keep it in CRUD only.

[djechlin-mongodb]

Chatted offline a bit -- confirmed schema tab actually ignores the sort part of the query. From here I think that tilts the argument to the CRUD component because we know the other possible user, schema tab, will actually ignore this data if we send it (and Sergey signed off on my reasoning).

[gribnoysup]

I don't think undefined is ever possible here and you're getting a compilation error that's related to that: leafygreen Select tries to do some infers to smartly detect uncontrolled component and shows some optional props as required (you can see those errors in CI):

@mongodb-js/compass-settings: src/components/settings/settings-list.tsx(185,8): error TS2322: Type '{ children: Element[]; className: string; allowDeselect: false; "aria-labelledby": string; id: PreferenceName; name: PreferenceName; "data-testid": PreferenceName; value: string | undefined; onChange: (value: string) => void; disabled: boolean; }' is not assignable to type 'IntrinsicAttributes & ((Omit<BaseSelectProps & Omit<LabelProp, "aria-label" | "aria-labelledby" | "label"> & Required<...> & Partial<...> & { ...; } & { ...; }, "ref"> | ... 7 more ... | Omit<...>) & RefAttributes<...>)'.
@mongodb-js/compass-settings:   Type '{ children: Element[]; className: string; allowDeselect: false; "aria-labelledby": string; id: PreferenceName; name: PreferenceName; "data-testid": PreferenceName; value: string | undefined; onChange: (value: string) => void; disabled: boolean; }' is missing the following properties from type 'Omit<BaseSelectProps & Omit<LabelProp, "aria-label" | "aria-labelledby" | "label"> & Required<Pick<LabelProp, "label">> & Partial<...> & { ...; } & { ...; }, "ref">': label, readOnly

Generally speaking controlled react component should always get the value, so this error is legit, it just shows itself in a weird way at the moment. If somehow we expect the value here to not always be provided it needs to be handled when component is rendered

[djechlin-mongodb]

fixed.

[gribnoysup]

This test fails for me locally (and in CI):

1 failing

  1) GeneralSettings
       changes defaultSortOrder value when selecting an option:
     TestingLibraryElementError: Value "_id: 1 (in ascending order by creation)" not found in options

I'm pretty sure selectOptions works only with browser select and you'll have to "manually" click around things to select something in a leafygreen component. Does it work for you?

[lerouxb]

The sort order affects the explain plan. Should we send it through to Explain?

[djechlin-mongodb]

The sort order affects the explain plan. Should we send it through to Explain?

Discussed in slack some, but basically no, at best it's a small piece of polish but we're already accepting some risk by exposing the _id option which doesn' apply 100% to every collection.