refactor: improve OrchestratorList maintainability and mobile layout (Fixes #466)

[Roaring30s]

Refactor: OrchestratorList Component Improvements

Overview

This PR refactors the OrchestratorList component to improve maintainability, readability, and mobile user experience. The changes include component extraction, logic centralization, and responsive design improvements.

Fixes Issue #466

Refactoring for Maintainability & Readability

Component Extraction

To improve testability and maintainability, several components were extracted from the monolithic OrchestratorList:

• OrchestratorCard - Encapsulates the mobile card view UI and logic
• OrchestratorActionsMenu - Reusable "three dots" action menu (used in both desktop and mobile views)
• YieldAssumptionsControls - Filter controls UI for forecasted yield assumptions
• PaginationControls - Extracted pagination UI into a reusable component within the Table folder

Logic Centralization

• useOrchestratorViewModel - Custom hook that centralizes:

  • Filter state management (principle, timeHorizon, factors, inflationChange)
  • Data transformation and sorting (mappedData)
  • Contract data fetching (useBondingManagerAddress, useReadContract)
  • Derived values (formattedPrinciple, maxSupplyTokens, formatPercentChange)

• useOrchestratorRowViewModel - Per-row formatting hook for:

  • feeCut, rewardCut, rewardCalls calculations
  • Memoized formatting logic shared between desktop columns and mobile cards

Utility Function Consolidation

• Moved formatTimeHorizon and formatFactors to lib/roi.ts to centralize ROI-related utilities
• Both functions are now reusable across the codebase

Unified Rendering Approach

• Replaced the renderCard prop pattern with conditional column arrays (desktopColumns vs mobileColumns)
• Both mobile and desktop now use the same Table component with different column configurations
• Added constrainWidth prop to Table component to handle mobile overflow issues without affecting other tables

Mobile Layout Improvements

• Fixed card overflow issues with proper width constraints and box-sizing
• Made ENS name/address layout responsive: stacks vertically on mobile phones, horizontal on tablets
• Reduced wallet address font size when ENS name is present to save space
• Added proper flex constraints to prevent content cutoff

📋 Feedback Request: Mobile Card Design Approach

This section is not for approval, but to gather team feedback.

Since react-table v7 is a headless library with no built-in mobile/responsive functionality, I implemented a custom card-based layout for mobile devices. This approach:

• Uses the same Table component infrastructure
• Conditionally renders different column arrays based on screen size
• Maintains consistency with desktop sorting and pagination logic
• Provides a mobile-optimized card UI

Question for the team: Are we comfortable with this card-based approach being the default pattern for mobile table views? This PR introduces several opinionated architectural decisions, and I'd like to ensure the team is aligned before proceeding further.

One last mention: Feel free to let me know if any of my patterns or approaches here are good to keep or some changes are needed. I am doing my best to level myself up so any feedback and criticisms would be heavily appreciated.

🔍 Known Limitation: Mobile Column Filtering

Currently, the mobile card view uses a single column (earnings) in the mobileColumns array. This means:

• ✅ Sorting by "Forecasted Yield" works on mobile
• ❌ Sorting by "Delegated Stake" or "Trailing 90D Fees" is not available on mobile

The Issue:
Since react-table's sorting is tied to column definitions, and we're only defining one column for mobile, only that column's sorting is available.

Potential Solutions:

1. Include hidden columns in mobileColumns - Add totalStake and ninetyDayVolumeETH columns with empty Cell renderers, keeping them in the array for sorting purposes while only visually rendering the card
2. Add Table Context - Extend the Table component with a context provider that exposes toggleSortBy and sortBy, allowing custom header components to access sorting functionality
3. Custom Mobile Header Component - Create a mobile header that shows all three filter options and manually triggers sorting (would require the context approach above)

Discussion Needed:
To add filtering capabilities for the other two columns on mobile, we would need to make changes to the Table component (like adding a context provider). Before implementing this, I'd like to discuss:

• Is this level of mobile filtering necessary?
• Which approach do we prefer?
• Should we prioritize this in this PR or handle it separately?

Files Changed

• components/OrchestratorList/index.tsx - Main refactoring
• components/OrchestratorList/OrchestratorCard.tsx - New component
• components/OrchestratorList/OrchestratorActionsMenu.tsx - New component
• components/OrchestratorList/YieldAssumptionsControls.tsx - New component
• components/Table/index.tsx - Added constrainWidth prop and context
• components/Table/PaginationControls.tsx - New component
• hooks/useOrchestratorViewModel.ts - Centralized view model logic
• hooks/useOrchestratorRowViewModel.ts - Per-row formatting hook
• lib/roi.ts - Added utility functions

Testing

• ✅ All linting and formatting checks pass
• ✅ Mobile card layout fits within parent container
• ✅ Responsive layout works correctly (vertical on mobile, horizontal on tablet)
• ✅ Desktop table functionality unchanged
• ✅ Sorting and pagination work on both mobile and desktop

Upon Feedback

If we can come to a consensus on how to approach the Orchestrator Table, then we could easily use this approach to make the other tables in the explorer mobile-compatible as well in one shot.

[vercel]

@Roaring30s is attempting to deploy a commit to the Livepeer Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[Roaring30s]

@ECWireless Feel free to let me know if you are fine with this card design and my approach to the refactors. If all is good, we can employ a similar card approach and refactor to the rest of the tables in explorer that also need mobile responsiveness.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
explorer-arbitrum-one	Ready	Preview, Comment	Jan 13, 2026 2:30am

[ECWireless]

@Roaring30s this is awesome! And really appreciate the level of thought you put into the PR write-up. I think solution 3 is the best route for sorting, to be honest; though I recognize that this could be a lot of work, so want to be realistic about what you're willing to contribute with this. Please let me know if you need any kind of support!

[Roaring30s]

@ECWireless Sounds good. I'll implement it. Just wanted to get your guys' opinion if you were fine with me implementing solution 3 in the PR. And thank you for checking my code and giving me feedback. These PR's are helping me learn. Ill have this done today as well.

[rickstaa]

@Roaring30s The refactors into reusable components and helper functions could make sense if these components are already shared elsewhere, otherwise, it may be better to keep them local for now.

@ECWireless would you mind taking a look? If it makes sense, we can also move those refactors into a separate PR.

[Roaring30s]

@rickstaa I can investigate this. But when looking at the live website, I am not seeing some body-level horizontal scroll activating. Only at the orchestrator table level.

[rickstaa]

@rickstaa I can investigate this. But when looking at the live website, I am not seeing some body-level horizontal scroll activating. Only at the orchestrator table level.

Your correct, sorry I was mixing up two issues l. The problem is on the orchestrators page. The problem is that the Performance Leaderboard button should be put under the Orchestrators title.

Screen_Recording_20260113_152039_Brave.mp4

[Roaring30s]

@rickstaa I can investigate this. But when looking at the live website, I am not seeing some body-level horizontal scroll activating. Only at the orchestrator table level.

Your correct, sorry I was mixing up two issues l. The problem is on the orchestrators page. The problem is that the Performance Leaderboard button should be put under the Orchestrators title.

Screen_Recording_20260113_152039_Brave.mp4

Okay cool thanks for the vid. Ill fix this.

One last thing. While EC reviews it, even if some of the components only have a one time use, the refactors I made will make it very easy for us to test things in isolation like the PaginationControls and putting things in hooks allows me to more easily set boundaries in testing. Which was something I was going to eventually throw my hat in the ring with was to help expand test coverage for the repo. So that was where my thinking was going. We can nix the mobile compatibility code I have in this PR but still preserve the refactors for the purpose mentioned above but you guys let me know.

[ECWireless]

@Roaring30s looks like this is hitting linting/type errors

[Roaring30s]

@Roaring30s looks like this is hitting linting/type errors

Yeah. I fixed a conflict this morning and this came up so Ill clean it up.

[Roaring30s]

@ECWireless Lint errors fixed. Note. This is not ready for merge but just some quick feedback is needed from your end.

1. Are you ok with the refactoring approach we did here? I did it to make testing in isolation easier. We could apply this to the other tables. If not, I can discard and go with Rickstaa's approach of not worrying about it at the moment.

2. Do we preserve how the table's are on mobile mode with the horizontal scroll or do we implement this card approach that you will see you in your vercel deployment, which can also be employed in the other tables down the road.

3. As discussed earlier, if we do go with the card method, then I can build a context in the Table component to make it work with the cards.

You let me know what approach works best for your team and Ill accommodate. With the feedback, Ill get the PR merge ready.