chore: refactor /database parallel rendering

[duyet]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
clickhouse-monitoring	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 27, 2024 11:17am

[sourcery-ai]

Hey @duyet - I've reviewed your changes and they look great!

Here's what I looked at during the review

• 🟡 General issues: 5 issues found
• 🟡 Security: 1 issue found
• 🟢 Testing: all looks good
• 🟡 Complexity: 2 issues found

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[sourcery-ai]

question: Empty component

The Page component currently returns an empty fragment. Is this intentional? If this is a placeholder, consider adding a comment to clarify its purpose.

[sourcery-ai]

question (bug_risk): Removed error handling

The error handling for fetching databases has been removed. How will errors be handled in the new implementation?

[sourcery-ai]

suggestion (performance): Query duration logging

Logging the duration of queries is a good addition. Ensure that this does not introduce significant overhead.

Suggested change

	const query_id = resultSet.query_id
	const data = await resultSet.json<T>()
	const end = new Date()
	const duration = (end.getTime() - start.getTime()) / 1000
	const start = performance.now()
	const client = getClient({ web: false })
	const resultSet = await client.query({
	query: QUERY_COMMENT + query,
	const query_id = resultSet.query_id
	const data = await resultSet.json<T>()
	const end = performance.now()
	const duration = (end - start) / 1000

[sourcery-ai]

🚨 suggestion (security): Optional query prop

The query prop is a useful addition for debugging. Ensure that sensitive information is not exposed in production environments.

[sourcery-ai]

suggestion (bug_risk): Error handling for engineType

Consider adding error handling for the engineType function call to handle cases where the fetch might fail.

[sourcery-ai]

suggestion (bug_risk): Error handling for fetchDataWithCache

Consider adding error handling for the fetchDataWithCache call to handle potential network or data issues.

[sourcery-ai]

issue (complexity): Consider refactoring to handle both message and query in a more unified way.

The new code introduces increased complexity due to additional conditional logic and repetition. To simplify, consider refactoring to handle both message and query in a more unified way. Here's a possible refactor:

import React from 'react';
import { Alert, AlertDescription, AlertTitle } from '@/components/ui/alert';
import { Button } from '@/components/ui/button';

interface ErrorAlertProps {
  title?: string;
  message?: string | React.ReactNode | React.ReactNode[];
  query?: string;
  reset?: () => void;
  className?: string;
}

export function ErrorAlert({
  title = 'Something went wrong!',
  message = 'Checking console for more details.',
  query,
  reset,
  className,
}: ErrorAlertProps) {
  const renderContent = (content: string | React.ReactNode | React.ReactNode[]) => (
    <div className="mb-5 font-light">
      <code className="overflow-auto hover:text-clip">{content}</code>
    </div>
  );

  return (
    <Alert className={className}>
      <AlertTitle className="text-lg">{title}</AlertTitle>
      <AlertDescription>
        {renderContent(message)}
        {query && renderContent(query)}
        {reset && (
          <Button
            variant="outline"
            onClick={() => reset()}
          >
            Try again
          </Button>
        )}
      </AlertDescription>
    </Alert>
  );
}

This refactor reduces repetition, improves readability, and maintains the same functionality.

[sourcery-ai]

issue (complexity): Consider simplifying the type checking conditions for errorFallback.

The new code introduces some logical errors and reduces readability. Specifically, the type checking conditions for errorFallback are incorrect, leading to potential bugs. The conditions for checking if errorFallback is a string or number are not properly grouped, causing incorrect logic. Additionally, the code is harder to read due to these fragmented conditions. Here is a revised version that maintains simplicity and correctness:

import { LoadingIcon } from '@/components/loading-icon';

function defaultFallbackRender({ error, resetErrorBoundary }: FallbackProps) {
  // Call resetErrorBoundary() to reset the error boundary and retry the render.
  return <ErrorAlert message={error.message} reset={resetErrorBoundary} />;
}

export type ServerComponentLazyProps = {
  children: ReactNode;
  errorFallback?: null | string | number | ((props: FallbackProps) => ReactNode);
};

export function ServerComponentLazy({
  children,
  errorFallback,
}: ServerComponentLazyProps) {
  let fallbackRender: (props: FallbackProps) => ReactNode;

  if (errorFallback === null) {
    fallbackRender = () => null;
  } else if (typeof errorFallback === 'string' || typeof errorFallback === 'number') {
    fallbackRender = () => <span>{errorFallback}</span>;
  } else if (typeof errorFallback === 'function') {
    fallbackRender = errorFallback;
  } else {
    fallbackRender = defaultFallbackRender;
  }

  return (
    <ErrorBoundary fallbackRender={fallbackRender}>
      <Suspense fallback={<LoadingIcon />}>{children}</Suspense>
    </ErrorBoundary>
  );
}

This version corrects the type checking and improves readability, making the code easier to maintain.