feat: Enhance Schema Error Visualization with New Icons

[Kevin101Zhang]

Optimized Editor Lifecycle methods and removed the 'janky' Alert that would insert itself between the developer tools and Editor component in favor of a small icon that is in the fileswitcher.

[Kevin101Zhang]

Schema now no longer throws an Alert component in between the Editor and the DevelopMenu cause a 'janky experience'. Instead schema not showcases errors based on the file tab itself through small icons. Similarly the debugMode no longer has a Alert component but is now directs the user to open their console through a onHover tooltip. Indexer.js has a similar funtionality but is locked through a feature flag as it is dependent on Monaco having types of node, near-lake first before we can properly prompt the user there is an error in the Indexer.

[morgsmccauley]

There's a lot going on in this PR, could you please split it in to smaller ones, one for each of the fix/feat added in the title?

Smaller PRs are preferable because they:

1. Make the review process easier, smaller diff to review.
2. Reduce the likelihood of introducing bugs, as changes are more focused and easier to understand.
3. Improve the ability to identify the source of issues, as smaller, isolated changes make debugging more straightforward.

[Kevin101Zhang]

Small change in validators.ts, no functionality change.
Purpose is to make the error handling more consistent with others functions in the same file.

[Kevin101Zhang]

small change in index.js, no functionality change.
Purpose is to make component more readable

[Kevin101Zhang]

@morgsmccauley I removed the "fix: multiple rerenders" to a different PR.
The Editor optimizations heavily revolve around the the introduction of the new feature of icons in fileSwitcher to showcase error messages. All the other files here are tightly coupled are children component of Editor (fileSwitcher, developertools). There are the larger number of file changes due to each component having a view and viewContainer.

The exception are the 2 small more readability refactors in the files commented above that are trivial.

[morgsmccauley]

Looks good, just a few minor comments

[morgsmccauley]

should we just remove this?

[Kevin101Zhang]

I want to add this the second I get monaco Types inserted. I attempted it with a little time but I was having trouble. Will retackle it in the next ticket so I would like to keep it

[morgsmccauley]

I don't understand, there is a functional change here. Previously, if the error was not an Error it would be re-thrown. Are you sure we don't need that functionality?

[Kevin101Zhang]

Yes! Im fairly certain the error will be handled properly.

const debouncedValidateCode = useDebouncedCallback((_code: string) => {
  const { error } = validateJSCode(_code);
  console.log(error);
  indexerErrorHandler(error);
}, 500);

export function validateJSCode(code: string): { data: string | null; error: Error | null } {
  if (!code) return { data: null, error: null };

  try {
    const formattedCode = formatIndexingCode(code);
    return { data: formattedCode, error: null };
  } catch (error: any) {
    return {
      data: code,
      error: error.message,
    };
  }
}

export const formatIndexingCode = (code) => {
  try {
    return prettier.format(code, {
      parser: 'babel',
      plugins: [parserBabel],
    });
  } catch (error) {
    throw new Error(`Failed to format code: ${error.message}`);
  }
};

validateJSCode function will attempt to format the code. If an error occurs during formatting, it catches the error and returns it. formatIndexingCode function tries to format the code using Prettier. If Prettier fails, it throws an error with a clear message. This error will be caught by the validateJSCode function.