add frontend for search

[nexxeln]

No description provided.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	supermemory-app	0f15ae1	Oct 23 2025, 05:09 AM

[nexxeln]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add user search #514
• add frontend for search #513 👈 (View in Graphite)
• add server api #512
• main

---

How to use the Graphite Merge Queue

Add the label Main to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

Code Review: Add Frontend for Search

Thank you for adding the search frontend! Here's my review of the changes:

✅ Strengths

• Clean React component structure with proper state management
• Correctly uses encodeURIComponent for query parameter encoding
• Proper error handling with try-catch pattern
• Loading states are handled appropriately

🔴 Critical Issues

1. Performance Issue - Fetch on Every Keystroke (graphite-demo/frontend.jsx:9-26)

The current implementation triggers a fetch request on every single keystroke since searchQuery is in the dependency array. This will cause:

• Excessive API calls
• Poor UX with flickering results
• Potential race conditions if responses arrive out of order
• Server overload with rapid typing

Recommendation: Implement debouncing to delay the search until the user stops typing:

import React, { useEffect, useState } from 'react';

const TaskSearch = () => {
  const [tasks, setTasks] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [searchQuery, setSearchQuery] = useState('');

  useEffect(() => {
    // Don't fetch on mount with empty query
    if (!searchQuery.trim()) {
      setTasks([]);
      setLoading(false);
      return;
    }

    setLoading(true);
    setError(null);
    
    // Debounce: wait 300ms after user stops typing
    const timeoutId = setTimeout(() => {
      fetch(`/search?query=${encodeURIComponent(searchQuery)}`)
        .then(response => {
          if (!response.ok) {
            throw new Error('Network response was not ok');
          }
          return response.json();
        })
        .then(data => {
          setTasks(data);
          setLoading(false);
        })
        .catch(error => {
          setError(error.message);
          setLoading(false);
        });
    }, 300);

    return () => clearTimeout(timeoutId);
  }, [searchQuery]);

  // Rest of component...
};

2. Initial Fetch on Mount (graphite-demo/frontend.jsx:9-26)

The component immediately fetches with an empty search query on mount, which may not be the desired behavior. Consider:

• Only fetching when there's an actual search query
• Or showing all tasks initially if that's the intended UX

⚠️ Other Issues

3. Missing Abort Controller for Race Conditions

If a user types quickly, older requests might resolve after newer ones, showing stale results. Consider using AbortController:

useEffect(() => {
  const abortController = new AbortController();
  const timeoutId = setTimeout(() => {
    fetch(`/search?query=${encodeURIComponent(searchQuery)}`, {
      signal: abortController.signal
    })
    // ... rest of fetch logic
  }, 300);

  return () => {
    clearTimeout(timeoutId);
    abortController.abort();
  };
}, [searchQuery]);

4. Missing Key Prop Validation (graphite-demo/frontend.jsx:46-50)

The code assumes task.id exists. If the API response changes or returns tasks without IDs, React will throw warnings. Add validation:

{tasks.map((task, index) => (
  <li key={task.id || index}>
    <p>{task.description || 'No description'}</p>
  </li>
))}

5. Generic Error Message (graphite-demo/frontend.jsx:32-34)

"Network response was not ok" doesn't give users actionable information. Consider:

throw new Error(`Search failed: ${response.status} ${response.statusText}`);

6. Missing Loading Indicator During Search

When typing, users should see a loading indicator. The current implementation shows "Loading..." only initially. Consider showing a spinner or "Searching..." text in the UI.

📋 Best Practices & Suggestions

7. Consider Using React Query or SWR

For data fetching in React, libraries like @tanstack/react-query (which is already in your monorepo dependencies per CLAUDE.md) would handle:

• Caching
• Debouncing
• Race conditions
• Error retry logic
• Loading states

8. Accessibility Issues

• Add aria-label to the search input
• Add aria-live region for screen readers to announce results
• Add loading aria attributes

