Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

fix(svelte): respect default pattern type in toggles#63795

Merged
jtibshirani merged 3 commits into
mainfrom
jtibs/patterntype
Jul 12, 2024
Merged

fix(svelte): respect default pattern type in toggles#63795
jtibshirani merged 3 commits into
mainfrom
jtibs/patterntype

Conversation

@jtibshirani

@jtibshirani jtibshirani commented Jul 11, 2024

Copy link
Copy Markdown
Contributor

In Sveltekit, we respect the setting search.defaultPatternType for the initial search, but if you set then unset the regexp toggle, it always reverts to keyword. Now we revert back to the default when a toggle is unset.

This is important because some customers have disabled keyword search, and for 5.5 we've directed them to use search.defaultPatternType: standard.

Test plan

Manually tested search + toggles with following config:

  • No settings
  • search.defaultPatternType: standard, keyword, and regexp

@cla-bot cla-bot Bot added the cla-signed label Jul 11, 2024
@jtibshirani jtibshirani requested review from a team July 11, 2024 21:06
@github-actions github-actions Bot added team/product-platform team/search-platform Issues owned by the search platform team labels Jul 11, 2024
// When a toggle is unset, we revert back to the default pattern type. However, if the default pattern type
// is regexp, we should revert to keyword instead (otherwise it's not possible to disable the toggle).
function getUnselectedPatternType(): SearchPatternType {
const defaultPatternType = ($settings?.['search.defaultPatternType'] as SearchPatternType) ?? SearchPatternType.keyword

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is my first SvelteKit PR, so not really sure what I'm doing :) And also this felt too easy.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad you found it easy 😃

It doesn't make a big difference here since this is not a hot path, but instead of defining and calling a function every time the toggle is clicked, you could instead define a reactive/derived variable. In this case the variable would only update when $settings changes. For example:

$: unselectedPatternType = getUnselectedPatternType(
    $settings?.['search.defaultPatternType'] as (SearchPatternType|undefined)
)

function getUnselectedPatternType(defaultPatternType = SearchPatternType.keyword): SearchPatternType {
    return defaultPatternType === SearchPatternType.regexp 
        ? SearchPatternType.keyword 
        : defaultPatternType
}


function setOrUnsetPatternType(patternType: SearchPatternType): void {
        queryState.setPatternType(currentPatternType =>
            currentPatternType === patternType 
                ? unselectedPatternType
                : patternType
        )
    }

But again, that's not necessary here IMO, and the function solution might actually be easier to understand.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know about derived variables! I agree that the current approach is most straightforward though and shouldn't hurt performance.

@fkling fkling left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to test this you could add an integration test here and check whether the URL contains the expected pattern type after submitting the query.

// When a toggle is unset, we revert back to the default pattern type. However, if the default pattern type
// is regexp, we should revert to keyword instead (otherwise it's not possible to disable the toggle).
function getUnselectedPatternType(): SearchPatternType {
const defaultPatternType = ($settings?.['search.defaultPatternType'] as SearchPatternType) ?? SearchPatternType.keyword

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad you found it easy 😃

It doesn't make a big difference here since this is not a hot path, but instead of defining and calling a function every time the toggle is clicked, you could instead define a reactive/derived variable. In this case the variable would only update when $settings changes. For example:

$: unselectedPatternType = getUnselectedPatternType(
    $settings?.['search.defaultPatternType'] as (SearchPatternType|undefined)
)

function getUnselectedPatternType(defaultPatternType = SearchPatternType.keyword): SearchPatternType {
    return defaultPatternType === SearchPatternType.regexp 
        ? SearchPatternType.keyword 
        : defaultPatternType
}


function setOrUnsetPatternType(patternType: SearchPatternType): void {
        queryState.setPatternType(currentPatternType =>
            currentPatternType === patternType 
                ? unselectedPatternType
                : patternType
        )
    }

But again, that's not necessary here IMO, and the function solution might actually be easier to understand.

@jtibshirani

Copy link
Copy Markdown
Contributor Author

If you want to test this you could add an integration test here and check whether the URL contains the expected pattern type after submitting the query.

I gave this a try and added an integration test. It highlighted a difference between the React and Sveltekit versions: in the experimental app, just hitting the toggle has no effect on the URL (and does not resubmit the search).

@jtibshirani jtibshirani merged commit aaee245 into main Jul 12, 2024
@jtibshirani jtibshirani deleted the jtibs/patterntype branch July 12, 2024 21:22
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla-signed team/product-platform team/search-platform Issues owned by the search platform team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants