block / block/proto-fleet

Add search/filter functionality to the All Miners table (and other miner-selection surfaces)

Closed
#809 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
55
Forks
16
Avg merge
1d 17h
Merged PRs (30d)
84

Description

### Problem

When managing a fleet of 3,000+ miners, there is no way to quickly locate a specific miner by a unique identifier (MAC address, IP address, Worker Name, Serial Number, etc.). Users must scroll through the full table or rely on column sorting/filtering to find a specific device. This is especially painful when investigating a known miner (e.g., "the miner with MAC `C8:98:DB:10:DC:7C` had issues last week — is it healthy now?").

### Proposed solution

## Desired Behavior

Add a search input to the All Miners page (above or alongside the existing filter controls) that filters the table in-place as the user types.

**Preferred approach (lazy/global search):**
- Single text input that matches across all identifier columns simultaneously
- Debounced as-you-type filtering (200–300ms delay)
- Matches against: Name, Serial Number, MAC Address, IP Address, Worker Name
- Partial/substring matching (e.g., typing `DC:7C` matches `C8:98:DB:10:DC:7C`)

**Acceptable fallback (column-scoped search):**
- If global cross-column search is too complex or has performance concerns at scale, allow the user to select a specific column to search within via a dropdown, then enter their search term.

## Scope: Reuse across other surfaces

This search behavior should be implemented as a reusable component and embedded in **any UI surface that involves selecting or browsing miners**, including but not limited to:
- Creating a rack (selecting miners to assign)
- Manually adding miners to a group or site
- Any future miner-picker or miner-list view

The goal is a consistent search experience wherever a user needs to find a specific miner.

## Acceptance Criteria

- [ ] Search input is visible on the All Miners page alongside existing filter/sort controls
- [ ] Typing a query filters the table in-place (no navigation to a separate results view)
- [ ] Matches work on partial strings (substring match)
- [ ] Performs acceptably with 3,000+ miners in the table
- [ ] Clearing the search restores the full (filtered) table
- [ ] Search works in combination with existing filters (e.g., Status: Hashing + search for a MAC)
- [ ] Same search component is used in rack creation and manual miner-addition flows
- [ ] Search component is built to be reusable for future miner-selection surfaces

### Duplicate check

- [x] I have searched existing issues and this is not a duplicate

### Alternatives considered

_No response_

### Component

Client (Web UI)

### Additional context

## Context

- Current page has column filtering and sorting but no text search

Contributor guide

Open the contributing guide

Research direction

Start at the All Miners page and its existing filter/sort controls, then trace the miner-selection entry points for rack creation and manual miner addition. Implement a reusable search component with partial matching, debouncing, filter combination, and acceptable performance for 3,000+ miners; done means all listed acceptance criteria pass on each surface.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.