Add GitHub Gist sync for cross-browser/machine data persistence

[Copilot]

Adds the ability to sync UUID UI history and favorites to GitHub Gist, enabling data restoration after browser resets and cross-device access without a custom backend.

Changes

• src/gist-sync.js - Gist API service handling create/update/read operations, token management, and data serialization
• src/gist-sync-modal.js - Modal UI for token entry, sync/restore actions, and connection status
• src/nav.js - Sync button in nav bar with connected state indicator (green when authenticated)
• src/app.js - Added restoreFromGist handler to replace local state with gist data
• tests/gist-sync.js - Unit tests for serialization logic

Usage

1. Click the cloud icon in the nav bar
2. Create a GitHub PAT with gist scope (link provided in modal)
3. Connect and use "Sync to Gist" / "Restore from Gist"

Data is stored in a private gist as uuid-ui-data.json with items capped at 100 entries.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>gist sync</issue_title>
<issue_description>Add an option to sync uuid-ui data across browsers and machines using the GitHub Gist API. This would also allow restoring data after a browser reset without needing a custom backend.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes gist sync #373

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR adds GitHub Gist sync functionality to enable cross-browser and cross-machine data persistence for UUID UI history and favorites. Users can authenticate with a GitHub Personal Access Token (PAT), sync their local data to a private gist, and restore it on other devices or after browser resets.

Key Changes:

• New Gist API integration service with create/update/read operations and token management
• Modal UI component for authentication and sync/restore actions
• Integration with existing app state management for data restoration

Reviewed changes

Copilot reviewed 7 out of 10 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
src/gist-sync.js	Core service implementing GitHub Gist API operations, data serialization (capped at 100 items), and localStorage-based token management
src/gist-sync-modal.js	Modal component providing UI for token authentication, sync/restore operations, and connection status with visual feedback
src/nav.js	Adds cloud sync button to navigation bar with green indicator when authenticated, integrates modal component
src/app.js	Implements restoreFromGist handler to deserialize and restore items/favorites from gist data
tests/gist-sync.js	Unit tests for data serialization logic including item limiting and empty data handling
.gitignore	Updated to exclude build artifacts in public/assets/
public/index.html	Updated bundle references (build artifacts that should be gitignored)
public/assets/index-lWTPcmWB.css	Build artifact marked for deletion

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] In the useEffect hook, the isOpen state is checked but the effect doesn't reset the state when the modal is closed. This means that if a user opens the modal, enters a token but doesn't connect, then closes and reopens the modal, the unsaved token will still be visible in the input field. Consider resetting the token state when isOpen becomes false and the user is not connected:

useEffect(() => {
  if (isOpen) {
    const savedToken = getGistToken();
    if (savedToken) {
      setToken(savedToken);
      setIsConnected(true);
    }
    const savedLastSync = getLastSyncTimestamp();
    if (savedLastSync) {
      setLastSync(savedLastSync);
    }
  } else if (!isConnected) {
    // Reset unsaved token when modal closes
    setToken('');
  }
}, [isOpen, isConnected]);

Suggested change

	}
	}, [isOpen]);
	} else if (!isConnected) {
	// Reset unsaved token when modal closes
	setToken('');
	}
	}, [isOpen, isConnected]);

[Copilot]

The generated bundle files in public/assets/ should not be committed to version control as they are build artifacts. The .gitignore has been correctly updated to exclude public/assets/, but these files (index-lWTPcmWB.css and the HTML references to bundle files) are still being tracked in this PR. These should be removed from the commit.

Suggested change

	<script type="module" crossorigin src="./assets/bundle-DScjgMdC.js"></script>
	<link rel="stylesheet" crossorigin href="./assets/index-B5HI90Nx.css">

[Copilot]

The restoreFromGist method doesn't save the restored items to localStorage. This creates an inconsistency where restored data won't persist in localStorage until the next item is added or modified via componentDidUpdate. Users could lose their restored data if they close the browser before making any changes.

Consider calling localStorage.setItem('uuidItems', JSON.stringify(...)) after updating the state, similar to the pattern used in componentDidUpdate.

