Explorer Laravel Package

Product Decisions This Supports

• Enhancing Search Capabilities: Accelerate the development of server-driven DataTables and advanced search interfaces (e.g., admin panels, e-commerce filters, or content discovery) with minimal boilerplate. Reduces frontend-backend complexity by offloading pagination, sorting, and filtering logic to the backend.
• Roadmap for Admin Tools: Prioritize reusable Explorer classes to standardize table behaviors across internal tools (e.g., user management, analytics dashboards), reducing technical debt and improving consistency.
• Build vs. Buy: Buy—avoids reinventing server-side DataTable logic, saving 3–6 months of dev time while delivering production-ready features like:
  • Dynamic column formatting (e.g., currency, dates).
  • Computed values (e.g., "Profit Margin" from revenue - cost).
  • Custom filters (e.g., date ranges, multi-select dropdowns).
• Use Cases:
  • Admin Panels: Replace manual where/orderBy chains in controllers with declarative Explorer classes (e.g., for users, orders, or content tables).
  • Public-Facing Search: Power search-as-you-type interfaces with Elasticsearch’s speed (e.g., autocomplete for products or articles).
  • Analytics Dashboards: Leverage aggregations (e.g., "Top 10 products by sales") without writing raw SQL or Elasticsearch queries.
  • Hybrid Workflows: Combine with Laravel Scout for search + Explorer for tabular data (e.g., a "Search Results" table with filters).

When to Consider This Package

• Adopt if:

  • Your Laravel app needs server-side DataTables with search, sort, and pagination (e.g., admin panels, reporting tools).
  • You’re using Laravel Scout but want to expose search results in a tabular format without duplicating logic.
  • Your team lacks frontend expertise for client-side DataTables (e.g., jQuery DataTables, AG Grid) but needs scalable backend pagination.
  • You require reusable table definitions (e.g., UserExplorer, OrderExplorer) to avoid copy-pasted controller logic.
  • Your use case involves complex filtering (e.g., nested conditions, computed columns) that would bloat controllers or require heavy frontend JS.

• Look elsewhere if:

  • Your tables are simple (e.g., static CRUD grids with no search/sort) and can be handled by Laravel’s built-in pagination (paginate()).
  • You’re using client-side DataTables (e.g., for large datasets where server-side processing isn’t feasible).
  • Your stack doesn’t include Laravel Scout or Elasticsearch (this package is Scout-centric).
  • You need real-time updates (e.g., WebSocket-driven tables); Explorer relies on server-rendered responses.
  • Your team prefers low-code frontend tools (e.g., Filament, Nova) that include built-in table components.

How to Pitch It (Stakeholders)

For Executives:

*"This package lets us build admin panels and search interfaces 10x faster by moving DataTable logic to the backend. Instead of writing custom controllers for every table (e.g., users, orders, content), we define reusable ‘Explorer’ classes that handle sorting, filtering, and pagination—just like a spreadsheet but scalable. It’s a ‘buy vs. build’ win:

• Faster development: Launch tables in days, not weeks.
• Lower maintenance: No duplicate controller logic or frontend JS bugs.
• Future-proof: Works with Laravel Scout for search + Explorer for tables.

Example: For our new analytics dashboard, this could cut dev time by 60% while supporting features like ‘export to CSV’ or ‘group by date’ out of the box."*

Key Outcomes:

• Reduced technical debt from copy-pasted table logic.
• Consistent UX across admin tools (e.g., same filtering patterns).
• Scalability for high-traffic tables (e.g., 100K+ rows).

For Engineering Teams:

*"This is a backend-first DataTables solution that replaces frontend-heavy libraries like jQuery DataTables. Here’s how it works:

1. Define an Explorer class (e.g., UserExplorer) with columns, filters, and actions.
2. Plug it into your UI (e.g., via a simple API endpoint or Blade component).
3. Profit: Server handles pagination, sorting, and filtering—no more if ($request->has('sort')) spaghetti in controllers.

Why it’s better than alternatives:

• No frontend JS: Avoids DataTables’ dependency bloat and compatibility issues.
• Reusable: One UserExplorer class powers all user tables (list, search results, etc.).
• Extensible: Add custom filters (e.g., where('status', 'active')) or computed columns (e.g., profit_margin) via methods.

Trade-offs:

• Requires Laravel Scout (but we can start with a simple database driver).
• Server-side only: Not ideal for offline or client-side-heavy apps.

Quick Start:

// Define a reusable table
class UserExplorer extends Explorer
{
    public function columns()
    {
        return [
            Column::make('name')->sortable(),
            Column::make('email')->searchable(),
            Column::make('created_at')->date(),
        ];
    }

    public function filters()
    {
        return [
            Filter::make('active')->boolean(),
            Filter::make('role')->select(['admin', 'user']),
        ];
    }
}

// Use it in a controller
public function index(Request $request)
{
    return (new UserExplorer)->query($request)->paginate();
}

ROI:

• For admin panels: Replace 500+ lines of controller logic with 50 lines of Explorer code.
• For search interfaces: Combine with Scout to show search results in a filterable table (e.g., ‘Search results for “Laravel”’ with columns for title, author, date)."*

For Design/UX Teams:

*"This package lets us design tables without worrying about backend limits. Need a sortable column? Add ->sortable(). Want to filter by date range? Define it once in the Explorer class. The backend handles:

• Infinite scroll/pagination: No more ‘Load More’ buttons breaking.
• Consistent sorting: Click a header, and it works everywhere.
• Responsive defaults: Tables adapt to mobile/desktop without CSS hacks.

Example: For the new ‘Content Manager’ tool, we can prototype a table with 10 columns and 5 filters in hours—not days—because the backend logic is abstracted away."*