<input
  type="text"
  placeholder="Search tasks..."
  value={searchQuery}
  onChange={(e) => setSearchQuery(e.target.value)}
  aria-label="Search tasks"
  aria-describedby="search-results"
/>

9. Empty State Handling

No handling for when tasks is empty after a search. Consider showing "No results found" message.

10. File Location & Integration

This file is in graphite-demo/ which appears to be a demo/example directory. If this is intended for production use, it should be in apps/web/ following the monorepo structure defined in CLAUDE.md.

🧪 Test Coverage

No tests were added. Consider adding:

• Unit tests for the component
• Tests for debouncing behavior
• Tests for error states
• Tests for empty states

🔒 Security

• ✅ Properly using encodeURIComponent for XSS prevention
• ⚠️ No input sanitization length limits (consider max query length)
• ⚠️ No rate limiting on the client side

Summary

The component has a solid foundation but requires performance optimization before merging. The fetch-on-every-keystroke issue is critical and should be addressed with debouncing. The other suggestions would improve robustness and user experience.

Recommendation: Request changes - please implement debouncing before merging.

[claude]

PR Review: Add Frontend for Search

Overview

This PR adds a React frontend component to complement the search API from PR #512. Overall structure is good, but there are several issues that need to be addressed before merging.

---

🐛 Critical Issues

1. Infinite Loop on Initial Load (graphite-demo/frontend.jsx:10)

The useEffect runs on mount with an empty searchQuery, triggering an API call immediately. This creates a poor UX and unnecessary server load.

Issue:

useEffect(() => {
  setLoading(true);
  fetch(`/search?query=${encodeURIComponent(searchQuery)}`)
  // ...
}, [searchQuery]);

Recommendation:
Only fetch when there's actual search input, or debounce the search:

useEffect(() => {
  if (!searchQuery) {
    setTasks([]);
    setLoading(false);
    return;
  }
  
  const timeoutId = setTimeout(() => {
    setLoading(true);
    fetch(`/search?query=${encodeURIComponent(searchQuery)}`)
      // ... rest of fetch logic
  }, 300); // 300ms debounce
  
  return () => clearTimeout(timeoutId);
}, [searchQuery]);

2. Missing Key Prop Uniqueness Guarantee (graphite-demo/frontend.jsx:46)

Using task.id as a key assumes all task IDs are unique, but there's no TypeScript/PropTypes validation.

---

⚠️ Major Issues

3. No Error Handling for Empty Results (graphite-demo/frontend.jsx:44)

When tasks is empty (no search results), the UI shows nothing, leaving users confused.

Recommendation:

{tasks.length === 0 ? (
  <li>No tasks found matching "{searchQuery}"</li>
) : (
  tasks.map(task => (
    <li key={task.id}>
      <p>{task.description}</p>
    </li>
  ))
)}

4. Performance: Fetch on Every Keystroke (graphite-demo/frontend.jsx:10)

As mentioned in issue #1, fetching on every character typed creates unnecessary API calls.

5. Loading State During Search Updates (graphite-demo/frontend.jsx:27-29)

The loading indicator replaces the entire UI, including the search input, making it impossible to modify the search while loading.

Recommendation:

<div>
  <h2>Task Search</h2>
  <input
    type="text"
    placeholder="Search tasks..."
    value={searchQuery}
    onChange={(e) => setSearchQuery(e.target.value)}
  />
  {loading && <div>Loading...</div>}
  {error && <div>Error: {error}</div>}
  {!loading && !error && (
    <ul>
      {/* tasks list */}
    </ul>
  )}
</div>

---

💡 Minor Issues & Improvements

6. Accessibility

• Missing <label> for the search input (graphite-demo/frontend.jsx:38-43)
• No ARIA attributes for screen readers
• Consider adding aria-live region for search results

Recommendation:

<label htmlFor="task-search">
  Search tasks:
  <input
    id="task-search"
    type="text"
    placeholder="Search tasks..."
    value={searchQuery}
    onChange={(e) => setSearchQuery(e.target.value)}
    aria-label="Search tasks"
  />
