Skip to content

Conversation

@zanesq
Copy link
Collaborator

@zanesq zanesq commented Aug 22, 2025

Made the fallbacks for checking local storage more resilient. Also added a backup mechanism for navigation since electron can have issues with hash based routing on load.

  • added exponential backoff retries to avoid accessing local storage before its available
  • added direct call to react router navigation with fallback to hash routing to avoid protocol errors in electron

fixes #4255

@zanesq zanesq requested review from DOsinga and alexhancock August 22, 2025 20:06
break;

// Use React Router navigation if available, otherwise fallback to hash manipulation
if (navigateRef.current) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

When is it not available?

const configStr = JSON.stringify(windowConfig).replace(/'/g, "\\'");
mainWindow.webContents
.executeJavaScript(
`
Copy link
Collaborator

Choose a reason for hiding this comment

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

A bit outside the scope of this PR, but why do we need to manually call executeJavaScript on this block?

Could we not move it to some renderer side ts?

@zanesq
Copy link
Collaborator Author

zanesq commented Aug 25, 2025

@alexhancock I can see how this would be confusing so I added comments to both of these. Let me know if it makes sense or not.

zanesq added 2 commits August 25, 2025 10:07
* 'main' of github.com:block/goose:
  fix slow typing with long sessions (#4291)
  docs: improvements to release docs (#4317)
  blog: mcp-ui recap blog (#4146)
  added more logging for recipe creation failures (#4299)
  Remove a bit from pre-commit that husky says we should (#4286)
  feat: autovisualiser of structured data with mcp-ui (#4153)
  docs: Plan tutorial (#4309)
  Extensions Modal Improvements (#4293)
  docs: fixed cicd tutorial pipeline in docs (#4223)
  Read oltp config from config and env (#4292)

# Conflicts:
#	ui/desktop/src/App.tsx
Copy link
Collaborator

@DOsinga DOsinga left a comment

Choose a reason for hiding this comment

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

we should maybe discuss this some more, this does feel like we're trying to fix stuff on top of shaky stuff maybe?

onNavigateReady={(navigate) => {
navigateRef.current = navigate;
}}
/>
Copy link
Collaborator

Choose a reason for hiding this comment

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

you'll have to explain to me why we need this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Basically setView was being called before react router was ready during direct navigation or refresh so now it will capture it and use it once its ready. We prefer to use react router navigation anyway so it should improve things. That being said I can leave this part out for now and only do the local storage changes to see if that is enough to fix the refresh issue.

const injectionScript = localStorageInjectionScript('gooseConfig', configStr);
mainWindow.webContents.executeJavaScript(injectionScript).catch((error) => {
console.error('Failed to execute localStorage script:', error);
});
Copy link
Collaborator

Choose a reason for hiding this comment

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

why again do we want this to be injected into local storage? we seem to be loading this with:

  getConfig: () => {
    // Add fallback to localStorage if config from preload is empty or missing
    if (!config || Object.keys(config).length === 0) {
      try {
        if (window.localStorage) {
          const storedConfig = localStorage.getItem('gooseConfig');
          if (storedConfig) {
            return JSON.parse(storedConfig);
          }
        }
      } catch (e) {
        console.warn('Failed to parse stored config from localStorage:', e);
      }
    }
    return config;

couldn't we store it locally in the renderer and when it can't be found just do an ipc call back to the electron processs? or expose it using exposeInMainWorld that I just learned about?

Copy link
Collaborator Author

@zanesq zanesq Aug 25, 2025

Choose a reason for hiding this comment

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

Agreed this can probably be improved with some exposeInMainWorld logic but unfortunately would require more time so I think we should come back to that in a bigger refactor. IPC would require async calls that happen further down the chain and could cause race conditions. This is just a way to get it called as early as possible and have retries to fix the main error that localstorage isn't available to the browser yet when it tries to access it.

As for why we put config in local storage I'm guessing its so it can be loaded faster from multiple windows but it may be a legacy thing that we could come back to and remove also.

@zanesq
Copy link
Collaborator Author

zanesq commented Aug 26, 2025

Appreciate the feedback! Closing this in favor of a more targeted fix #4355

@zanesq zanesq closed this Aug 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reload Doesn't Work

4 participants