Create status page PR2 #1494
Create status page PR2 #1494
Conversation
- Create CreateStatus page -WIP
- WIP logo uploading in general settings tab
- Implemented drag and drop for the server list section
- Add the rest of content panel UI layouts - Update the card value with onChange
- Fix the warning possible change from uncontrolled to controlled component
- Make static status page and actual status config page toggleable - Remove the sidebar nested menu item entry for status page tabs - Pass context to status config page which contains general settings and contents tabs - Status config page is now one submission and one validation
- Change layout to use the one that has vertical line - Update name to CreateStatusContext instead of TabContext to make it clearer - Handle errors to land on the respective page tab
- Switch to active tab when there are errors on it upon submission - Add createStatusPage function - Updated JSDOC for functions
- Replace Text input with Search component - Extend Search component to accept start and end adorment
…cept the fields that currently does not have BE counterparts, including all checkboxes and uploaded logo
![llamapreview[bot]](https://avatars.githubusercontent.com/in/1023541?s=60&v=4){kind=small}
There was a problem hiding this comment.
Auto Pull Request Review from LlamaPReview
Large PR Notification
Dear contributor,
Thank you for your substantial contribution to this project. LlamaPReview has detected that this Pull Request contains a large volume of changes, which exceeds our current processing capacity.
Details:
- PR and related contents total size: Approximately 74,552 characters
- Current limit: 50,000 characters
Next steps:
- Consider breaking this PR into smaller, more focused changes if possible.
- For manual review, please reach out to your team members or maintainers.
We appreciate your understanding and commitment to improving this project. Your contributions are valuable, and we want to ensure they receive the attention they deserve.
LlamaPReview is continuously evolving to better serve the community. Share your thoughts on handling large PRs in our GitHub Discussions - your feedback helps us improve and expand our capabilities.
If you have any questions or need assistance, our community and support team are here to help.
Best regards,
LlamaPReview Team
WalkthroughThe pull request introduces comprehensive enhancements to the client-side application, focusing on creating a new status page feature. The changes span multiple components and utilities, adding drag-and-drop functionality, new input components, context management, and network service methods. Key additions include a status page creation workflow, improved form validation, and more flexible UI components. Changes
Sequence DiagramsequenceDiagram
participant User
participant CreateStatus
participant StatusFormContext
participant NetworkService
participant ValidationService
User->>CreateStatus: Navigate to status page creation
CreateStatus->>StatusFormContext: Initialize form state
User->>CreateStatus: Fill out general settings
CreateStatus->>ValidationService: Validate form data
ValidationService-->>CreateStatus: Validation result
CreateStatus->>NetworkService: Submit status page configuration
NetworkService-->>CreateStatus: Response with created status page
CreateStatus->>User: Display success/error message
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (17)
Client/src/Components/TabPanels/Status/Card/Server/index.jsx (2)
16-19: Consider resetting the search input upon selection
It may be courteous to clear thesearchstate after the user selects an option, thus maintaining a fresh start for subsequent searches.
25-25: Ensure consistent fallback formonitors
Usingmonitors ? monitors : []is fine, but consider providing a user-friendly message or disabling theSearchcomponent gracefully if no monitors are present.Client/src/Components/Inputs/TextInput/Adornments/index.jsx (1)
78-102: Set up a confirmation prompt for server removal
Accidental clicks on the delete icon might occur. Consider a small confirmation before invokingremoveItemto keep folks from unexpectedly losing their servers.Client/src/Components/Inputs/Search/index.jsx (2)
71-72: Optional chaining might simplify your onChange logic
Using optional chaining could help avoid runtime errors if the event object orhandleChangeis sometimes undefined.🧰 Tools
🪛 Biome (1.9.4)
[error] 72-72: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
94-100: Consolidate input adornments
When specifying bothisAdornedand custom props (startAdornment,endAdornment), the logic can be streamlined by merging them into a single approach to keep the code simpler.Client/src/Pages/Status/index.jsx (2)
26-28: Optional Chaining Could Simplify
Currently checkingif (res && res.data), but you could rockres?.datato tighten the flow and avoid potential null pointer issues.- if(res && res.data) + if (res?.data)🧰 Tools
🪛 Biome (1.9.4)
[error] 27-27: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
38-82: Fallback Layout Looks Great, Consider Loading States
The fallback approach is dope, but if data fetching is slow, a loading indicator might be friendlier than a sudden jump. Something like an interim spinner could keep the vibe while data arrives.Client/src/Validation/error.js (1)
13-13: Consider Strict Equality
Using==might lead to some edge cases. Consider===for any unexpected type mismatches.-if (error && id == error.details[0].path) { +if (error && id === error.details[0].path) {Client/src/Components/Inputs/Checkbox/index.jsx (2)
24-24: Add usage details in the JSDoc for clarity
This JSDoc line includes thealignSelfparam, but it could benefit from an additional usage example to show how the property affects layout.
63-63: Neat ternary usage
Using a simple ternary to conditionally applyalignSelf: "flex-start"keeps the styling concise and tidy.Client/src/Routes/index.jsx (1)
101-105: Route definition clarity
The newstatus/createroute appears well-defined. Consider adding a note in your docs or README to clarify how this route fits into the overall workflow.Client/src/Components/Inputs/Image/index.jsx (1)
122-122: Maintaining design consistency
Adding spacing around the "Supported formats" text is user-friendly and visually neat.Client/src/Pages/Status/CreateStatus/index.jsx (1)
94-101: Add additional error handling.
Whenres.statusis not 200, you throw an error, but consider also checking forres.okor particular fields in the response body to handle partial success or more explanatory error states.Client/src/Components/TabPanels/Status/ContentPanel.jsx (1)
36-38: Surface the “no monitors” condition more explicitly.
You are setting an error in the form state if no monitors exist, but you might also consider gracefully disabling certain UI elements or providing a user-friendly notice in the UI.Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx (1)
165-176: Simplify boolean expressions to prevent unnecessary ternaries.
Avoid usingcondition ? true : false; you can directly pass the condition as a boolean for clarity and maintainability.- helperText={errors["companyName"]} - error={errors["companyName"] ? true : false} + helperText={errors.companyName} + error={!!errors.companyName}- helperText={errors["url"]} - error={errors["url"] ? true : false} + helperText={errors.url} + error={!!errors.url}🧰 Tools
🪛 Biome (1.9.4)
[error] 165-165: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with(lint/complexity/noUselessTernary)
[error] 176-176: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with(lint/complexity/noUselessTernary)
Client/src/Validation/validation.js (1)
138-151: Yo, keep that style in check!
Your pixel-based size limit is legit, but it might be confusing to pass file dimension data into asizefield. Consider adding clarifying doc or name changes so future devs know it's about pixel constraints, not bytes.Client/src/Utils/NetworkService.js (1)
860-868: Slam dunk on the POST method!
createStatusPageflows nice. Just ensure data is validated before you pass it along, so no shady payload causes your app to meltdown.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (23)
Client/package.json(1 hunks)Client/src/App.jsx(1 hunks)Client/src/Components/Inputs/Checkbox/index.jsx(5 hunks)Client/src/Components/Inputs/Image/index.jsx(9 hunks)Client/src/Components/Inputs/Search/index.jsx(4 hunks)Client/src/Components/Inputs/TextInput/Adornments/index.jsx(3 hunks)Client/src/Components/ProgressBars/index.jsx(1 hunks)Client/src/Components/Sidebar/index.jsx(2 hunks)Client/src/Components/TabPanels/Status/Card/ItemTypes.js(1 hunks)Client/src/Components/TabPanels/Status/Card/Server/index.jsx(1 hunks)Client/src/Components/TabPanels/Status/Card/index.jsx(1 hunks)Client/src/Components/TabPanels/Status/ContentPanel.jsx(1 hunks)Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx(1 hunks)Client/src/Pages/Maintenance/CreateMaintenance/index.jsx(1 hunks)Client/src/Pages/Status/CreateStatus/index.jsx(1 hunks)Client/src/Pages/Status/CreateStatusContext/index.jsx(1 hunks)Client/src/Pages/Status/index.jsx(1 hunks)Client/src/Routes/index.jsx(2 hunks)Client/src/Utils/NetworkService.js(1 hunks)Client/src/Utils/stringUtils.js(1 hunks)Client/src/Validation/error.js(4 hunks)Client/src/Validation/validation.js(2 hunks)Client/src/main.jsx(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- Client/src/Components/TabPanels/Status/Card/ItemTypes.js
🧰 Additional context used
🪛 Biome (1.9.4)
Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx
[error] 165-165: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
[error] 176-176: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
Client/src/Components/Inputs/Search/index.jsx
[error] 72-72: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
Client/src/Pages/Status/index.jsx
[error] 27-27: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
Client/src/Pages/Status/CreateStatus/index.jsx
[error] 71-71: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
🔇 Additional comments (39)
Client/src/Utils/stringUtils.js (1)
25-36: Solid helper function, no noticeable code spaghetti!
His palms are sweaty, knees weak, arms are heavy, but no need to fret: the logic in toLowerCaseFirstLetter is on point. It mirrors the approach used in capitalizeFirstLetter, effectively handles null/undefined inputs, and ensures the first character is lowercased without throwing code confetti everywhere.
Client/src/Components/TabPanels/Status/Card/Server/index.jsx (1)
29-35: Check accessibility for icon buttons
Users with assistive technologies might appreciate a more descriptive label or tooltip for the ServerEndAdornment and ServerStartAdornment icons.
Client/src/Components/Inputs/TextInput/Adornments/index.jsx (1)
70-76: Mind the reordering icon’s colour contrast
The reordering icon (ReorderRoundedIcon) should be tested with high-contrast themes to ensure accessibility for all users.
Client/src/Pages/Status/index.jsx (2)
3-9: No Concerns with the New Imports
They look smooth like a fresh verse—no conflicts, no extraneous references, just proper modules lined up ready to spin.
11-15: Documentation Flow Is On Point
The explanation clarifies the purpose well, shining like stage lights on performance night. Keep those comments crisp and updated.
Client/src/Pages/Status/CreateStatusContext/index.jsx (3)
3-8: Context Default Values Are Clear
Props to you for enumerating default keys neatly. This foundation avoids undefined shenanigans when the mic drops.
10-16: Provider Composition Is Solid
Providing form, errors, and updaters in one spot lays a clean track for child components to jam. Keep it consistent across the app.
18-18: Exports Organized
Exporting both context and provider fosters reusability in other flows. No shaky knees detected here.
Client/src/main.jsx (1)
9-10: Drag-and-Drop Is Seamless
Integrating react-dnd with HTML5Backend is done correctly. Users can now move items around with ease, and the code flow respects best practices for the library. Drop the mic on this neat addition!
Also applies to: 22-24
Client/src/App.jsx (1)
15-15: CreateStatus Import
You’re importing CreateStatus, likely for routes or future expansions. Your approach is good—no collisions or random references.
Client/src/Validation/error.js (3)
1-8: Concise Documentation
You’ve explained how buildErrors handles validations with brevity. Keep it sharper than a fresh hook so folks comprehend at a glance.
69-72: Exclusion List Is Thorough
Looks like you’re skipping known fields. Keep it that way to avoid extra validation noise. This is as tight as a strong chorus.
99-99: Proper Error Reset
Setting setErrors({}); when all is good ensures clarity. Great way to free your code from leftover custom errors.
Client/src/Components/Inputs/Checkbox/index.jsx (4)
46-46: Confirm example property usage
Ensure the example code snippet here truly demonstrates passing alignSelf as a prop correctly.
58-58: New prop integrated successfully
The alignSelf prop has been correctly declared; this looks good.
82-82: Spread operator approach
Spreading override into your sx object is both flexible and maintainable. Great practice.
121-121: PropTypes properly updated
The addition of alignSelf to PropTypes helps keep your component’s contract explicit.
Client/src/Components/TabPanels/Status/Card/index.jsx (1)
1-109: Drag-and-drop logic validation
Your drag-and-drop implementation using useDrag and useDrop is coherent. However, consider verifying whether the item’s index is always valid when swapping positions. In extremely large lists, you might need additional checks to prevent out-of-bound movements.
Client/src/Routes/index.jsx (1)
30-30: New import for CreateStatus
Importing CreateStatus is clear and straightforward; no issues spotted.
Client/src/Components/Inputs/Image/index.jsx (9)
18-18: Default prop
Providing a default true value for isRound is a reasonable approach. Nicely done.
20-21: Styled conditionals
Switching border colour to error red if error is set, and toggling roundness based on isRound, handles design and validation states elegantly.
35-35: Check for valid image
The checkImage function helps avoid trying to render invalid images, preventing console errors or broken UI elements.
53-53: Error border style chaining
Merging error_border_style with other styles looks consistent. Good approach to keep the code clean.
70-70: Increased z-index
This ensures that the file input is accessible above other elements. Works well for user interactions.
87-87: Layer ordering
Maintaining separate z-indices for the input field and placeholder text helps keep the UI easy to navigate.
131-143: Error message display
Conditionally showing the error text is a great UX decision. Ensures you only present the user with relevant feedback.
157-157: Round shape logic
The usage of ...roundShape for effortless shape toggling is a nice pattern. Keeps the code DRY.
170-170: PropTypes alignment
Specifying isRound as a bool matches the usage. Clean and consistent.
Client/src/Components/ProgressBars/index.jsx (1)
172-172: Consider verifying that optional labels won't adversely affect UX.
Now that “label” is optional, you might want to confirm no breakage occurs when the consumer omits it. Validate usage scenarios to ensure the UI remains coherent without the label.
Client/src/Pages/Status/CreateStatus/index.jsx (1)
27-32: Confirm that the teamId is always defined before calling getMonitorsByTeamId.
If user.teamId is undefined, the request will fail. A quick conditional check or fallback value will prevent runtime issues.
Client/src/Components/TabPanels/Status/ContentPanel.jsx (1)
71-92: Validate the monitor assignment logic.
Within handleCardChange, ensure that the logic to match an existing card by ID is robust, especially if IDs are randomly generated. This mitigates risks of collisions or unintentional overwrites.
Client/src/Validation/validation.js (2)
153-170: No sweat here, you’re on a roll!
Your public page validation hits the mark, but watch out if you plan on validating the actual URL format. You might benefit from adding a stricter URL pattern or reusing the existing monitorValidation approach for consistency.
285-286: Clean exports, big ups to that!
These new exports look good to go.
Client/src/Pages/Maintenance/CreateMaintenance/index.jsx (1)
184-184: Smooth pivot, but watch for synergy!
Changing the first param to _ for handleSelectMonitors is nice if it’s truly unneeded. Just be sure any callers supply the correct arguments, or else your code might freeze like palms sweaty, mom’s spaghetti.
Client/src/Components/Sidebar/index.jsx (2)
46-46: New icon, fresh look!
Importing StatusPages gives your sidebar some extra sauce. That’s one small step for code, one giant leap for navigation.
56-57: Slick addition, no meltdown!
Listing “Status pages” in the menu is a bold move to help folks find the new feature. Good hustle.
Client/src/Utils/NetworkService.js (1)
850-858: Double-check your naming and security game!
getStatusPageByUrl is a clean approach, but watch out for any potential injection or fuzz in the url. Keep them endpoints safe, so you’re not puking code on your sweater.
Client/package.json (2)
26-26: Yo dawg, this immutability-helper addition is straight fire! 🔥
The immutability-helper package is perfect for handling state updates in a clean way, especially with the drag-and-drop feature you're building. Version 3.1.1 is solid.
30-31: Mom's spaghetti moment: These react-dnd deps are exactly what we need! 🍝
The react-dnd (v16.0.1) and its HTML5 backend are the dynamic duo for implementing drag-and-drop functionality. The matching versions show you've got your dependencies organized.
However, let's verify the integration is complete:
✅ Verification successful
Yo, the drag-n-drop setup is cookin' perfectly! 🍝
Knees weak with excitement 'cause the implementation is rock solid:
DndProviderwithHTML5Backendis properly wrapped aroundAppinmain.jsx- Card component is using both
useDraganduseDrophooks with proper item types - The drag-drop logic is implemented for card reordering with index tracking
This spaghetti is ready to be served - the integration is complete and properly structured!
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify DndProvider setup and usage
# Check if DndProvider is properly set up in the main app
rg -l "DndProvider.*HTML5Backend" --type jsx
# Look for drag-drop hook usage
rg -l "useDrag|useDrop" --type jsx
Length of output: 139
Script:
#!/bin/bash
# Let's try with different file extensions since jsx wasn't recognized
# Check for DndProvider setup
echo "Checking for DndProvider setup..."
rg -l "DndProvider.*HTML5Backend" --type ts --type js --type tsx
# Look for drag-drop hook usage
echo "Checking for drag-drop hooks..."
rg -l "useDrag|useDrop" --type ts --type js --type tsx
# Let's also check for any imports of these packages
echo "Checking for react-dnd imports..."
rg -l "from ['|\"]react-dnd" --type ts --type js --type tsx
rg -l "from ['|\"]react-dnd-html5-backend" --type ts --type js --type tsx
Length of output: 604
Script:
#!/bin/bash
# Let's try without file type restrictions since they're not recognized
echo "Checking for DndProvider setup..."
rg -l "DndProvider.*HTML5Backend"
echo "Checking for drag-drop hooks..."
rg -l "useDrag|useDrop"
echo "Checking for react-dnd imports..."
rg -l "from ['\"]react-dnd"
rg -l "from ['\"]react-dnd-html5-backend"
# Also check for require statements just in case
echo "Checking for require statements..."
rg -l "require\(['\"]react-dnd"
rg -l "require\(['\"]react-dnd-html5-backend"
Length of output: 699
Script:
#!/bin/bash
# Let's check the actual implementation to ensure it's properly set up
echo "Checking DndProvider setup in main.jsx..."
rg "DndProvider" Client/src/main.jsx -C 2
echo "Checking drag-drop implementation in Card component..."
rg "useDrag|useDrop" Client/src/Components/TabPanels/Status/Card/index.jsx -C 2
Length of output: 1252
| @@ -11,11 +11,15 @@ import { checkImage } from "../../../Utils/fileUtils"; | |||
| * @param {string} props.id - The unique identifier for the input field. | |||
| * @param {string} props.src - The URL of the image to display. | |||
| * @param {function} props.onChange - The function to handle file input change. | |||
| * @param {string} props.isRound - The shape of the image to display. | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Possible JSDoc mismatch
This line's documentation calls isRound a string, but it is declared and used as a boolean. Updating the JSDoc to reflect a boolean type prevents confusion.
- * @param {string} props.isRound - The shape of the image to display.
+ * @param {boolean} props.isRound - The shape of the image to display.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * @param {string} props.isRound - The shape of the image to display. | |
| * @param {boolean} props.isRound - The shape of the image to display. |
| const handleSubmit = async (e) => { | ||
| e.preventDefault(); | ||
| //validate rest of the form | ||
| delete form.logo; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid using delete for performance and maintainability reasons.
Reassigning the property to undefined or using an empty string is usually safer and more consistent.
- delete form.logo;
+ form.logo = undefined;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| delete form.logo; | |
| form.logo = undefined; |
🧰 Tools
🪛 Biome (1.9.4)
[error] 71-71: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
- Update card initialization
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
Client/src/Pages/Status/CreateStatus/index.jsx (1)
29-30: Yo dawg, fix that typo in the variable name!The variable name
error_tab_mapinghas a typo (missing 'p'). Let's fix that spelling to maintain code quality.-const error_tab_maping = [["companyName","url","timezone","color","publish","logo"],["monitors", +const errorTabMapping = [["companyName","url","timezone","color","publish","logo"],["monitors",Client/src/Components/TabPanels/Status/ContentPanel.jsx (1)
85-85: That deep clone is heavy like mom's spaghetti - let's make it lighter!Using
JSON.parse(JSON.stringify())for deep cloning can be inefficient and doesn't handle all data types correctly.-let x = JSON.parse(JSON.stringify(cards[idx])); +let x = structuredClone(cards[idx]);Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx (1)
76-86: This function's return value is making me nervous - let's clean it up!The
validateFieldfunction has unclear return behavior and could be simplified.const validateField = (toValidate, schema, name = "logo") => { const { error } = schema.validate(toValidate, { abortEarly: false }); setErrors((prev) => { - let prevErrors = { ...prev }; - if (error) prevErrors[name] = error?.details[0].message; - else delete prevErrors[name]; - return prevErrors; + const newErrors = { ...prev }; + if (error) { + newErrors[name] = error.details[0].message; + } else { + delete newErrors[name]; + } + return newErrors; }); - if (error) return true; + return Boolean(error); };
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Client/src/Components/TabPanels/Status/ContentPanel.jsx(1 hunks)Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx(1 hunks)Client/src/Pages/Status/CreateStatus/index.jsx(1 hunks)Client/src/Validation/validation.js(2 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx
[error] 172-172: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
[error] 188-188: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
[error] 227-227: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (2)
Client/src/Pages/Status/CreateStatus/index.jsx (1)
41-47: Clean up those commented fields, they're making me nervous!There are several commented-out fields in the form initialization. Either implement these features or remove the comments to keep the code clean.
Would you like me to help implement these features or create GitHub issues to track them?
Client/src/Validation/validation.js (1)
153-170: 🛠️ Refactor suggestionMom's spaghetti time! Let's beef up this validation! 🍝
The schema needs some additional validation rules to make it more robust:
- URL validation is too permissive
- Color format isn't validated (should it be hex? rgb?)
- Theme validation lacks specific allowed values
- Monitor ID validation could be stronger
Here's how we can strengthen this:
const publicPageGeneralSettingsValidation = joi.object({ publish: joi.bool(), companyName: joi .string() .trim() + .max(100) .messages({ "string.empty": "Company name is required." }), url: joi.string().trim() + .pattern(/^[a-z0-9-]+$/) .messages({ "string.empty": "URL is required.", + "string.pattern.base": "URL must contain only lowercase letters, numbers, and hyphens" }), timezone: joi.string().trim() + .pattern(/^[A-Za-z_\/+-]+$/) .messages({ "string.empty": "Timezone is required." }), color: joi.string().trim() + .pattern(/^#[0-9A-Fa-f]{6}$/) .messages({ "string.empty": "Color is required.", + "string.pattern.base": "Color must be a valid hex code (e.g. #FF0000)" }), - theme: joi.string(), + theme: joi.string().valid('light', 'dark', 'auto'), monitors: joi.array().min(1).items( - joi.string().required() + joi.string().pattern(/^[0-9a-f]{24}$/).required() ).messages({ "string.pattern.base": "Must be a valid monitor ID", "array.base": "Monitors must be an array", "array.empty": "At least one monitor is required", "any.required": "Monitors are required", }), logo: logoImageValidation });Let's verify the monitor ID format matches what's used in the database:
✅ Verification successful
Yo, the validation's weak, code's heavy! Time to drop some truth bombs! 🍝
Based on the codebase analysis, some of our suggested validations need adjusting:
const publicPageGeneralSettingsValidation = joi.object({ publish: joi.bool(), companyName: joi .string() .trim() + .max(100) .messages({ "string.empty": "Company name is required." }), url: joi.string().trim() + .uri() // Changed from pattern() to use Joi's built-in URI validation .messages({ "string.empty": "URL is required.", + "string.uri": "Must be a valid URL" }), timezone: joi.string().trim() + .pattern(/^[A-Za-z_\/+-]+$/) .messages({ "string.empty": "Timezone is required." }), color: joi.string().trim() + .pattern(/^#[0-9A-Fa-f]{6}$/) .messages({ "string.empty": "Color is required.", + "string.pattern.base": "Color must be a valid hex code (e.g. #FF0000)" }), - theme: joi.string(), + theme: joi.string().valid('light', 'dark').required(), // Found these themes in the codebase monitors: joi.array().min(1).items( - joi.string().required() + joi.string().pattern(/^[0-9a-f]{24}$/).required() // Matches MongoDB ObjectId format ).messages({ "string.pattern.base": "Must be a valid monitor ID", "array.base": "Monitors must be an array", "array.empty": "At least one monitor is required", "any.required": "Monitors are required", }), logo: logoImageValidation });• The monitor ID format matches MongoDB's ObjectId format (24 hex chars) as seen in the MongoDB schema definitions
• Theme values are limited to 'light' and 'dark' based on the theme usage in the codebase
• URL validation now uses Joi's built-in URI validator for better robustness
• Added a reasonable max length for company name🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for monitor ID patterns in the codebase rg -A 2 'monitors?.*(id|_id).*='Length of output: 1787
Script:
#!/bin/bash # Let's check the monitor ID format in MongoDB-related files rg -A 2 'mongoose.*Schema.*monitor' || rg -A 2 'new Schema.*monitor' # Also check for any theme-related constants or enums rg -A 2 'theme.*=.*[\[{]' || rg 'enum.*theme'Length of output: 8565
| if (!res.status === 200) { | ||
| throw new Error("Failed to create status page"); | ||
| } |
There was a problem hiding this comment.
Mom's spaghetti alert! Fix this status check!
The status check has incorrect syntax that will always evaluate to false:
if (!res.status === 200)This is equivalent to (!res.status) === 200, which is not what you want.
-if (!res.status === 200) {
+if (res.status !== 200) {| useEffect(() => { | ||
| const fetchMonitors = async () => { | ||
| try { | ||
| const response = await networkService.getMonitorsByTeamId({ | ||
| authToken: authToken, | ||
| teamId: user.teamId, | ||
| limit: -1, | ||
| types: ["http", "ping", "pagespeed", "hardware"], | ||
| }); | ||
| if(response.data.data.monitors.length==0){ | ||
| setErrors({monitors: "Please config monitors to setup status page"}) | ||
| } | ||
| const fullMonitors = response.data.data.monitors ; | ||
| setMonitors(fullMonitors); | ||
| if (form.monitors.length > 0) { | ||
| const initiCards = form.monitors.map((mid, idx) => ({ | ||
| id: "" + idx, | ||
| val: fullMonitors.filter((fM) => | ||
| mid._id ? fM._id == mid._id : fM._id == mid | ||
| )[0], | ||
| })); | ||
| setCards(initiCards); | ||
| } | ||
| } catch (error) { | ||
| createToast({ body: "Failed to fetch monitors data" }); | ||
| logger.error("Failed to fetch monitors", error); | ||
| } | ||
| }; | ||
| fetchMonitors(); | ||
| }, [user, authToken]); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Cleanup missing in useEffect - don't let those memory leaks make you weak in the knees!
The useEffect hook is missing a cleanup function, which could lead to memory leaks if the component unmounts during the fetch operation.
useEffect(() => {
+ let isSubscribed = true;
const fetchMonitors = async () => {
try {
const response = await networkService.getMonitorsByTeamId({
authToken: authToken,
teamId: user.teamId,
limit: -1,
types: ["http", "ping", "pagespeed", "hardware"],
});
+ if (!isSubscribed) return;
if(response.data.data.monitors.length==0){
setErrors({monitors: "Please config monitors to setup status page"})
}
const fullMonitors = response.data.data.monitors;
setMonitors(fullMonitors);
// ... rest of the code
} catch (error) {
+ if (!isSubscribed) return;
createToast({ body: "Failed to fetch monitors data" });
logger.error("Failed to fetch monitors", error);
}
};
fetchMonitors();
+ return () => {
+ isSubscribed = false;
+ };
}, [user, authToken]);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| useEffect(() => { | |
| const fetchMonitors = async () => { | |
| try { | |
| const response = await networkService.getMonitorsByTeamId({ | |
| authToken: authToken, | |
| teamId: user.teamId, | |
| limit: -1, | |
| types: ["http", "ping", "pagespeed", "hardware"], | |
| }); | |
| if(response.data.data.monitors.length==0){ | |
| setErrors({monitors: "Please config monitors to setup status page"}) | |
| } | |
| const fullMonitors = response.data.data.monitors ; | |
| setMonitors(fullMonitors); | |
| if (form.monitors.length > 0) { | |
| const initiCards = form.monitors.map((mid, idx) => ({ | |
| id: "" + idx, | |
| val: fullMonitors.filter((fM) => | |
| mid._id ? fM._id == mid._id : fM._id == mid | |
| )[0], | |
| })); | |
| setCards(initiCards); | |
| } | |
| } catch (error) { | |
| createToast({ body: "Failed to fetch monitors data" }); | |
| logger.error("Failed to fetch monitors", error); | |
| } | |
| }; | |
| fetchMonitors(); | |
| }, [user, authToken]); | |
| useEffect(() => { | |
| let isSubscribed = true; | |
| const fetchMonitors = async () => { | |
| try { | |
| const response = await networkService.getMonitorsByTeamId({ | |
| authToken: authToken, | |
| teamId: user.teamId, | |
| limit: -1, | |
| types: ["http", "ping", "pagespeed", "hardware"], | |
| }); | |
| if (!isSubscribed) return; | |
| if(response.data.data.monitors.length==0){ | |
| setErrors({monitors: "Please config monitors to setup status page"}) | |
| } | |
| const fullMonitors = response.data.data.monitors ; | |
| setMonitors(fullMonitors); | |
| if (form.monitors.length > 0) { | |
| const initiCards = form.monitors.map((mid, idx) => ({ | |
| id: "" + idx, | |
| val: fullMonitors.filter((fM) => | |
| mid._id ? fM._id == mid._id : fM._id == mid | |
| )[0], | |
| })); | |
| setCards(initiCards); | |
| } | |
| } catch (error) { | |
| if (!isSubscribed) return; | |
| createToast({ body: "Failed to fetch monitors data" }); | |
| logger.error("Failed to fetch monitors", error); | |
| } | |
| }; | |
| fetchMonitors(); | |
| return () => { | |
| isSubscribed = false; | |
| }; | |
| }, [user, authToken]); |
| setLogo({ | ||
| src: URL.createObjectURL(pic), | ||
| name: pic.name, | ||
| type: pic.type, | ||
| size: pic.size, | ||
| }); | ||
| setForm({...form, logo: { | ||
| src: URL.createObjectURL(pic), | ||
| name: pic.name, | ||
| type: pic.type, | ||
| size: pic.size, | ||
| }}) |
There was a problem hiding this comment.
Clean up those object URLs before they make you lose your spaghetti!
The URL.createObjectURL creates object URLs that need to be revoked to prevent memory leaks. Also, there's duplicate code in setting the logo state.
+ const objectUrl = URL.createObjectURL(pic);
setLogo({
- src: URL.createObjectURL(pic),
+ src: objectUrl,
name: pic.name,
type: pic.type,
size: pic.size,
});
-setForm({...form, logo: {
- src: URL.createObjectURL(pic),
- name: pic.name,
- type: pic.type,
- size: pic.size,
-}})
+setForm(prev => ({
+ ...prev,
+ logo: {
+ src: objectUrl,
+ name: pic.name,
+ type: pic.type,
+ size: pic.size,
+ }
+}));
+
+return () => {
+ URL.revokeObjectURL(objectUrl);
+};Committable suggestion skipped: line range outside the PR's diff.
| const logoImageValidation = joi.object({ | ||
| type: joi.string().valid("image/jpeg", "image/png").messages({ | ||
| "any.only": "Invalid file format.", | ||
| "string.empty": "File type required.", | ||
| }), | ||
| size: joi | ||
| .number() | ||
| .max(800*800) | ||
| .messages({ | ||
| "number.base": "File size must be a number.", | ||
| "number.max": "File size must be less than 640000 pixels.", | ||
| "number.empty": "File size required.", | ||
| }), | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Yo! Let's clean up this validation schema, dawg! 🍝
The current implementation has some issues that need addressing:
-
The size validation needs clarification:
- The calculation
800*800should be extracted to a named constant - The error message mentions "pixels" but we're validating file size in bytes
- The calculation
-
Consider consolidating with the existing
imageValidationschema to avoid code duplication.
Here's a suggested improvement:
+const MAX_LOGO_SIZE = 800 * 800; // 640000 bytes
+const VALID_IMAGE_TYPES = ['image/jpeg', 'image/png'];
const logoImageValidation = joi.object({
- type: joi.string().valid("image/jpeg", "image/png").messages({
+ type: joi.string().valid(...VALID_IMAGE_TYPES).messages({
"any.only": "Invalid file format.",
"string.empty": "File type required.",
}),
size: joi
.number()
- .max(800*800)
+ .max(MAX_LOGO_SIZE)
.messages({
"number.base": "File size must be a number.",
- "number.max": "File size must be less than 640000 pixels.",
+ "number.max": `File size must be less than ${MAX_LOGO_SIZE} bytes.`,
"number.empty": "File size required.",
}),
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const logoImageValidation = joi.object({ | |
| type: joi.string().valid("image/jpeg", "image/png").messages({ | |
| "any.only": "Invalid file format.", | |
| "string.empty": "File type required.", | |
| }), | |
| size: joi | |
| .number() | |
| .max(800*800) | |
| .messages({ | |
| "number.base": "File size must be a number.", | |
| "number.max": "File size must be less than 640000 pixels.", | |
| "number.empty": "File size required.", | |
| }), | |
| }); | |
| const MAX_LOGO_SIZE = 800 * 800; // 640000 bytes | |
| const VALID_IMAGE_TYPES = ['image/jpeg', 'image/png']; | |
| const logoImageValidation = joi.object({ | |
| type: joi.string().valid(...VALID_IMAGE_TYPES).messages({ | |
| "any.only": "Invalid file format.", | |
| "string.empty": "File type required.", | |
| }), | |
| size: joi | |
| .number() | |
| .max(MAX_LOGO_SIZE) | |
| .messages({ | |
| "number.base": "File size must be a number.", | |
| "number.max": `File size must be less than ${MAX_LOGO_SIZE} bytes.`, | |
| "number.empty": "File size required.", | |
| }), | |
| }); |
- Adjust Server lists and Add new layout etc - Adjust Save button
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (7)
Docker/test/docker-compose.yaml (1)
Line range hint
1-50: There's vomit on his sweater already: Architecture suggestion! 🍝Consider implementing service discovery or using environment-specific DNS for the status page subdomain prefix. This would provide more flexibility for different environments and make it easier to manage domain changes.
Client/src/Pages/Status/CreateStatus/index.jsx (3)
78-79: Clean up this spaghetti code! 🍝The logo object construction is unnecessarily verbose with the type and size spread.
-logo: { type: form.logo?.type ?? "", size: form.logo?.size ?? "" }, +logo: form.logo ?? { type: "", size: "" },
42-43: Mom's spaghetti alert! Clean up these comments!The comment "which fields matching below?" is unclear and should be removed or clarified.
-//which fields matching below? -//publish: false, +// TODO: Implement publish functionality
52-61: Simplify this error mapping logic before it makes your arms heavy!The nested mapping for error tab navigation can be simplified using
findandsome.-Object.keys(errors).map((id) => { - if (newIdx !== -1) return; - error_tab_maping.map((val, idx) => { - let anyMatch = val.some((vl) => vl == id); - if (anyMatch) { - newIdx = idx; - return; - } - }); -}); +const errorTabIdx = error_tab_maping.findIndex(fields => + Object.keys(errors).some(error => fields.includes(error)) +); +if (errorTabIdx !== -1) setTabIdx(errorTabIdx);Client/src/Components/TabPanels/Status/ContentPanel.jsx (1)
73-94: Clean up this handleCardChange spaghetti! 🍝The function is overly complex with nested conditionals and string manipulation.
-const handleCardChange = (event, val) => { - event.preventDefault(); - const { id } = event.target; - let idx = cards.findIndex((a) => { - let found = false; - let optionIdx = id.indexOf("-option"); - if (optionIdx !== -1) found = a.id == id.substr(0, optionIdx); - else found = a.id == id; - return found; - }); - let newCards; - if (idx >= 0) { - let x = JSON.parse(JSON.stringify(cards[idx])); - x.val = val; - newCards = update(cards, { $splice: [[idx, 1, x]] }); - setCards(newCards); - } else { - newCards = update(cards, { $push: [{ id: id, val: val }] }); - setCards(newCards); - } - setForm({ ...form, monitors: newCards.map(c=>c.val) }); -}; +const handleCardChange = (event, val) => { + event.preventDefault(); + const cardId = event.target.id.split('-option')[0]; + const idx = cards.findIndex(card => card.id === cardId); + + const newCards = idx >= 0 + ? update(cards, { + [idx]: { $merge: { val } } + }) + : [...cards, { id: cardId, val }]; + + setCards(newCards); + setForm(prev => ({ + ...prev, + monitors: newCards.map(c => c.val) + })); +};Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx (2)
174-174: Simplify these boolean expressions, they're making me nervous! 😰The boolean literals in conditional expressions are unnecessary.
-error={errors["companyName"] ? true : false} +error={!!errors["companyName"]} -error={errors["url"] ? true : false} +error={!!errors["url"]}Also applies to: 190-190
🧰 Tools
🪛 Biome (1.9.4)
[error] 174-174: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with(lint/complexity/noUselessTernary)
229-229: Add optional chaining to prevent your palms from getting sweaty!Use optional chaining for cleaner null checks.
-) : logo && logo.type ? ( +) : logo?.type ? (🧰 Tools
🪛 Biome (1.9.4)
[error] 229-229: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Docker/dist/docker-compose.yamlis excluded by!**/dist/**
📒 Files selected for processing (7)
Client/.env.production(1 hunks)Client/src/Components/TabPanels/Status/ContentPanel.jsx(1 hunks)Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx(1 hunks)Client/src/Pages/Status/CreateStatus/index.jsx(1 hunks)Docker/prod/docker-compose.yaml(1 hunks)Docker/test/docker-compose.yaml(1 hunks)Docker/test/prod/docker-compose.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- Client/.env.production
🧰 Additional context used
🪛 Biome (1.9.4)
Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx
[error] 174-174: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
[error] 190-190: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
[error] 229-229: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (4)
Docker/test/prod/docker-compose.yaml (1)
6-6: Mom's spaghetti: Same HTTP issue in test/prod! 🍝For consistency with the production environment, this configuration should also use HTTPS and be environment-specific.
Docker/test/docker-compose.yaml (1)
7-7: Knees weak, arms heavy: Let's verify the domain setup! 🍝While HTTP might be acceptable in a test environment, we should verify if this domain is properly configured for both HTTP and HTTPS.
Also, consider extracting this configuration to an environment file for consistency with other services that use env_file.
✅ Verification successful
Yo, the domain's got some sauce! Both HTTP and HTTPS are cookin' 🍝
The domain
uptimegenie.comis responding on both HTTP and HTTPS protocols with a 405 (Method Not Allowed) status code. This is actually expected since we're just doing HEAD requests, and the server's configured to handle specific methods. The important part is that both protocols are up and running, with HTTPS properly upgrading to HTTP/2!
- The HTTP endpoint returns HTTP/1.1 responses
- The HTTPS endpoint upgrades to HTTP/2, showing proper SSL configuration
- Both endpoints are responsive and properly configured
Mom's spaghetti verdict: The domain setup is solid! The test environment can safely use either protocol, though I'd still recommend using HTTPS even in test environments as a best practice.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the domain is accessible and its SSL configuration curl -I http://uptimegenie.com/ curl -I https://uptimegenie.com/Length of output: 825
Client/src/Components/TabPanels/Status/ContentPanel.jsx (1)
27-56:⚠️ Potential issueYo! Don't let those memory leaks make you weak in the knees!
The useEffect hook is missing a cleanup function, which could lead to memory leaks if the component unmounts during the fetch operation.
useEffect(() => { + let isSubscribed = true; const fetchMonitors = async () => { try { const response = await networkService.getMonitorsByTeamId({ authToken: authToken, teamId: user.teamId, limit: -1, types: ["http", "ping", "pagespeed", "hardware"], }); + if (!isSubscribed) return; if(response.data.data.monitors.length==0){ setErrors({monitors: "Please config monitors to setup status page"}) } const fullMonitors = response.data.data.monitors; setMonitors(fullMonitors); } catch (error) { + if (!isSubscribed) return; createToast({ body: "Failed to fetch monitors data" }); logger.error("Failed to fetch monitors", error); } }; fetchMonitors(); + return () => { + isSubscribed = false; + }; }, [user, authToken]);Likely invalid or redundant comment.
Client/src/Components/TabPanels/Status/GeneralSettingsPanel.jsx (1)
95-106:⚠️ Potential issueClean up those object URLs before they make you lose your spaghetti!
The
URL.createObjectURLcreates object URLs that need to be revoked to prevent memory leaks. Also, there's duplicate code in setting the logo state.+const objectUrl = URL.createObjectURL(pic); setLogo({ - src: URL.createObjectURL(pic), + src: objectUrl, name: pic.name, type: pic.type, size: pic.size, }); -setForm({...form, logo: { - src: URL.createObjectURL(pic), - name: pic.name, - type: pic.type, - size: pic.size, -}}) +setForm(prev => ({ + ...prev, + logo: { + src: objectUrl, + name: pic.name, + type: pic.type, + size: pic.size, + } +})); + +return () => { + URL.revokeObjectURL(objectUrl); +};Likely invalid or redundant comment.
| @@ -4,6 +4,7 @@ services: | |||
| restart: always | |||
| environment: | |||
| UPTIME_APP_API_BASE_URL: "https://checkmate-demo.bluewavelabs.ca/api/v1" | |||
| UPTIME_STATUS_PAGE_SUBDOMAIN_PREFIX: "http://uptimegenie.com/" | |||
There was a problem hiding this comment.
Yo dawg, we need HTTPS for production! 🍝
The subdomain prefix is using HTTP which isn't secure for production use. Additionally, having the same hardcoded value across all environments might limit flexibility.
Consider these changes:
- UPTIME_STATUS_PAGE_SUBDOMAIN_PREFIX: "http://uptimegenie.com/"
+ UPTIME_STATUS_PAGE_SUBDOMAIN_PREFIX: "https://uptimegenie.com/"Also, consider moving this value to an environment file to allow easy customization per environment.
Committable suggestion skipped: line range outside the PR's diff.
| const res = await networkService.createStatusPage(config); | ||
| if (!res.status === 200) { |
There was a problem hiding this comment.
Yo! Fix this status check before it makes your knees weak!
The status check has incorrect syntax that will always evaluate to false:
if (!res.status === 200)This is equivalent to (!res.status) === 200, which is not what you want.
Here's the fix to make your palms less sweaty:
-if (!res.status === 200) {
+if (res.status !== 200) {
Screencast.from.2024-12-30.22-02-19.webm