</label>
<ul aria-live="polite" aria-atomic="true">
  {/* tasks */}
</ul>

7. Network Error Handling (graphite-demo/frontend.jsx:12-14)

Only catches network errors, not API-level errors (e.g., 500 responses with valid JSON).

8. Code Style Consistency

• Missing semicolon on line 56 (though this is a minor style issue)
• Consider using the repository's Biome formatter: bun run format-lint

9. Component Organization

This appears to be a demo component in graphite-demo/. Consider:

• Is this intended to be integrated into apps/web/?
• If so, it should follow the existing Next.js/TypeScript patterns
• Should use @tanstack/react-query for data fetching (as mentioned in CLAUDE.md)

---

🧪 Testing

Missing:

• No tests for the component
• No tests for edge cases (empty search, special characters, API errors)

Recommendation:
Add tests covering:

• Initial render state
• Search input changes
• Loading states
• Error states
• Empty results
• Successful search results

---

🔒 Security

✅ Good: Using encodeURIComponent for query parameter sanitization

---

📝 Summary

Must Fix Before Merge:

1. Implement debouncing to prevent excessive API calls
2. Fix loading state to not block the search input
3. Add empty state handling

Should Fix:
4. Improve accessibility with labels and ARIA attributes
5. Consider using the repository's standard data fetching patterns (@tanstack/react-query)
6. Run bun run format-lint to ensure code style consistency

Nice to Have:
7. Add tests
8. Clarify integration path (demo vs. production component)

---

📊 Overall Assessment

The component provides basic search functionality but needs refinement for production use. The UX issues (loading states, missing debounce) are the highest priority. Once addressed, this will be a solid foundation for the search feature.

Status: Changes requested ⚠️

[claude]

Pull Request Review - Frontend Search Component

Thank you for the contribution! Here is my detailed review:

Code Quality - Positive Aspects

• Clean component structure with proper state management
• Good use of React hooks (useState, useEffect)
• Proper error handling and loading states
• URL encoding for search queries

Areas for Improvement

1. Debouncing the search
Currently, the search fires on every keystroke, causing excessive API calls. Implement debouncing (300-500ms) to reduce unnecessary requests.

2. Initial empty search
The useEffect runs on mount with an empty searchQuery, triggering an unnecessary API call. Add a guard to check if searchQuery is empty before fetching.

3. Missing cleanup
The useEffect should handle component unmounting to avoid memory leaks. Use AbortController to cancel in-flight requests when the component unmounts or searchQuery changes.

Potential Bugs

1. Missing key uniqueness - If tasks do not have unique IDs, React will warn about duplicate keys. Consider using array index as a fallback.

2. Empty state handling - No handling for when tasks array is empty but search completed successfully. Add a message for empty results.

3. API endpoint mismatch - The endpoint /search should likely use the API route structure defined in CLAUDE.md (/v3/search). Verify this aligns with your backend.

Performance Considerations

1. Every keystroke triggers a fetch - implement debouncing
2. Consider using React Query - per CLAUDE.md, the web app uses @tanstack/react-query for data fetching, which provides caching and better state management

Security Concerns

Ensure the /search endpoint has proper authentication using Better Auth or API key authentication as per project standards.

Code Style & Repository Standards

1. File location - This file is in graphite-demo/ which appears to be a demo directory. If meant for production, it should be in apps/web/

2. Linting - Run 'bun run format-lint' to ensure this follows Biome configuration

3. TypeScript - The repository uses TypeScript throughout. Convert this to .tsx with proper type interfaces

Test Coverage

Missing: unit tests, error state tests, loading state tests, and integration tests with the search API.

Summary Recommendations

1. Add debouncing for search input
2. Convert to TypeScript with proper interfaces
3. Use React Query for data fetching
4. Add abort controller for cleanup
5. Add empty state handling
6. Move to proper app directory if not a demo
7. Add unit tests
8. Verify API endpoint matches backend routes

Overall, this is a good foundation but needs refinement for production use. Main concerns are performance optimization and alignment with project standards.

---

Review generated by Claude Code