Area
Voting Pillar
Domain
gov.tools
Which wallet were you using?
No response
Context
In the governance dashboard, the filtering of proposals a DRep has already voted on is currently implemented entirely on the frontend (within DashboardGovernanceActionsVotedOn and GovernanceActionsToVote components).
This logic involves complex filtering inside a React useMemo hook that processes mappedData, votes, and proposal details to exclude proposals already voted on. The code is difficult to maintain, causes unnecessary client-side computation, and should be handled by the backend/API instead.
By moving this logic to the backend, we can simplify the React components, reduce frontend data processing, and ensure consistency and scalability for future API consumers.
Notes
-
The backend should handle filtering of proposals so that the API directly returns:
- proposals to vote on (not yet voted), and
- proposals already voted on,
as distinct datasets or through clear filtering parameters.
-
The frontend should simply display what the backend provides, without reproducing filtering logic.
-
Preserve the current behavior and data integrity (i.e., the UI should look and work exactly the same after refactoring).
-
Ensure API responses include any necessary metadata for frontend pagination or status updates.
-
The current frontend filtering logic (below) should be fully removed:
// TODO: Filtering here is some kind of craziness. It should be done on the backend.
const filteredProposals = useMemo(() => {
const list = mappedData ?? [];
if (!votes?.length) return list;
const proposalsFromVotes = votes
.flatMap((v) => v?.actions ?? [])
.map((a) => a?.proposal)
.filter(Boolean);
const votedKeys = new Set(
proposalsFromVotes
.map((p) => ({
id: p?.id ?? p?.id,
tx: p?.txHash ?? p?.txHash,
}))
.filter(({ id, tx }) => Boolean(id && tx))
.map(({ id, tx }) => `${id}:${tx}`),
);
if (votedKeys.size === 0) return list;
return list.filter((p) => {
const id = p?.id ?? p?.id;
const tx = p?.txHash ?? p?.txHash;
if (!id || !tx) return true;
return !votedKeys.has(`${id}:${tx}`);
});
}, [mappedData, voter?.isRegisteredAsDRep, isProposalsFetchingNextPage]);
Steps to reproduce
- Open the Governance Dashboard.
- Observe the proposals shown under both “Governance Actions to Vote On” and “Governance Actions Voted On” sections.
- Note that filtering between these sections currently happens client-side in React.
Actual behavior
Filtering of voted/unvoted governance actions is done on the frontend using complex client-side logic, increasing code complexity and computation on the user’s browser.
Expected behavior
Filtering should be performed by the backend:
- The frontend should receive pre-filtered data (voted vs not voted).
- The React components should only render data without additional filtering logic.
- Behavior, output, and visual presentation remain identical to current implementation.
Area
Voting Pillar
Domain
gov.tools
Which wallet were you using?
No response
Context
In the governance dashboard, the filtering of proposals a DRep has already voted on is currently implemented entirely on the frontend (within
DashboardGovernanceActionsVotedOnandGovernanceActionsToVotecomponents).This logic involves complex filtering inside a React
useMemohook that processesmappedData,votes, and proposal details to exclude proposals already voted on. The code is difficult to maintain, causes unnecessary client-side computation, and should be handled by the backend/API instead.By moving this logic to the backend, we can simplify the React components, reduce frontend data processing, and ensure consistency and scalability for future API consumers.
Notes
The backend should handle filtering of proposals so that the API directly returns:
as distinct datasets or through clear filtering parameters.
The frontend should simply display what the backend provides, without reproducing filtering logic.
Preserve the current behavior and data integrity (i.e., the UI should look and work exactly the same after refactoring).
Ensure API responses include any necessary metadata for frontend pagination or status updates.
The current frontend filtering logic (below) should be fully removed:
Steps to reproduce
Actual behavior
Filtering of voted/unvoted governance actions is done on the frontend using complex client-side logic, increasing code complexity and computation on the user’s browser.
Expected behavior
Filtering should be performed by the backend: