-
Notifications
You must be signed in to change notification settings - Fork 245
feat(query-bar): allow users to set the default sort to be recent first COMPASS-6706 #6663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 21 commits
f3174bc
1d13dbd
987e78d
59e0b25
b4a3945
7a56074
b2d9240
af1f596
879cca9
82207d6
650a774
4e4dd30
72f0697
ddcab6f
60668d2
b7d6a8c
0489bcc
df8dc6c
c1ed3d9
d22bea9
db27b01
7114687
ebbfca0
69daf52
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -55,6 +55,16 @@ describe('GeneralSettings', function () { | |
| }); | ||
| }); | ||
|
|
||
| it('renders defaultSortOrder', function () { | ||
| expect(within(container).getByTestId('defaultSortOrder')).to.exist; | ||
| }); | ||
|
|
||
| it('changes defaultSortOrder value when selecting an option', function () { | ||
| const select = within(container).getByTestId('defaultSortOrder'); | ||
| userEvent.selectOptions(select, '_id: 1 (in ascending order by creation)'); | ||
|
||
| expect(getSettings()).to.have.property('defaultSortOrder', '{ _id: 1 }'); | ||
| }); | ||
|
|
||
| ['maxTimeMS'].forEach((option) => { | ||
| it(`renders ${option}`, function () { | ||
| expect(within(container).getByTestId(option)).to.exist; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,6 +4,7 @@ import { | |
| getSettingDescription, | ||
| featureFlags, | ||
| } from 'compass-preferences-model/provider'; | ||
| import { SORT_ORDER_VALUES } from 'compass-preferences-model/provider'; | ||
| import { settingStateLabels } from './state-labels'; | ||
| import { | ||
| Checkbox, | ||
|
|
@@ -12,6 +13,8 @@ import { | |
| css, | ||
| spacing, | ||
| TextInput, | ||
| Select, | ||
| Option, | ||
| FormFieldContainer, | ||
| Badge, | ||
| } from '@mongodb-js/compass-components'; | ||
|
|
@@ -157,6 +160,55 @@ function NumericSetting<PreferenceName extends NumericPreferences>({ | |
| ); | ||
| } | ||
|
|
||
| function DefaultSortOrderSetting<PreferenceName extends 'defaultSortOrder'>({ | ||
| name, | ||
| onChange, | ||
| value, | ||
| disabled, | ||
| }: { | ||
| name: PreferenceName; | ||
| onChange: HandleChange<PreferenceName>; | ||
| value: string | undefined; | ||
|
||
| disabled: boolean; | ||
| }) { | ||
| const optionDescriptions = getSettingDescription(name).description.options; | ||
| const onChangeCallback = useCallback( | ||
| (value: string) => { | ||
| onChange(name, value as UserConfigurablePreferences[PreferenceName]); | ||
| }, | ||
| [name, onChange] | ||
| ); | ||
|
|
||
| return ( | ||
| <> | ||
| <SettingLabel name={name} /> | ||
| <Select | ||
| className={inputStyles} | ||
| allowDeselect={false} | ||
| aria-labelledby={`${name}-label`} | ||
| id={name} | ||
| name={name} | ||
| data-testid={name} | ||
| value={value} | ||
| onChange={onChangeCallback} | ||
| disabled={disabled} | ||
| > | ||
| {SORT_ORDER_VALUES.map((option) => ( | ||
| <Option | ||
| key={option} | ||
| value={option} | ||
| description={ | ||
| optionDescriptions && optionDescriptions[option].description | ||
| } | ||
| > | ||
| {optionDescriptions && optionDescriptions[option].label} | ||
| </Option> | ||
| ))} | ||
| </Select> | ||
| </> | ||
| ); | ||
| } | ||
|
|
||
| function StringSetting<PreferenceName extends StringPreferences>({ | ||
| name, | ||
| onChange, | ||
|
|
@@ -263,9 +315,16 @@ function SettingsInput({ | |
| disabled={!!disabled} | ||
| /> | ||
| ); | ||
| } | ||
|
|
||
| if (type === 'number') { | ||
| } else if (type === 'string' && name === 'defaultSortOrder') { | ||
| input = ( | ||
| <DefaultSortOrderSetting | ||
| name={name} | ||
| onChange={onChange} | ||
| value={value as string} | ||
| disabled={!!disabled} | ||
| /> | ||
| ); | ||
| } else if (type === 'number') { | ||
| input = ( | ||
| <NumericSetting | ||
| name={name} | ||
|
|
@@ -275,9 +334,7 @@ function SettingsInput({ | |
| disabled={!!disabled} | ||
| /> | ||
| ); | ||
| } | ||
|
|
||
| if (type === 'string') { | ||
| } else if (type === 'string') { | ||
| input = ( | ||
| <StringSetting | ||
| name={name} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
sortand 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🙂
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).