fix(useToastHook): don't re-render text field on focus

[kishore03109]

Problem

We have a bug in production, see video here:

Screen.Recording.2023-07-13.at.12.03.25.PM.mov

This is not because of design system, I was able to replicate this even with chakra ui's toast. This seems to suggest the bug lies in how we are using this hook. video here:

Screen.Recording.2023-07-13.at.12.17.52.PM.mov

Solution

I think I know the cause for this, please feel free to correct me on this ya.

1. This does not happen at all the places of the code base.
   eg.

Screen.Recording.2023-08-03.at.12.24.35.PM.mov

2. There exists a useEffect in Settings.tsx that states

  // Reset cache on success
  useEffect(() => {
    if (isSuccess) {
      // Update to the new form state
      initialSettings.current = getValues()
      reset(settings)
    }
  }, [isSuccess, getValues, reset, settings])

  useEffect(() => {
    if (isSuccess) {
      successToast({
        id: "update-settings-success",
        title: "Success!",
        description: "Successfully updated settings!",
      })
    }
  }, [isSuccess, successToast])

I think there are unintended side effects here as the useUpdateSettings hook gives us, which then leads to the model being opened again. This bug is also so far observable when using in the settings page, which this PR solely attempts to solve.

I am ok to revert this if this should not be the best practice to do this, but I feel this should still go in to at least fix the bug in prod first.

Tests

https://github.com/isomerpages/isomercms-frontend/assets/42832651/5a973b89-473f-4757-83eb-ebf2e5b9fdfa
Should be similar to what is shown in the video above.

• open up settings page
• change anything in the site desc and click save
• wait for modal to pop out and close
• change anything in the text field
• assert that modal does not pop out again

[seaerchin]

successToast isnt' the hook - useSuccessToast is, and that's the one htat calls useXxxToast under the hood. this is called at top level so it should be ok? i can pair with you on this

[seaerchin]

hello, can we close this if it's not being worked on ah? i can take this up on fri

[seaerchin]

i'm ok with this for now but i think the root cause is how our errorToast/successToast is defined (which we found out).

could you file a ticket for that?

[seaerchin]

would be good if we shifted all these to the hook and mark as optional but is a good to have bah...

[kishore03109]

oof merge liao :/ + I abit dont get this what do you mean by shift to hook ah?

[kishore03109]

@seaerchin Hmm how do we feel about prioritising this such that we file a ticket only if there is another bug?