- Notifications
You must be signed in to change notification settings - Fork 50
feat: public dashboards #1819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: public dashboards #1819
Conversation
WalkthroughThis pull request introduces comprehensive changes to multiple components across the web application, focusing on enhancing URL parameter handling and navigation. The modifications primarily involve implementing Changes
Sequence DiagramsequenceDiagram participant User participant URL participant Component participant Navigation User->>URL: Enters/modifies search parameters URL->>Component: Passes search parameters Component->>Navigation: Preserves search parameters Navigation->>Component: Updates view with parameters Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (5)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File ( |
✅ Deploy Preview for kleros-v2-university ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kleros-v2-neo ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (11)
web/src/pages/Home/TopJurors/JurorCard/JurorTitle.tsx (1)
1-5: Use consistent import approach.
Since React 17+ allows JSX without the explicitReactimport, consider removingimport React from "react"if your toolchain supports the new JSX transform. However, retaining it can still be fine for clarity.web/src/pages/Dashboard/Courts/Header.tsx (1)
66-66: Dynamically switching text.
The ternary"Their" : "My"is an effective approach. However, be mindful of user-facing text in multi-language contexts or expansions.web/src/pages/Dashboard/JurorInfo/index.tsx (2)
59-59: Spread operator usage is clean.
Using the object spread operator is concise and fine, though you might consider explicit named props for added clarity in large-scale components.
63-64: Composition withCoherenceandJurorRewards.
Combining these subcomponents under the same card is a tidy layout. Watch for potential performance bottlenecks if future expansions increase complexity.web/src/pages/Dashboard/Courts/index.tsx (2)
42-43: Refactor suggestion: add fallback or error handling for stake queries.We're directly passing
addressToQueryto the query hooks. Consider adding a fallback for scenarios whereaddressToQuerymight be invalid or missing.
57-59: User-friendly messaging.Consider clarifying the “They”/“You” message further for improved UX. For instance, if
searchParamAddress === addressToQuery, you might detect a case of self vs. third party.web/src/pages/Cases/CaseDetails/Voting/VotesDetails/AccordionTitle.tsx (2)
4-5: ImportinglandscapeStyle.Ensure consistent usage with the rest of the codebase. The spacing and extra blank line is minor but can be maintained for readability.
45-49: Styled component usage.Good approach for theming. Consider centralizing hover styling for consistency across the app.
web/src/components/CasesDisplay/Search.tsx (1)
41-41: Styling for the input block.Make sure to keep consistent sizing or reuse from a theming system to maintain uniform UI.
web/src/pages/Dashboard/JurorInfo/Header.tsx (1)
81-85: Block explorer link creation.Memoizing ensures stable references. Just confirm that
DEFAULT_CHAINis really the intended chain; you might want chain detection for multi-chain.web/src/components/EvidenceCard.tsx (1)
158-161: Consider standardizing hover styling.
The hover color on theAddresscomponent is valid, but you could reuse theExternalLinkHoverStylefor visual parity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
web/src/components/CasesDisplay/Filters.tsx(2 hunks)web/src/components/CasesDisplay/Search.tsx(4 hunks)web/src/components/EvidenceCard.tsx(4 hunks)web/src/pages/Cases/CaseDetails/Voting/VotesDetails/AccordionTitle.tsx(3 hunks)web/src/pages/Dashboard/Courts/Header.tsx(2 hunks)web/src/pages/Dashboard/Courts/index.tsx(3 hunks)web/src/pages/Dashboard/JurorInfo/Header.tsx(2 hunks)web/src/pages/Dashboard/JurorInfo/JurorRewards.tsx(1 hunks)web/src/pages/Dashboard/JurorInfo/index.tsx(2 hunks)web/src/pages/Dashboard/index.tsx(2 hunks)web/src/pages/Home/TopJurors/JurorCard/JurorTitle.tsx(3 hunks)
🔇 Additional comments (51)
web/src/pages/Home/TopJurors/JurorCard/JurorTitle.tsx (2)
23-27: Styling updates look good.
Changing the hover color from theme.primaryBlue to theme.secondaryBlue aligns with the shift towards a secondary color accent. No issues found here.
37-44: Verify the correctness and consistency of the dashboardLink.
Confirm the route /dashboard/1/desc/all is correct and that address is properly handled if it’s missing or malformed. Consider additional validation or default handling for the address parameter.
web/src/pages/Dashboard/JurorInfo/JurorRewards.tsx (1)
29-34: Prop-driven address query is a solid improvement.
Receiving addressToQuery as a prop rather than from a global hook gives better modularity and testability. Ensure input validation or fallback for invalid addresses, if relevant.
web/src/pages/Dashboard/Courts/Header.tsx (2)
5-5: Using useSearchParams is a good practice.
Extraction of the query parameter encourages direct, user-friendly navigation. No immediate issues detected.
61-62: Lowercasing address from searchParams.
Address normalization is helpful, but consider verifying or sanitizing the input if used in subsequent calls or displayed in the UI.
web/src/pages/Dashboard/JurorInfo/index.tsx (2)
40-43: Clear interface definition.
Defining IJurorInfo with addressToQuery improves readability and clarity. Good job on typed string literals for addresses.
44-45: Query user data via prop-provided address.
Decoupling from useAccount fosters reusability. Ensure fallback behavior if addressToQuery is undefined or invalid.
web/src/pages/Dashboard/Courts/index.tsx (4)
5-5: Use of useSearchParams: Good approach, watch out for consistent usage.
Importing useSearchParams helps retrieve query parameters without extra overhead. Make sure you consistently handle possible null or undefined values when reading the search param.
38-40: Interface definition clarity.
Defining the ICourts interface with a typed addressToQuery is clear and helpful for TS safety.
45-45: Parameter usage.
Using args: [addressToQuery, BigInt(1)] is correct. If future courts are added, consider making the court ID dynamic instead of hardcoded to BigInt(1).
47-48: Guard search param usage.
If searchParamAddress is used in logic below, ensure you handle any edge cases when the param is not provided or is malformed.
web/src/pages/Cases/CaseDetails/Voting/VotesDetails/AccordionTitle.tsx (4)
1-1: Import React from "react"
This is typical usage; no issues here.
13-13: Switch to internal link for better routing.
Good move to unify internal navigation with InternalLink. This makes routing consistent across the app.
91-91: Dashboard link structure.
Embedding chain ID in the URL (e.g., /dashboard/1/...) might need to be dynamic. Keep an eye on future multi-chain support.
97-99: Dynamic address usage in link.
Using juror directly in the query param is correct. Ensure that addresses are normalized or validated.
web/src/components/CasesDisplay/Search.tsx (7)
1-1: Multiple imports in one statement.
Looks neat. No concerns unless the bundle size is an issue.
5-5: Proper usage of useNavigate, useParams, and useSearchParams.
All relevant React Router hooks are correctly combined for flexible navigation.
56-56: Initial render guard.
Using a ref to detect the first render is a well-known pattern for preventing side effects.
58-59: Extracting search params.
Consider hooking changes (like query param changes) into a side effect if needed. Currently, this is straightforward.
62-65: Short-circuit if empty search on first render.
A good measure to avoid unwanted navigation. Just confirm that a follow-up navigation occurs if the user modifies the search bar.
69-69: Appending searchParams to the navigation path.
Maintains current query parameters—useful for combining multiple filters. Great approach.
94-94: Court selection navigation.
Appending searchParams ensures consistent query params after changes. Good user experience improvement.
web/src/pages/Dashboard/JurorInfo/Header.tsx (9)
1-1: useMemo import for performance.
Creating memoized values for explorer links prevents unnecessary re-computations if the address doesn’t change frequently.
7-8: useSearchParams in a juror info header.
Retrieving the address param helps differentiate between the user’s own address vs. external addresses—just handle edge cases.
12-14: Imports from consts/chains and shortenAddress.
Combining getChain() with shortenAddress is a neat, consistent way to handle chain-based addresses.
53-57: Styled external link for uniform typography.
Great approach to keep link styling consistent across the application.
64-64: Updated IHeader interface.
Adding addressToQuery: \0x${string}`` enforces a typed address shape. This is a nice improvement.
67-73: Extended props in Header:
Accepting addressToQuery fosters reusability and decouples from direct hooks.
75-75: useSearchParams usage for multi-address scenarios.
You might add a fallback or default address logic if the param is missing, especially for brand-new visits.
89-96: Address copy button.
The Copiable component offering quick copying is a great UX improvement. Wrapping the external link inside is consistent with the design.
103-103: Conditional share link.
Suppressing the share link if the user is viewing someone else’s data is a clear approach. Confirm you have UI to handle partial coverage of totalResolvedVotes = 0.
web/src/pages/Dashboard/index.tsx (12)
2-5: Imports look good.
The inclusion of these additional style modules appears consistent with their usage for responsive layout enhancements.
7-7: Adoption of useSearchParams.
Bringing in useSearchParams aligns well with the objective of preserving query parameters in the URL.
54-54: Rename to connectedAddress is clear.
Renaming address to connectedAddress clarifies its distinction from the search parameter address.
56-56: Excellent approach to maintain URL state.
Using [searchParams] = useSearchParams() ensures consistency with the rest of the codebase for query parameter handling.
59-59: Consider validating the address.
The optional chain and toLowerCase usage is correct, but consider adding a simple address validation utility to ensure this is genuinely a valid address.
60-60: Good fallback to connectedAddress.
Defaulting to the wallet address when no address param is present is intuitive and ensures continuity.
66-66: Query parameter usage is consistent.
Passing addressToQuery into useMyCasesQuery matches the new URL-driven approach.
71-71: Consistent usage of addressToQuery.
Aligns well with the filter logic in useUserQuery.
81-81: Conditionally render dashboard for external addresses.
Allowing dashboard viewing via URL param (even if not connected) is a user-friendly addition.
83-84: Prop forwarding is consistent.
Passing addressToQuery to <JurorInfo /> and <Courts /> ensures they remain in sync and decoupled from direct wallet usage.
86-86: Dynamic title is user-friendly.
Using "Their Cases" vs. "My Cases" helps clarify whose data is being displayed.
92-94: Preserving URL parameters on pagination.
Including existing search params when navigating to other pages ensures a seamless user experience.
web/src/components/EvidenceCard.tsx (4)
141-141: New ExternalLinkHoverStyle centralizes hover behavior.
Having a unified hover styling block fosters consistency across components.
165-165: Consistent use of ExternalLinkHoverStyle.
Applying the shared hover style helps keep user interactions uniform.
226-226: Dashboard link is a neat addition.
Constructing dashboardLink based on the sender's address provides an easy path for internal navigation.
251-253: Switch from external explorer to internal dashboard link.
Replacing the block explorer link with an internal dashboard link aligns with the overall URL-parameter-based approach.
web/src/components/CasesDisplay/Filters.tsx (4)
6-6: Introduce useSearchParams.
Adding useSearchParams for synchronizing filters with URL parameters is consistent with implementation across the codebase.
58-58: Stateful search parameter usage.
Grabbing [searchParams] once allows efficient preservation of query parameters for subsequent navigation calls.
63-63: Preserve existing search params on status change.
Appended ?${searchParams.toString()} ensures previously set parameters remain intact.
68-68: Ordering logic retains search params too.
Maintaining consistency in filter and order handling across navigations is beneficial for user experience.
✅ Deploy Preview for kleros-v2-testnet-devtools ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
| Code Climate has analyzed commit 8b11b62 and detected 16 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
|



PR-Codex overview
This PR focuses on enhancing the
JurorRewardsandJurorInfocomponents to accept anaddressToQueryprop, improving the handling of addresses in various components, and updating links from external to internal navigation. It also refines the display logic based on the presence of search parameters.Detailed summary
JurorRewardsandJurorInfoto acceptaddressToQueryprop.JurorTitle,EvidenceCard, andAccordionTitle.Headerto conditionally display "My" or "Their" based on search parameters.CourtsandDashboardto utilizeaddressToQueryfor fetching data.useSearchParamsto several components for better URL parameter management.FiltersandSearchto maintain search parameters during routing.Summary by CodeRabbit
New Features
Bug Fixes
Refactor
useAccounthook in favor of prop-based address querying.Style