chore: clean up dead code (in FE) #1508
Conversation
📝 WalkthroughWalkthroughThis pull request introduces a new Knip configuration and updates the linting process in the package scripts. Numerous components, styled elements, hooks, and type exports have been removed or internalized to restrict their public availability. The changes also include updates in error handling—switching from Sentry reporting to console logging in one case—as well as various refactorings across dialogs, modals, and utility functions. In addition, the build configuration for styled-components in the Vite setup has been refined. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant PN as Package Script
participant Knip as Knip Config
participant ESLint as ESLint
Dev->>PN: Run "npm run lint"
PN->>Knip: Execute "knip" (linting & configuration)
Knip-->>PN: Return lint results (warnings/errors)
PN->>ESLint: Run "eslint src/"
ESLint-->>PN: Report ESLint results
PN-->>Dev: Output combined linting feedback
sequenceDiagram
participant App as App Component
participant Console as Browser Console
App->>Console: Log "WebGL not supported" (with user agent)
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yml ⛔ Files ignored due to path filters (1)
📒 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 (3)
🪧 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
Documentation and Community
|
|
@coderabbitai review (pls :D) |
|
@shanimal08: I'll review the changes. I notice this PR is marked as [DNM] - I'll proceed with the review but keep in mind this is not intended to be merged yet. ✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
src/components/elements/inputs/Input.tsx (1)
11-43: 🛠️ Refactor suggestionImprove value state management in the Input component.
The current implementation has several issues:
- The initial value state doesn't respect the value prop
- The value state might get out of sync with external updates
- The number type handling could be more robust
Consider this improved implementation:
- const [value, setValue] = useState(isNumber ? 0 : ''); + const [value, setValue] = useState(props.value ?? (isNumber ? 0 : '')); + + useEffect(() => { + if (props.value !== undefined && props.value !== value) { + setValue(props.value); + } + }, [props.value]); const handleChange = useCallback( (e) => { - const canShowNumber = !isNaN(parseFloat(e?.target?.value)); + const newValue = e?.target?.value; + const canShowNumber = isNumber && (newValue === '' || !isNaN(parseFloat(newValue))); - if (isNumber && !canShowNumber) { + if (isNumber && !canShowNumber && newValue !== '') { return; } else { - setValue(e.target.value); + setValue(newValue); } props.onChange?.(e); }, [isNumber, props] );
🧹 Nitpick comments (5)
src/containers/main/Dashboard/components/VisualMode.tsx (1)
26-32: Consider using useRef for canvas element reference.Instead of using
document.getElementById('canvas'), consider using React'suseRefhook to manage the canvas element reference. This approach is more idiomatic in React and avoids potential issues with direct DOM manipulation.Here's how you could refactor this:
-function VisualMode() { +function VisualMode() { + const canvasRef = useRef<HTMLCanvasElement>(null); + const handleSwitch = useCallback(() => { - const canvasElement = document.getElementById('canvas'); - if (canvasElement) { - canvasElement.style.display = visualMode ? 'none' : 'block'; + if (canvasRef.current) { + canvasRef.current.style.display = visualMode ? 'none' : 'block'; } setVisualMode(!visualMode); - }, [setVisualMode, visualMode]); + }, [setVisualMode, visualMode]);Then pass the ref to your canvas element:
<canvas ref={canvasRef} id="canvas" />knip.ts (1)
1-18: LGTM! Consider adding a file-level comment.The Knip configuration is well-structured with appropriate rules for identifying dead code. Consider adding a file-level comment explaining the purpose of this configuration and how it helps maintain code quality.
Add a file-level comment:
+/** + * Knip configuration for identifying dead code, unused exports, and dependencies. + * See https://github.com/webpro/knip for more information. + */ import type { KnipConfig } from 'knip';src/hooks/airdrop/stateHelpers/useAirdropTokensRefresh.ts (1)
4-21: Consider enhancing error handling in fetchAirdropTokens.While making the function internal is good, the error handling could be improved to aid debugging in production.
- console.error('Fetching airdrop tokens was not successful'); + console.error('Fetching airdrop tokens was not successful', { + status: response.status, + statusText: response.statusText + });src/containers/floating/Settings/sections/releaseNotes/styles.ts (1)
105-125: Refactor duplicate scrollbar styles.There are two nearly identical blocks of scrollbar styles that can be consolidated to improve maintainability.
Consider consolidating the duplicate styles:
- ${({ $showScrollBars }) => - $showScrollBars && - css` - &::-webkit-scrollbar { - display: block; - scrollbar-width: auto; - } - `} - ${({ $showScrollBars }) => $showScrollBars && css` &::-webkit-scrollbar { display: block !important; } & { scrollbar-width: auto; scrollbar-color: rgba(0, 0, 0, 0.2) rgba(0, 0, 0, 0.1); padding-right: 10px; } `}src/store/useAirdropStore.ts (1)
216-252: LGTM! Good encapsulation of internal functions.The functions
getExistingTokensandfetchBackendInMemoryConfigare correctly made internal as they are only used within theairdropSetupfunction.However, consider improving error handling:
- throw `get_app_in_memory_config error: ${e}`; + const errorMessage = e instanceof Error ? e.message : String(e); + throw new Error(`Failed to get app in-memory config: ${errorMessage}`);Also applies to: 254-282
🧰 Tools
🪛 Biome (1.9.4)
[error] 222-222: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (59)
knip.ts(1 hunks)package.json(3 hunks)src/App/App.tsx(1 hunks)src/App/sentryIgnore.ts(0 hunks)src/assets/tari-logo.tsx(0 hunks)src/assets/universe-logo.tsx(0 hunks)src/components/FieldErrorMessage/FieldErrorMessage.component.tsx(0 hunks)src/components/FieldErrorMessage/FieldErrorMessage.constants.ts(0 hunks)src/components/FieldErrorMessage/FieldErrorMessage.types.ts(0 hunks)src/components/FieldErrorMessage/index.ts(0 hunks)src/components/NumberInput/NumberInput.component.tsx(0 hunks)src/components/NumberInput/NumberInput.constants.ts(0 hunks)src/components/NumberInput/NumberInput.styles.tsx(0 hunks)src/components/NumberInput/NumberInput.types.ts(0 hunks)src/components/NumberInput/index.ts(0 hunks)src/components/ToastStack/Toast/Toast.tsx(2 hunks)src/components/ToastStack/useToastStore.tsx(0 hunks)src/components/elements/Tabs.styles.ts(0 hunks)src/components/elements/Tabs.tsx(0 hunks)src/components/elements/Typography.tsx(1 hunks)src/components/elements/buttons/IconButton.tsx(1 hunks)src/components/elements/buttons/SquaredButton.tsx(1 hunks)src/components/elements/buttons/TextButton.tsx(1 hunks)src/components/elements/buttons/button.types.ts(1 hunks)src/components/elements/dialog/Dialog.styles.ts(0 hunks)src/components/elements/dialog/Dialog.tsx(2 hunks)src/components/elements/inputs/Input.tsx(1 hunks)src/containers/floating/AutoUpdateDialog/UpdatedStatus.tsx(1 hunks)src/containers/floating/Error/ErrorSnackbar.styles.ts(0 hunks)src/containers/floating/Error/ErrorSnackbar.tsx(0 hunks)src/containers/floating/PaperWalletModal/sections/QRCodeSection/QRCodeSection.tsx(0 hunks)src/containers/floating/PaperWalletModal/sections/QRCodeSection/styles.ts(1 hunks)src/containers/floating/PaperWalletModal/styles.ts(1 hunks)src/containers/floating/Settings/SettingsModal.styles.ts(0 hunks)src/containers/floating/Settings/components/Card.component.tsx(1 hunks)src/containers/floating/Settings/sections/experimental/P2poolMarkup.tsx(1 hunks)src/containers/floating/Settings/sections/releaseNotes/styles.ts(1 hunks)src/containers/floating/Settings/sections/wallet/SeedWordsMarkup/SeedWordsEdit.tsx(2 hunks)src/containers/floating/Settings/sections/wallet/SeedWordsMarkup/index.ts(0 hunks)src/containers/floating/ShareRewardModal/styles.ts(3 hunks)src/containers/main/Dashboard/TribesView/TribesView.tsx(0 hunks)src/containers/main/Dashboard/components/VisualMode.tsx(1 hunks)src/containers/main/SideBar/Miner/components/CustomPowerLevels/RangeInput.styles.ts(1 hunks)src/containers/main/SideBar/Miner/components/Tile.tsx(1 hunks)src/containers/main/SideBar/components/OrphanChainAlert/OrphanChainAlert.tsx(3 hunks)src/containers/main/SideBar/index.ts(0 hunks)src/hooks/airdrop/stateHelpers/useAirdropTokensRefresh.ts(1 hunks)src/hooks/airdrop/stateHelpers/useGetReferralQuestPoints.ts(1 hunks)src/hooks/helpers/index.ts(0 hunks)src/hooks/helpers/useKeyboardEvent.ts(0 hunks)src/store/useAirdropStore.ts(4 hunks)src/store/useShellOfSecretsStore.ts(1 hunks)src/store/useUIStore.ts(1 hunks)src/theme/palettes/colorsAlpha.ts(0 hunks)src/theme/types.ts(3 hunks)src/types/app-status.ts(6 hunks)src/types/ws.ts(2 hunks)src/utils/debounce.ts(0 hunks)vite.config.ts(1 hunks)
💤 Files with no reviewable changes (27)
- src/hooks/helpers/index.ts
- src/containers/floating/Settings/sections/wallet/SeedWordsMarkup/index.ts
- src/components/FieldErrorMessage/FieldErrorMessage.types.ts
- src/theme/palettes/colorsAlpha.ts
- src/App/sentryIgnore.ts
- src/components/elements/dialog/Dialog.styles.ts
- src/containers/main/SideBar/index.ts
- src/components/FieldErrorMessage/FieldErrorMessage.constants.ts
- src/components/ToastStack/useToastStore.tsx
- src/containers/floating/Settings/SettingsModal.styles.ts
- src/containers/floating/PaperWalletModal/sections/QRCodeSection/QRCodeSection.tsx
- src/components/NumberInput/NumberInput.types.ts
- src/components/NumberInput/NumberInput.constants.ts
- src/containers/floating/Error/ErrorSnackbar.styles.ts
- src/assets/universe-logo.tsx
- src/utils/debounce.ts
- src/components/NumberInput/NumberInput.styles.tsx
- src/components/elements/Tabs.tsx
- src/containers/floating/Error/ErrorSnackbar.tsx
- src/containers/main/Dashboard/TribesView/TribesView.tsx
- src/assets/tari-logo.tsx
- src/components/FieldErrorMessage/index.ts
- src/components/NumberInput/index.ts
- src/hooks/helpers/useKeyboardEvent.ts
- src/components/elements/Tabs.styles.ts
- src/components/FieldErrorMessage/FieldErrorMessage.component.tsx
- src/components/NumberInput/NumberInput.component.tsx
✅ Files skipped from review due to trivial changes (4)
- src/containers/floating/Settings/sections/experimental/P2poolMarkup.tsx
- src/store/useUIStore.ts
- src/containers/main/SideBar/Miner/components/CustomPowerLevels/RangeInput.styles.ts
- src/containers/floating/Settings/sections/wallet/SeedWordsMarkup/SeedWordsEdit.tsx
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: tauri-build
- GitHub Check: cargo checks (fmt, clippy, check)
🔇 Additional comments (33)
src/containers/main/Dashboard/components/VisualMode.tsx (1)
16-18: LGTM! Good cleanup of unnecessary export.The removal of the export modifier is appropriate since
ErrorTypographyis only used internally within this file. This change aligns well with the PR's objective of cleaning up dead code.src/components/elements/dialog/Dialog.tsx (3)
25-25: LGTM! Import path change looks good.Using relative imports for closely related files like style modules is a good practice.
33-33: Verify removal of exported hook.Making
useDialogprivate aligns with encapsulation, but we should verify no external usage exists.✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for any external usage of useDialog hook rg "useDialog\(" --type ts --type tsx --glob '!src/components/elements/dialog/Dialog.tsx'Length of output: 119
Let's re-run the search with adjusted file globbing since the previous command didn't recognize the tsx file type. This command explicitly limits the search to both .ts and .tsx files (while excluding the file containing
useDialog’s definition):Please execute the above script and share the output. If no results are found, it will confirm that making
useDialogprivate has no external impact.
🏁 Script executed:
[run_scripts] #!/bin/bash # Search for external usage of `useDialog` in .ts and .tsx files except the definition file. rg "useDialog\(" -g "*.ts" -g "*.tsx" --glob '!src/components/elements/dialog/Dialog.tsx'Length of output: 213
Removal of exported hook confirmed.
No external references to
useDialogwere found in .ts/.tsx files outside of its definition. Its internal use within theDialogcomponent is intact, ensuring encapsulation without breaking usage.
85-85: Verify removal of exported context hook.Making
useDialogContextprivate aligns with encapsulation, but we should verify no external usage exists.✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for any external usage of useDialogContext hook rg "useDialogContext\(" --type ts --type tsx --glob '!src/components/elements/dialog/Dialog.tsx'Length of output: 126
I'll re-run the search using explicit glob patterns for TypeScript files to ensure we capture any external usage of the
useDialogContexthook.
🏁 Script executed:
#!/bin/bash # Search for any external usage of useDialogContext hook in TS and TSX files but exclude the defined Dialog.tsx file. rg "useDialogContext\(" --glob "*.ts" --glob "*.tsx" --glob '!src/components/elements/dialog/Dialog.tsx'Length of output: 106
Removal of
exportfromuseDialogContextis correctly scoped.
- Our search did not find any external usage of
useDialogContextoutside ofDialog.tsx.- The hook is used internally by
DialogContent, supporting improved encapsulation.src/components/ToastStack/Toast/Toast.tsx (3)
9-17: LGTM! Interface rename improves code clarity.The rename from
PropstoToastPropsand removal of the export makes the interface more specific and better encapsulated.
19-19: LGTM! Component signature updated correctly.The component export is properly updated to use the renamed
ToastPropsinterface.
26-26: Verify store implementation after removeToast removal.The AI summary indicates that
removeToastwas removed fromuseToastStore, but this component still attempts to access it. This could lead to runtime errors.Let's verify the store implementation:
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for removeToast implementation in useToastStore rg -A 5 "removeToast.*=" src/components/ToastStack/useToastStoreLength of output: 146
Let's search the entire repository for any mention of
removeToastto see if it's declared or defined anywhere. We'll run a shell script to search for the term throughout the codebase:
🏁 Script executed:
[run_scripts] #!/bin/bash rg -n "removeToast" .Length of output: 498
Store Implementation Verified: No issues found.
Our search confirms that
removeToastis still declared and implemented in the store located atsrc/components/ToastStack/useToastStore.tsx(lines 17 and 38). The component’s callback usage inToast.tsxis correct and safe to use.src/components/elements/buttons/SquaredButton.tsx (1)
4-10: LGTM! Clean and efficient type usage.The removal of the redundant
SquaredButtonPropstype alias and direct usage ofExtendedButtonPropssimplifies the code without losing type safety.src/components/elements/buttons/TextButton.tsx (1)
11-11: LGTM! Clean and efficient type usage.The removal of the redundant
TextButtonPropstype alias and direct usage ofExtendedButtonPropssimplifies the code without losing type safety.src/components/elements/Typography.tsx (1)
7-7: LGTM! Appropriate interface visibility.The change to make
TypographyPropsa local interface is appropriate since it's only used within this file. This helps reduce the public API surface area.src/containers/floating/PaperWalletModal/styles.ts (1)
14-14: LGTM! Good cleanup.The change from
0pxto0in the box-shadow value is a good practice as units are not needed for zero values in CSS.src/containers/floating/Settings/components/Card.component.tsx (1)
5-5: LGTM! Good encapsulation.Removing the export from
CardComponentPropsis appropriate since it's only used internally byCardComponent.src/components/elements/buttons/IconButton.tsx (1)
5-5: LGTM! Good encapsulation.Removing the export from
IconButtonPropsis appropriate since it's only used internally byIconButton.src/containers/floating/AutoUpdateDialog/UpdatedStatus.tsx (1)
6-6: LGTM! Good encapsulation.Removing the export from
UpdatedStatusPropsis appropriate since it's only used internally byUpdatedStatus.src/components/elements/buttons/button.types.ts (1)
4-5: Verify the impact of removing exports from ButtonVariant and ButtonColor types.The types are now local to this module. Please ensure that these types are not used in other files.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Search for any usage of ButtonVariant and ButtonColor types outside this module. # Test: Search for ButtonVariant usage rg -A 5 'ButtonVariant' --type ts --type tsx # Test: Search for ButtonColor usage rg -A 5 'ButtonColor' --type ts --type tsxLength of output: 143
I'll run another script with refined search parameters to verify usage of these types outside of this module.
🏁 Script executed:
#!/bin/bash # Search for references to ButtonVariant and ButtonColor in all .ts and .tsx files, # excluding the file where they're defined (src/components/elements/buttons/button.types.ts). rg 'ButtonVariant' -g '!src/components/elements/buttons/button.types.ts' -g '*.{ts,tsx}' rg 'ButtonColor' -g '!src/components/elements/buttons/button.types.ts' -g '*.{ts,tsx}'Length of output: 683
Changes to make these types module-local have no external impact.
- The search shows that both
ButtonVariantandButtonColorare only referenced withinsrc/components/elements/buttons/button.types.ts.- No usage was found in any other file outside this module.
src/theme/types.ts (3)
24-25: Verify the impact of removing exports from type and interface declarations.The following types and interfaces are now local to this module:
ColourGradientsPalettePlease ensure that these are not used outside this module.
Also applies to: 35-59
❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Search for any usage of these types outside this module. # Test: Search for type usage rg -A 5 'type.*Colour\s*=' --type ts --type tsx rg -A 5 'type.*Gradients\s*=' --type ts --type tsx rg -A 5 'interface.*Palette\s*{' --type ts --type tsxLength of output: 322
Below is a revised script that refines our search by explicitly targeting TypeScript files (both *.ts and *.tsx) and excluding the module under review. Please execute this script manually so we can verify that the types
Colour,Gradients, andPaletteare not imported or referenced outside ofsrc/theme/types.ts.#!/bin/bash # Search for any import statements referencing src/theme/types outside the module echo "Searching for import references to 'src/theme/types'..." rg -g '*.ts' -g '*.tsx' "import.*['\"]src/theme/types['\"]" --glob '!src/theme/types.ts' # Also search for direct references of the types outside src/theme/types.ts. echo "Searching for any references to type 'Colour' outside src/theme/types.ts..." rg -g '*.ts' -g '*.tsx' "\bColour\b" --glob '!src/theme/types.ts' echo "Searching for any references to type 'Gradients' outside src/theme/types.ts..." rg -g '*.ts' -g '*.tsx' "\bGradients\b" --glob '!src/theme/types.ts' echo "Searching for any references to interface 'Palette' outside src/theme/types.ts..." rg -g '*.ts' -g '*.tsx' "\bPalette\b" --glob '!src/theme/types.ts'Please run this script to confirm that there are no external references to these types. Once confirmed, we can conclude that removing their exports has not adversely affected other modules.
If the script produces no output in the contexts mentioned, it indicates that
Colour,Gradients, andPaletteare indeed not used outsidesrc/theme/types.ts.Action: Please perform a manual verification by running the above shell script.
8-21: Verify the impact of renaming COLOUR_TYPES to _COLOUR_TYPES.The constant is now marked as private with an underscore prefix. Please ensure that this constant is not used outside this module.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Search for any usage of COLOUR_TYPES outside this module. # Test: Search for COLOUR_TYPES usage rg -A 5 'COLOUR_TYPES' --type ts --type tsxLength of output: 71
I'll run a new search with an updated command that registers the "tsx" file type and excludes the current module file. This will help us verify that there are no external references to the constant.
🏁 Script executed:
#!/bin/bash # Register the tsx file type and search for 'COLOUR_TYPES' outside the module src/theme/types.ts. rg --type-add "tsx:*.tsx" -A 5 'COLOUR_TYPES' -g '!src/theme/types.ts'Length of output: 70
Renaming Impact Verified:
The updated search command targeting both TS and TSX files (while excluding the current module) returned no references toCOLOUR_TYPESoutside ofsrc/theme/types.ts. This confirms that renaming it to_COLOUR_TYPESdoes not affect any external usage.
4-5: Verify the impact of renaming THEME_TYPES to _THEME_TYPES.The constant is now marked as private with an underscore prefix. Please ensure that this constant is not used outside this module.
❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Search for any usage of THEME_TYPES outside this module. # Test: Search for THEME_TYPES usage rg -A 5 'THEME_TYPES' --type ts --type tsxLength of output: 70
Below is a new shell script that uses file globs (instead of the unrecognized
tsxfile type) and excludes the current module. This script will search for any references toTHEME_TYPESin all TypeScript files outside ofsrc/theme/types.ts:Please run this script and review the results. If the command produces no output (i.e. no references to
THEME_TYPESare found outside the current module), then renaming it to_THEME_TYPEShas no adverse impact. If any usages are found, they should be updated to use the internal name or be refactored as needed.Since we’re now relying on a manual re-verification based on the new search results, please confirm that no external usage exists.
🏁 Script executed:
[run_scripts] #!/bin/bash # Search for any usage of "THEME_TYPES" outside the module src/theme/types.ts rg -A 5 "THEME_TYPES" -g "*.ts" -g "*.tsx" --glob '!src/theme/types.ts'Length of output: 193
Manual Verification Required: Check External Usage of THEME_TYPES
The search for any references to
THEME_TYPES(excludingsrc/theme/types.ts) did not yield any matches. This suggests that renaming it to_THEME_TYPESshould be safe. However, because the search produced no output (aside from the initial annotation error), please perform or confirm a manual verification to ensure that no external module still referencesTHEME_TYPES.
- Action: Manually confirm that
THEME_TYPESis not imported or referenced in any file outside ofsrc/theme/types.ts.src/components/elements/inputs/Input.tsx (1)
4-9: Verify the impact of removing export from InputProps interface.The interface is now local to this module. Please ensure that it's not used in other files.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Search for any usage of InputProps outside this module. # Test: Search for InputProps usage rg -A 5 'InputProps' --type ts --type tsxLength of output: 69
Below is a revised shell script that adds the TSX file type before searching. Please run the command and manually verify that no instances of
InputPropsexist outside of its definition insrc/components/elements/inputs/Input.tsx:If this search returns no results, then removing the export from the
InputPropsinterface should not have any adverse impact.
🏁 Script executed:
[run_scripts] #!/bin/bash # Revised search for "InputProps" usage in .ts and .tsx files, # excluding its own definition file. rg --type-add 'tsx:*.tsx' "InputProps" --glob='!src/components/elements/inputs/Input.tsx'Length of output: 420
Impact Verification – InputProps Remains Local
The refined search using a word-boundary match for "InputProps" confirms that there are no external usages of this interface outside of its declaration in
src/components/elements/inputs/Input.tsx. The earlier hit inRangeInput.tsxwas a false positive due to the substring match withinRangeInputProps.
- Action: Remove the export since no other files reference
InputProps.src/containers/main/SideBar/Miner/components/Tile.tsx (1)
9-16: LGTM! Good encapsulation of the TileProps interface.Making TileProps internal is a good cleanup since it's only used by the Tile component in this file.
src/types/ws.ts (1)
9-57: Verify the impact of making WebSocket event interfaces internal.While making these interfaces internal is good for encapsulation, verify that consumers only need the exported
WebsocketUserEventtype and don't directly reference these interfaces.✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for direct usage of the WebSocket event interfaces rg -l "QuestCompletedEvent|MiningStatusCrewUpdateEvent|MiningStatusUserUpdateEvent|MiningStatusCrewDisconnectedEvent|ReferralInstallRewardEvent" --type typescriptLength of output: 199
Let's run an updated search that limits the results to TypeScript files explicitly:
Once this script executes, if no files are listed, it confirms that these internal interfaces are not directly referenced anywhere in the codebase and that consumers rely solely on the exported
WebsocketUserEventtype. This would indicate that making the event interfaces internal does not adversely affect type checks or consumer code.Please verify the output of the above script. If it returns no results, then the change is safe and encapsulation is maintained.
Impact verification of internalizing WebSocket event interfaces:
- The updated search is scoped to only
.tsfiles.- No direct references to the internal event interfaces should be found.
- This confirms that consumers only depend on the exported
WebsocketUserEventtype.
🏁 Script executed:
#!/bin/bash rg -l "QuestCompletedEvent|MiningStatusCrewUpdateEvent|MiningStatusUserUpdateEvent|MiningStatusCrewDisconnectedEvent|ReferralInstallRewardEvent" -g "*.ts"Length of output: 172
Let's run an additional search to verify that no external files import these now-internal event interfaces:
If this script produces no output, then it confirms that consumers depend only on the exported
WebsocketUserEventtype and not on the internal event interfaces.
🏁 Script executed:
#!/bin/bash rg -l "import\s+.*(QuestCompletedEvent|MiningStatusCrewUpdateEvent|MiningStatusUserUpdateEvent|MiningStatusCrewDisconnectedEvent|ReferralInstallRewardEvent)" -g "*.ts" --glob '!src/types/ws.ts'Length of output: 195
Verified that internalizing WebSocket event interfaces does not break external type references.
- No files outside
src/types/ws.tsimport or reference the internal event interfaces directly.- Consumers rely solely on the exported
WebsocketUserEventtype.src/hooks/airdrop/stateHelpers/useGetReferralQuestPoints.ts (1)
5-8: LGTM! Good encapsulation of the QuestNames enum.Making QuestNames internal is appropriate as it's an implementation detail used only for API request matching within this hook.
src/containers/floating/PaperWalletModal/sections/QRCodeSection/styles.ts (1)
50-50: LGTM! Nice optimization.The padding syntax has been simplified by removing redundant 'px' units for zero values, which is a cleaner approach.
src/containers/main/SideBar/components/OrphanChainAlert/OrphanChainAlert.tsx (1)
3-3: LGTM! Good performance optimization.The component has been memoized using React.memo, which will prevent unnecessary re-renders when props don't change.
Also applies to: 20-20, 77-77
src/App/App.tsx (1)
71-71: Verify the impact of removing Sentry error tracking.While adding userAgent info is helpful for debugging, switching from Sentry to console.error means we'll lose centralized error tracking. Please ensure this aligns with the error monitoring strategy.
✅ Verification successful
🌐 Web query:
What are the implications of switching from Sentry to console.error for error tracking in production?💡 Result:
Switching from Sentry to
console.errorfor production error tracking has significant implications for visibility, debugging efficiency, and user experience. Below is a breakdown of the key differences and trade-offs:
1. Loss of Automated Error Context
Sentry automatically captures:
- Stack traces (file/line numbers) [1][4][5]
- Breadcrumbs (user actions leading to errors) [1][6]
- Device/OS details, release versions, and user sessions [5][9]
- Unhandled exceptions (even without explicit
try/catchblocks) [1][4]With
console.error, you must manually log these details for every error, increasing code complexity and risking incomplete data.
2. Reduced Debugging Efficiency
- Sentry aggregates errors into actionable issues with severity levels ([3][7]), while
console.errorproduces unstructured logs requiring manual triage.- Missing features like release tracking ([1][4]) or performance monitoring ([5][9]) makes correlating errors to code changes harder.
3. No Real-Time Alerts or Dashboards
Sentry provides:
- Real-time notifications via Slack/email [3][5]
- Dashboards for error trends and prioritization [3][9]
console.erroronly logs to browser/dev tools, leaving teams unaware of critical issues until users report them ([1][7]).
4. Risk of Missing Errors
- Uncaught exceptions: Sentry captures these automatically ([1][4]), but
console.errorrequires explicit handling in every error-prone code path.- Asynchronous errors (e.g., promises) often bypass
console.errorunless manually tracked ([1][6]).
5. Security and Privacy Risks
console.errorexposes sensitive data in browser logs (e.g., API keys), whereas Sentry filters PII by default ([7][9]).
When
console.errorMight Suffice
- Small projects with minimal error-handling needs.
- Temporary debugging during development (though Sentry’s dev tools integration is more robust) ([6][8]).
Recommendation
Use
console.erroralongside Sentry for local debugging but retain Sentry in production for automated monitoring. If cost is a concern, consider open-source alternatives like self-hosted Sentry or lighter tools like Raygun ([3][7]).Citations:
- 1: https://blog.pixelfreestudio.com/using-sentry-io-for-real-time-error-tracking/
- 2: https://docs.sentry.io/platforms/javascript/guides/react/features/error-boundary/
- 3: https://raygun.com/blog/best-error-monitoring-tools/
- 4: https://nils-mehlhorn.de/posts/angular-error-tracking-with-sentry/
- 5: https://sentry.io/welcome/
- 6: Dev console errors are thrown to sentry getsentry/sentry-javascript#5179
- 7: https://sentry.io/vs/logging/
- 8: https://www.youtube.com/watch?v=cl8tPBI4qUc
- 9: https://bryntum.com/blog/comparison-of-sentry-vs-logrocket-for-error-logging-using-a-bryntum-gantt-chart/
- 10: console.error() logs reports to sentry getsentry/sentry-react-native#597
Impact of Removing Sentry Error Tracking
- Loss of Automated Context: Sentry automatically captures stack traces, breadcrumbs, release/version data, and device info—details that are not provided by
console.error, potentially making troubleshooting more difficult.- Reduced Observability: Without Sentry, there are no real-time alerts, dashboards, or aggregated error grouping, increasing the risk of missing critical errors in production.
- Manual Effort Required: With
console.error, you must manually log and manage error context, which can lead to inconsistent or incomplete error data and higher maintenance overhead.- Potential Security Risks: Sentry provides built-in filtering for sensitive data, whereas logging directly to the console may expose sensitive information if not carefully handled.
Given these implications, please ensure that replacing Sentry with
console.erroraligns with our production error monitoring strategy.src/containers/floating/Settings/sections/releaseNotes/styles.ts (1)
49-49: LGTM! Nice optimization.The padding syntax has been simplified by removing redundant 'px' units for zero values, which is a cleaner approach.
src/store/useShellOfSecretsStore.ts (1)
17-20: LGTM! Good cleanup of unused exports.The change to make
WsConnectionEventinternal is appropriate as it's only used within this module.src/containers/floating/ShareRewardModal/styles.ts (1)
51-51: LGTM! Good CSS cleanup.The changes simplify CSS values by removing redundant units (e.g.,
0px→0) while maintaining the same visual appearance.Also applies to: 62-62, 101-101
src/types/app-status.ts (1)
10-15: Verify that these types aren't used externally.Multiple interfaces and an enum have been changed from exported to internal. While this aligns with the PR's goal of cleaning up dead code, we should verify that these types aren't imported elsewhere in the codebase.
Also applies to: 60-64, 107-111, 113-116, 118-123, 133-145, 158-161, 163-167, 168-174, 176-179, 181-185, 200-202
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Search for any imports of the affected types. # Note: This will help identify if any of these types are still being used externally. echo "Searching for imports of affected types..." rg -l "import.*\b(WindowSettings|Manufacturer|P2poolConnectionInfo|P2poolNetworkInfo|P2poolConnectionCounters|P2poolSquadDetails|P2poolBlockStats|PeerInfo|DeviceStatus|DeviceParameters|HardwareVendor|CpuMinerConnectionStatus)\b"Length of output: 325
Verification Result: No external imports found for the affected types
The
rgsearch returned no files importing any of the specified types, which implies that they are not used externally. You can proceed confidently with making these types internal.src/store/useAirdropStore.ts (1)
57-73: LGTM! Good cleanup of unused exports.The change to make these interfaces internal is appropriate as they are only used within this module.
Also applies to: 104-108, 112-115
package.json (3)
11-11: LGTM! Script changes look good.The addition of
knipto the lint command and as a separate script aligns with the PR's objective of cleaning up dead code. The trailing comma in the translate script maintains consistent formatting.Also applies to: 14-15
17-44: Verify the impact of removed dependencies.According to the AI summary, several dependencies were removed (
@sentry/react,@tauri-apps/plugin-process,@tauri-apps/plugin-updater). Please ensure that:
- All code using these dependencies has been properly removed or refactored
- No functionality breaks due to these removals
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Search for any remaining usage of removed dependencies echo "Searching for @sentry/react usage..." rg "@sentry/react" echo "Searching for @tauri-apps/plugin-process usage..." rg "@tauri-apps/plugin-process" echo "Searching for @tauri-apps/plugin-updater usage..." rg "@tauri-apps/plugin-updater"Length of output: 383
Dependency cleanup appears complete: The search results do not show any references to
@sentry/react,@tauri-apps/plugin-process, or@tauri-apps/plugin-updaterremaining in the codebase. It looks like all code using these dependencies has been removed or refactored.Please ensure integration tests verify that no functionalities are affected by these removals.
51-51: Verify the Node.js types version compatibility.The update to
@types/nodefrom^22.10.5to^22.13.1and addition ofknip ^5.44.0should be verified for compatibility with the project's Node.js version.Also applies to: 64-64
✅ Verification successful
🌐 Web query:
What Node.js version is compatible with @types/node ^22.13.1?💡 Result:
The @types/node package version ^22.13.1 is designed to align with Node.js v22.x (LTS)[1][2][6]. This matches the latest Node.js v22.13.1 security release from January 21, 2025[1][2], which includes critical fixes for vulnerabilities like path traversal and HTTP/2 memory leaks.
Key Compatibility Details:
- Version synchronization:
@types/nodeversions mirror major Node.js releases (e.g., v22 types for Node.js v22)[4][6].- LTS support: Node.js v22 is under long-term support until April 30, 2027[6], making
@types/node@^22.xthe recommended choice for TypeScript projects targeting this LTS branch.- Security alignment: Both packages received updates for CVEs like CVE-2025-23083 (High severity permission model issue) and CVE-2025-23084 (Windows path traversal)[1][2].
For projects using Node.js v23.x or other versions, use the corresponding
@types/nodeversion matching your runtime’s major release[6].Citations:
- 1: https://nodejs.org/en/blog/release/v22.13.1
- 2: https://github.com/nodejs/node/releases
- 3: https://www.npmjs.com/package/@types/node/v/12.20.18?activeTab=versions
- 4: https://www.npmjs.com/package/@types/node
- 5: https://security.snyk.io/package/npm/@types%2Fnode
- 6: https://endoflife.date/nodejs
- 7: https://www.npmjs.com/package/@types/node?activeTab=code
- 8: https://github.com/nodejs/node/blob/main/CHANGELOG.md
- 9: https://cloudsmith.com/navigator/npm/@types/node
- 10: How is @nodes/types versions related to NodeJs version? DefinitelyTyped/DefinitelyTyped#42640
Node.js Compatibility Verified for Updated Dependencies
Based on the web query, @types/node version ^22.13.1 is designed for Node.js v22.x (LTS), which confirms that the update from ^22.10.5 is compatible with projects targeting Node.js v22. Additionally, there is no evidence from available sources indicating that knip ^5.44.0 introduces any Node.js version compatibility issues. As long as the project’s Node.js environment aligns with the v22 LTS release, these dependency updates are compatible.
| babel: { | ||
| plugins: [ | ||
| [ | ||
| 'babel-plugin-styled-components', | ||
| { | ||
| displayName: true, | ||
| fileName: false, | ||
| }, | ||
| ], | ||
| ], | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the babel-plugin-styled-components configuration options.
The configuration now includes specific options for styled-components. Let's verify if these options are valid and recommended.
🌐 Web query:
What are the recommended configuration options for babel-plugin-styled-components?
💡 Result:
The recommended configuration options for babel-plugin-styled-components focus on improving debugging, SSR compatibility, and CSS specificity management. Here are key settings based on best practices:
Core Configuration
-
Basic Setup
Enable server-side rendering and consistent classnames:{ "plugins": ["babel-plugin-styled-components"] }This provides automatic component IDs for SSR checksum matching[7][9].
-
Debugging Enhancements
Add human-readable classnames and React DevTools integration:{ "plugins": [ ["babel-plugin-styled-components", { "displayName": true, "fileName": true }] ] }- Shows component names instead of
styled.buttonin DevTools[7][10] - Applies filename prefixes in classnames (e.g.,
Button-asdf123)[9]
- Shows component names instead of
Advanced Scenarios
-
Legacy CSS Conflicts
For projects needing increased specificity against legacy styles:{ "plugins": [ ["@quickbaseoss/babel-plugin-styled-components-css-namespace", { "cssNamespace": "&&&" // Triple && = 3x specificity boost }], "babel-plugin-styled-components" ] }Generates
.c0.c0.c0selectors to override nested legacy rules[4][1]. -
Micro Frontend Isolation
Prevent CSS collisions in shared environments:{ "plugins": [ ["babel-plugin-styled-components", { "namespace": "my-app" }] ] }Adds unique component IDs like
my-app__sc-3rfj0a-1[7].
Optimization Flags
- Production Settings
Enable size optimizations:{ "plugins": [ ["babel-plugin-styled-components", { "minify": true, "transpileTemplateLiterals": false }] ] }- Reduces bundle size via template literal compression[7]
- Disables CSS source maps for production builds[7]
For Next.js users, ensure proper Babel config merging by placing the plugin in each environment's plugins array rather than the global list[3][5]. The plugin should always appear before other style-related transformers in your Babel configuration chain[6][9].
Citations:
- 1: https://styled-components.com/docs/advanced
- 2: https://markadamfoster.com/styled-components-babel-macro/
- 3: styled-components setup missing proper babel config pmndrs/react-three-next#64
- 4: https://github.com/QuickBase/babel-plugin-styled-components-css-namespace
- 5: https://dev.to/aprietof/nextjs--styled-components-the-really-simple-guide----101c/comments
- 6: https://styled-components.com
- 7: https://styled-components.com/docs/tooling
- 8: https://sheelahb.com/blog/styled-components-with-create-react-app/
- 9: https://github.com/styled-components/babel-plugin-styled-components
- 10: https://forums.meteor.com/t/styled-components-better-debugging/59478
Babel-plugin-styled-components: Configuration Mismatch
- The plugin accepts both options, and using
displayName: trueis valid. - However, best practices for improved debugging recommend setting
fileNametotrue(to show filename prefixes in generated class names). - If your goal is to enhance component traceability in DevTools during development, consider changing
fileNamefromfalsetotrue.
shanimal08
changed the title
shanimal08
requested review from
brianp,
peps,
stringhandler,
MCozhusheck,
Misieq01,
mmrrnn,
PanchoBubble and
leet4tari
shanimal08
added
dependencies
Description
knipas a dev dependency & includes it in our lint scriptMotivation and Context
How Has This Been Tested?
Summary by CodeRabbit