-
Notifications
You must be signed in to change notification settings - Fork 46
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
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 explicitReact
import, 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 withCoherence
andJurorRewards
.
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
addressToQuery
to the query hooks. Consider adding a fallback for scenarios whereaddressToQuery
might 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_CHAIN
is 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 theAddress
component is valid, but you could reuse theExternalLinkHoverStyle
for 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
JurorRewards
andJurorInfo
components to accept anaddressToQuery
prop, 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
JurorRewards
andJurorInfo
to acceptaddressToQuery
prop.JurorTitle
,EvidenceCard
, andAccordionTitle
.Header
to conditionally display "My" or "Their" based on search parameters.Courts
andDashboard
to utilizeaddressToQuery
for fetching data.useSearchParams
to several components for better URL parameter management.Filters
andSearch
to maintain search parameters during routing.Summary by CodeRabbit
New Features
Bug Fixes
Refactor
useAccount
hook in favor of prop-based address querying.Style