Suggested change

	this.setState({ items, favorites }, () => {
	this.setState({ items, favorites }, () => {
	// Save restored items to localStorage
	try {
	localStorage.setItem('uuidItems', JSON.stringify(
	items.map(item => ({
	input: item.input || '',
	output: item.output || '',
	info: item.info || ''
	}))
	));
	} catch (e) {
	console.error('Error saving restored items to localStorage:', e);
	}

[Copilot]

The test suite only covers the synchronous serializeData and getHeaders methods, but doesn't test the core async functionality like syncToGist, restoreFromGist, findExistingGist, createGist, updateGist, and validateToken. Since the repository has comprehensive test coverage for other modules (base64, bytes, high-low, type-detector, ulid), the async API methods should also have test coverage using mocked fetch calls.

[Copilot]

When disconnecting from GitHub, the last sync timestamp is cleared from the UI state but not from localStorage. This means that after disconnecting and reconnecting with the same or different token, the old sync timestamp will reappear, which is misleading since it represents a sync from the previous connection.

The handleDisconnect function should also call localStorage.removeItem('gistLastSync') to ensure consistency.

[Copilot]

The error handling for findExistingGist uses response.json().catch(() => ({})) which suppresses JSON parsing errors. If the response body is not valid JSON, the error message will be generic. A more informative approach would be to handle JSON parsing errors separately or provide a fallback error message that doesn't rely on parsing the error response body.

For example:

if (!response.ok) {
  let errorMessage = `Failed to fetch gists: ${response.status}`;
  try {
    const error = await response.json();
    if (error.message) errorMessage = error.message;
  } catch {
    // Keep the default error message
  }
  throw new Error(errorMessage);
}

[Copilot]

The validateToken method silently returns false on network or other errors, making it difficult to distinguish between an invalid token and network issues. This could confuse users who have a valid token but experience temporary network problems. Consider propagating the actual error or providing more specific error handling to differentiate between authentication failures and network errors.

Suggested change

	} catch {
	return false;
	} catch (error) {
	throw error;

[Copilot]

[nitpick] The handleRestore function doesn't close the modal after successfully restoring data. Users might expect the modal to close automatically after a successful restore operation, similar to how many UI patterns work. Consider adding onClose() after the success toast on line 128, or provide a clear indication that users should manually close the modal.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 10 changed files in this pull request and generated 10 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The test should verify that items beyond position 100 are actually excluded, not just that the result has 100 items. The first 100 items might be included by coincidence. Add an assertion to check the content:

assert.strictEqual(result.items.length, 100);
assert.strictEqual(result.items[0].input, 'input0');
assert.strictEqual(result.items[99].input, 'input99');
// Verify that item 100+ are not included
assert.ok(!result.items.find(item => item.input === 'input100'));

Suggested change

	assert.strictEqual(result.items.length, 100);
	assert.strictEqual(result.items.length, 100);
	assert.strictEqual(result.items[0].input, 'input0');
	assert.strictEqual(result.items[99].input, 'input99');
	assert.ok(!result.items.find(item => item.input === 'input100'));

[Copilot]

Accessibility issue: The modal close button (X) at the top right should have keyboard support. Users should be able to close the modal with the Escape key. Add a keyboard event listener:

useEffect(() => {
    if (!isOpen) return;
    
    const handleEscape = (e) => {
        if (e.key === 'Escape') {
            onClose();
        }
    };
    
    document.addEventListener('keydown', handleEscape);
    return () => document.removeEventListener('keydown', handleEscape);
}, [isOpen, onClose]);

[Copilot]

Missing error handling for saveFavoritesToStorage. If this method throws an error, the state will be updated but favorites won't be persisted to storage, leading to data inconsistency. Consider wrapping the callback in a try-catch block:

this.setState({ items, favorites }, () => {
    try {
        this.saveFavoritesToStorage(favorites);
    } catch (e) {
        console.error('Failed to save favorites to storage:', e);
        // Consider showing a toast notification to the user
    }
});

Suggested change

	this.saveFavoritesToStorage(favorites);
	try {
	this.saveFavoritesToStorage(favorites);
	} catch (e) {
	console.error('Failed to save favorites to storage:', e);
	// Optionally, show a toast notification to the user here
	}

[Copilot]

The empty catch block silently swallows parsing errors. If the gist content is malformed JSON, users won't know why the restore failed. The error message "Failed to parse gist content" should be thrown or logged with more details:

try {
    const data = JSON.parse(file.content);
    return {
        items: data.items || [],
        favorites: data.favorites || {},
        timestamp: data.timestamp || null
    };
} catch (e) {
    console.error('Failed to parse gist content:', e);
    throw new Error(`Failed to parse gist content: ${e.message}`);
}

Suggested change

	} catch {
	throw new Error('Failed to parse gist content');
	} catch (e) {
	console.error('Failed to parse gist content:', e);
	throw new Error(`Failed to parse gist content: ${e.message}`);

[Copilot]

Security concern: The GitHub Personal Access Token is stored in localStorage in plain text. While this is standard practice for client-side apps, the PR description should document this security consideration. Users should be aware that tokens stored in localStorage:

1. Can be accessed by any JavaScript running on the same origin
2. Are vulnerable to XSS attacks
3. Should use fine-grained tokens with minimal permissions (only 'gist' scope)

Consider adding a warning message in the modal UI about token security and recommending users create fine-grained tokens limited to gist access only.

[Copilot]

Race condition potential: If the user rapidly clicks "Sync to Gist" multiple times, multiple API calls could be in flight simultaneously, potentially creating multiple gists or causing conflicts. While the isSyncing state prevents the button from being clicked again, a more robust solution would be to cancel in-flight requests or queue them. Consider using AbortController for cancellation or a request queue.

[Copilot]

Accessibility issue: The password visibility toggle button only has an aria-label that changes between "Hide token" and "Show token", but screen reader users won't be notified when the visibility state changes. Consider adding aria-pressed or aria-expanded attributes to communicate the current state:

<button
    type="button"
    onClick={() => setShowToken(!showToken)}
    className={...}
    aria-label={showToken ? 'Hide token' : 'Show token'}
    aria-pressed={showToken}
>

[Copilot]

The conditional color application ${this.state.isGistConnected ? 'text-green-500' : ''} will override the dark/light mode colors defined earlier in the className. When connected, the button will always be green regardless of the theme. Consider using conditional classes that respect the theme, such as:

${this.state.isGistConnected ? (isToggled ? 'text-green-400' : 'text-green-500') : ''}

Suggested change

	} ${this.state.isGistConnected ? 'text-green-500' : ''}`}
	}${this.state.isGistConnected ? (isToggled ? ' text-green-400' : ' text-green-500') : ''}`}

[Copilot]

The formatLastSync function has an edge case bug. When the date difference is exactly 7 days or more, it falls through to toLocaleDateString, but the year condition uses !== which could cause unexpected behavior during year transitions. For example, if now is January 1, 2024 and date is December 25, 2023, the year will be shown even though it's recent. Consider using a days threshold instead:

if (diffDays < 7) return `${diffDays}d ago`;
if (diffDays < 365) {
    return date.toLocaleDateString('en-US', { month: 'short', day: 'numeric' });
}
return date.toLocaleDateString('en-US', { month: 'short', day: 'numeric', year: 'numeric' });

Suggested change

	return date.toLocaleDateString('en-US', {
	month: 'short',
	day: 'numeric',
	year: date.getFullYear() !== now.getFullYear() ? 'numeric' : undefined
	});
	if (diffDays < 365) {
	return date.toLocaleDateString('en-US', { month: 'short', day: 'numeric' });
	}
	return date.toLocaleDateString('en-US', { month: 'short', day: 'numeric', year: 'numeric' });

[Copilot]

Duplicate error handling code. The pattern of checking !response.ok, attempting to parse JSON with a catch, and throwing an error is repeated in lines 67-68, 102-104, 133-135, and 174-176. Consider extracting this into a helper method:

async handleApiError(response, operation) {
    const error = await response.json().catch((e) => {
        console.error('Failed to parse error response:', e);
        return {};
    });
    throw new Error(error.message || `Failed to ${operation}: ${response.status}`);
}

Then use: if (!response.ok) await this.handleApiError(response, 'fetch gists');