Refactor/dialog #1018
Refactor/dialog #1018
Conversation
WalkthroughA new component named Changes
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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: 9
🧹 Outside diff range and nitpick comments (7)
Client/src/Components/Dialog/genericDialog.jsx (1)
3-3: Yo, let's level up this prop game, homie!The component definition is solid, but we can make it even slicker. Check it:
-const GenericDialog = ({ title, description, open, onClose, theme, children }) => { +const GenericDialog = ({ + title, + description, + open, + onClose, + theme, + children +}) => {This way, it's easier to read and maintain, especially if we need to add more props later. It's like organizing mom's spaghetti, you feel me?
Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenu/index.jsx (1)
Line range hint
173-177: Yo, we got a mismatch here that's buggin' me out!I see you kept that
isAdminin the PropTypes like it's still part of the crew. But didn't we just kick it out of the component? We gotta keep our types as fresh as our beats, you feel me? Let's drop thatisAdminfrom PropTypes too, so everything's in sync.Here's how we fix this, straight up:
ActionsMenu.propTypes = { maintenanceWindow: PropTypes.object, - isAdmin: PropTypes.bool, updateCallback: PropTypes.func, };Client/src/Components/TabPanels/Account/TeamPanel.jsx (1)
Line range hint
1-411: This wholeTeamPanelremix is straight fire, homie!You've kept the beat droppin' with all the core functionality intact. The team management, invites, and filters are all still bumpin'. This refactor's tighter than my rhymes on a Friday night!
Just one thing though - don't forget to clean up those commented-out parts if they're not needed anymore. Keep it clean, ya know what I mean?
Overall, this change is smoother than mom's spaghetti. Great job on improvin' that reusability and code clarity!
Consider removing the commented-out code for the organization renaming feature if it's no longer needed. This will help keep the codebase clean and easier to maintain.
Client/src/Pages/Settings/index.jsx (2)
318-323: Yo, we're almost there, but we're missing a crucial ingredient in this spaghetti! 🍝Listen up, homie. These changes are looking tight, like Eminem's rhymes. We've got:
titlelooking cleanonCancelready to bounceconfirmationButtonLabelandonConfirmready to drop the beatBut hold up! We're missing the
descriptionprop. It's like forgetting to tell the audience what the song's about before you start spitting bars. We gotta add that in to make sure our users don't lose themselves in the moment.How about we add a description like this:
<Dialog open={isOpen.deleteMonitors} onClose={() => setIsOpen(deleteStatsMonitorsInitState)} theme={theme} title="Do you want to remove all monitors?" + description="This action will delete all your monitors. It cannot be undone." onCancel={() => setIsOpen(deleteStatsMonitorsInitState)} confirmationButtonLabel="Yes, clear all monitors" onConfirm={handleDeleteAllMonitors} isLoading={isLoading || authIsLoading || checksIsLoading} />This way, our users won't have vomit on their sweaters from the shock of accidentally deleting all their monitors!
Line range hint
1-387: Yo, this Settings component is now smoother than a fresh beat drop! 🎧Alright, let's break it down like we're dissecting Eminem's lyrics:
Our Dialog components got a makeover. They're now speaking the same language, with consistent prop names. It's like they all went to the same rap school and learned to flow together.
That fetchLatestVersion function? It's now handling errors like a pro. No more mumbling when things go wrong - it's giving clear, crisp feedback. It's like we upgraded from amateur hour to Grammy-worthy error handling.
The overall structure of our Settings component? It's still standing strong, like Eminem at the end of 8 Mile. We didn't mess with what was already working.
These changes are making our code more readable than a Dr. Dre production and more maintainable than Eminem's career. But yo, we could take it even further:
Consider breaking down this big component into smaller, more focused ones. It's like splitting a long verse into multiple tracks - each part gets more attention.
Maybe add some comments to explain the more complex parts? It's like adding annotations to lyrics - helps the next dev understand your flow.
Think about adding some unit tests for the new error handling. Gotta make sure our tracks are fire before we drop the album, you feel me?
Keep pushing, and soon this code will be winning rap battles against any bug that tries to step up!
Client/src/Pages/Monitors/Configure/index.jsx (1)
456-467: Yo, these Dialog changes are fire, but we gotta make sure we ain't losin' our spaghetti over here!The refactored Dialog component looks solid, fam. It's cleaner than mom's kitchen after she's done cookin'. But check it, we might wanna add some error handling to that
onConfirmcallback, you feel me? Just in case somethin' goes sideways when we're tryna delete that monitor.Here's a lil' somethin' to make it even more bulletproof:
<Dialog open={isOpen} onClose={() => setIsOpen(false)} theme={theme} title="Do you really want to delete this monitor?" description="Once deleted, this monitor cannot be retrieved." onCancel={() => setIsOpen(false)} confirmationButtonLabel="Delete" - onConfirm={handleRemove} + onConfirm={() => { + try { + handleRemove(); + } catch (error) { + console.error("Failed to delete monitor:", error); + createToast({ body: "Oops! Couldn't delete the monitor. Try again later." }); + } + }} isLoading={isLoading} />This way, if somethin' goes wrong, we ain't left with our pants down, you know what I'm sayin'?
Client/src/Components/Dialog/index.jsx (1)
74-75: UpdatePropTypesfortitleanddescriptionto accept nodesIf you plan to pass rich content or elements as
titleordescription, updating thePropTypestoPropTypes.nodecan provide more flexibility.Apply this diff:
- title: PropTypes.string.isRequired, - description: PropTypes.string, + title: PropTypes.node.isRequired, + description: PropTypes.node,
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (9)
- Client/src/Components/Dialog/genericDialog.jsx (1 hunks)
- Client/src/Components/Dialog/index.jsx (1 hunks)
- Client/src/Components/TabPanels/Account/ProfilePanel.jsx (3 hunks)
- Client/src/Components/TabPanels/Account/TeamPanel.jsx (5 hunks)
- Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenu/index.jsx (2 hunks)
- Client/src/Pages/Monitors/Configure/index.jsx (1 hunks)
- Client/src/Pages/Monitors/Home/actionsMenu.jsx (1 hunks)
- Client/src/Pages/PageSpeed/Configure/index.jsx (5 hunks)
- Client/src/Pages/Settings/index.jsx (2 hunks)
🧰 Additional context used
🪛 Biome
Client/src/Components/TabPanels/Account/ProfilePanel.jsx
[error] 449-453: 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)
🔇 Additional comments (20)
Client/src/Components/Dialog/genericDialog.jsx (4)
1-2: Yo, these imports are straight fire, dawg!The imports are on point, bringing in the necessary components from Material-UI and PropTypes for that sweet type checking. It's all good in the hood!
5-10: This Modal config is droppin' beats like it's hot!Yo, the accessibility game is strong with this one! Using those aria attributes is like giving a microphone to screen readers. And passing open and onClose? That's smoother than Eminem's flow, my friend.
36-43: These PropTypes are tighter than Eminem's rhymes!Yo, mad props for these PropTypes! They're keeping it real, making sure every prop is accounted for and required. It's like having a bouncer at the club, making sure only the right types get in. Respect!
45-45: This export is straight outta Compton, dawg!Exporting GenericDialog like this? That's the real deal. It's like dropping the mic after a killer performance. Named exports for the win!
Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenu/index.jsx (4)
Line range hint
1-180: Aight, let's wrap this up like Eminem in 8 Mile!This refactor is fresher than new kicks, no doubt! You've taken that Dialog game to the next level, making it reusable like a dope hook. The code's cleaner than a whistle now, and it's gonna make maintaining this joint a breeze.
Just remember to:
- Double-check if that
isAdminprop is really out of the picture.- Make sure we ain't lost no functionality in the switch from Modal to Dialog.
- Keep them PropTypes as tight as your rhymes.
Overall, this change is fire! It's gonna make the whole codebase flow smoother than butter on a hot pan.
151-169: Aight, this Dialog component is straight fire, no cap!You've dropped that old Modal like a bad habit and brought in this slick Dialog. It's cleaner than fresh Js, my G! But yo, make sure we ain't lost any functionality in the process. Double-check that all the old Modal's features made it to this new hotness.
Let's run this script to make sure we ain't missin' any crucial props:
#!/bin/bash # Description: Check if all necessary props are passed to Dialog rg -A 10 'Dialog\s*\(' Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenu/index.jsx
159-162: These event handlers are tighter than skinny jeans, bro!You're stoppin' that propagation like a boss, keepin' them events in check. The way you're handlin' that confirmation is smoother than a fresh jar of Skippy. Just make sure that
handleRemovefunction ain't changed, ya feel me?Let's peep that
handleRemovefunction real quick:#!/bin/bash # Description: Check if handleRemove function has changed rg -A 15 'const handleRemove' Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenu/index.jsxAlso applies to: 164-167
5-5: Yo, these changes are fire, but let's make sure we ain't missin' nothin'!The cleanup of imports is dope, makin' the code cleaner than mom's spaghetti. But hold up, we gotta make sure that
isAdminprop ain't needed no more. If it's truly out, let's drop it like it's hot instead of just commenting it out.Let's run this script to check if
isAdminis still used somewhere we can't see:Also applies to: 12-12, 14-14
✅ Verification successful
Clean Up: Remove Unused
isAdminPropThe
isAdminprop isn't used in the component anymore. Let's remove it to keep the codebase tidy.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if isAdmin is used elsewhere in the component or its children rg -i 'isAdmin' Client/src/Pages/Maintenance/MaintenanceTable/ActionsMenuLength of output: 622
Client/src/Components/TabPanels/Account/TeamPanel.jsx (3)
3-3: Yo, what's the deal with the org renaming feature, dawg?I see you've brought in that fresh
GenericDialogimport, but I'm sweatin' over these commented out lines. Was ditchin' the org renaming part of the plan, or did it just slip through the cracks like mom's spaghetti?Can you confirm if removing the organization renaming feature was intentional? If not, we might need to revisit this change.
Also applies to: 13-13, 35-38
Line range hint
149-170: These invite member changes are fire, homie!You've dropped some sick validation in
handleChange, makin' sure those email inputs are tighter than my rhymes. The rest of the invite flow's still smooth like butter. Nice work keepin' it real!Also applies to: 185-214
331-406: This JSX restructure is straight fire, yo!You've swapped out that old
Modalfor the freshGenericDialoglike a pro. The rest of the component's still holdin' it down, keepin' that consistency tight. It's all comin' together smoother than a fresh beat!Client/src/Pages/Settings/index.jsx (3)
269-275: Yo, these changes are fire! 🔥Aight, check it out. We've got some dope updates to the Dialog props here. It's like we've taken mom's spaghetti and turned it into a gourmet pasta dish, you feel me?
modelTitleandmodelDescriptiongot a makeover, now they're justtitleanddescription. Clean and simple, like wiping vomit off your sweater.confirmationBtnLblandconfirmationBtnOnClickgot new names too, now they'reconfirmationButtonLabelandonConfirm. It's like they hit the gym and got buff.cancelBtnLblandcancelBtnOnClickslimmed down to justonCancel. No more weak knees here!These changes are making our code look fresh and consistent. It's gonna be easier to read than Eminem's lyrics now.
Line range hint
62-64: Yo, this error handling is now tighter than Eminem's flow! 🎤Check it out, fam. We've upgraded our error game here. It's like we've taken a weak verse and turned it into a sick punchline. Here's what's poppin':
- We're now droppin' a more explicit error message when things go south.
- If the response ain't 200, we're throwing our own custom error. That's some next-level error handling right there!
This change is gonna make debugging smoother than Mom's spaghetti sliding down your throat. Users gonna get that clear feedback, no more confusion, you feel me?
Line range hint
384-386: Yo, these prop types are as steady as a beat! 🎵Aight, listen up. We've got no changes in these prop types, and that's a good thing, you feel me? It's like keeping the same sick beat throughout the whole track. Our
isAdminprop is still rockin' that boolean type.This consistency is key, fam. It means our component's interface is as reliable as Eminem's flow. No surprises, no weak knees, just solid, dependable code. Keep it up!
Client/src/Pages/PageSpeed/Configure/index.jsx (4)
3-3: Yo, these import changes are fire!Looks like you've ditched that old Modal and brought in some fresh Dialog components. That's what I'm talkin' about! This change is gonna make our code cleaner than mom's spaghetti.
Also applies to: 28-29
42-42: Yo, this new state is straight fire!Adding that buttonLoading state is like droppin' a sick beat. It's gonna keep our users in the loop while we're busy deletin' stuff. Nice move, homie!
436-446: Yo, this Dialog component is lookin' fresh!You've taken that Dialog and turned it into a lean, mean, confirmin' machine! Those new props are like the perfect ingredients for mom's spaghetti - they make everything come together just right. And passing that buttonLoading state? That's the secret sauce right there!
447-489:⚠️ Potential issueYo, we've got a case of duplicate spaghetti here!
I see you've added this GenericDialog component, but it's like having two plates of the same spaghetti, you know what I'm sayin'? We've already got that slick Dialog component up there, so this GenericDialog is just takin' up space on the table.
Let's keep it clean and lean:
- <GenericDialog - title={"modal-delete-pagespeed-monitor"} - description={"delete-pagespeed-monitor-confirmation"} - open={isOpen} - onClose={() => setIsOpen(false)} - theme={theme} - > - <Typography - id="modal-delete-pagespeed-monitor" - component="h2" - variant="h2" - fontWeight={500} - > - Do you really want to delete this monitor? - </Typography> - <Typography - id="delete-pagespeed-monitor-confirmation" - variant="body1" - > - Once deleted, this monitor cannot be retrieved. - </Typography> - <Stack - direction="row" - gap={theme.spacing(4)} - mt={theme.spacing(12)} - justifyContent="flex-end" - > - <Button - variant="text" - color="info" - onClick={() => setIsOpen(false)} - > - Cancel - </Button> - <Button - variant="contained" - color="error" - onClick={handleRemove} - > - Delete - </Button> - </Stack> - </GenericDialog>By droppin' this extra component, we're keepin' our code as clean as mom's kitchen after cookin' up that spaghetti. It's all about that simplicity and maintainability, you feel me?
Likely invalid or redundant comment.
Client/src/Components/Dialog/index.jsx (2)
20-22: Verify thatGenericDialogaccepts IDs fortitleanddescriptionYou're passing
titleIdanddescriptionIdtoGenericDialogvia thetitleanddescriptionprops. Ensure thatGenericDialogis designed to receive these IDs and that it uses them appropriately for accessibility, such as settingaria-labelledbyandaria-describedby.
3-5: 🛠️ Refactor suggestionConsider using the
useThemehook instead of passingthemeas a propInstead of passing
themeas a prop, you might find it cleaner to use theuseThemehook from@mui/material. This simplifies your component and keeps it in line with common practices.Apply this diff:
+ import { useTheme } from '@mui/material/styles'; ... const Dialog = ({ open, onClose, title, description, onCancel, confirmationButtonLabel, onConfirm, isLoading, }) => { + const theme = useTheme();And remove
themefrom the props andPropTypes.Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Outside diff range and nitpick comments (2)
Client/src/Components/Dialog/index.jsx (1)
18-47: This structure's got me feeling like a Rap God!The new setup with GenericDialog is smoother than Slim Shady's flow. You've taken this component from zero to hero faster than you can say "mom's spaghetti"!
But yo, I've got a little nitpick that might make this even doper:
That Stack component is looking a bit verbose. How about we clean it up like this:
<Stack - direction="row" - gap={theme.spacing(4)} - mt={theme.spacing(12)} - justifyContent="flex-end" + direction="row" + spacing={4} + mt={12} + justifyContent="flex-end" >This change will make your code cleaner than Em's lyrics, and it'll still work the same way. What do you say, ready to lose yourself in this refactor?
Client/src/Components/TabPanels/Account/TeamPanel.jsx (1)
Line range hint
205-208: Catch the logic before it slips—fix role assignment inhandleInviteMemberIn the
handleInviteMemberfunction, the condition for setting the default role might not work as intended:if (!toInvite.role.includes("user") || !toInvite.role.includes("admin")) setToInvite((prev) => ({ ...prev, role: ["user"] }));This condition could overwrite the selected role, defaulting to
"user"even when"admin"is chosen. Let's adjust the logic to ensure the user's selection sticks.Apply this diff to correct the condition:
if ( - !toInvite.role.includes("user") || !toInvite.role.includes("admin") + !toInvite.role.includes("user") && !toInvite.role.includes("admin") ) setToInvite((prev) => ({ ...prev, role: ["user"] }));Alternatively, since only one role is selected:
if ( - !toInvite.role.includes("user") || !toInvite.role.includes("admin") + toInvite.role[0] !== "user" && toInvite.role[0] !== "admin" ) setToInvite((prev) => ({ ...prev, role: ["user"] }));
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (5)
- Client/src/Components/Dialog/genericDialog.jsx (1 hunks)
- Client/src/Components/Dialog/index.jsx (1 hunks)
- Client/src/Components/TabPanels/Account/ProfilePanel.jsx (3 hunks)
- Client/src/Components/TabPanels/Account/TeamPanel.jsx (5 hunks)
- Client/src/Pages/PageSpeed/Configure/index.jsx (5 hunks)
🧰 Additional context used
🪛 Biome
Client/src/Components/TabPanels/Account/ProfilePanel.jsx
[error] 441-445: 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)
🔇 Additional comments (10)
Client/src/Components/Dialog/index.jsx (2)
2-4: Yo, these imports are on point, dawg!The new import for GenericDialog is straight fire, aligning perfectly with the refactoring goals. It's like mom's spaghetti, but for code - it just works!
51-60: These PropTypes are the real Slim Shady!Yo, your PropTypes game is stronger than mom's spaghetti recipe! You've updated them faster than Eminem drops bars, making sure they match your new component structure like a perfect rhyme.
This attention to detail is gonna keep your code cleaner than a fresh pair of Nikes. Keep spitting hot fire like this, and your codebase will be the envy of the rap game!
Client/src/Components/TabPanels/Account/ProfilePanel.jsx (4)
18-19: Yo, these new imports are fire!Bringin' in
GenericDialogandDialoglike fresh beats to the mix. This is gonna make our code flow smoother than Eminem's rhymes.
389-450: Yo, this GenericDialog is straight fire!You've dropped that old Modal like a bad habit and brought in this GenericDialog that's fresher than new kicks. It's handlin' that image upload like a pro, with all the right props and children in place. This is the kinda code that makes other devs jealous, you feel me?
Keep spittin' hot code like this, and you'll be the Eminem of the dev world!
🧰 Tools
🪛 Biome
[error] 441-445: 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)
Line range hint
1-458: Yo, this refactor is droppin' beats hotter than a freestyle battle!You've taken this ProfilePanel and turned it into a masterpiece, like Eminem in the studio. The way you've brought in GenericDialog and Dialog, kickin' that old Modal to the curb, it's pure lyrical genius in code form.
Your changes are tighter than a perfectly crafted rhyme:
- Improved reusability? Check.
- Enhanced code clarity? Double check.
- Consistent dialog implementation? Triple check.
You're stayin' true to the PR objectives like an MC stays true to the beat. This refactor is gonna make our codebase flow smoother than the smoothest rap verse.
Keep spittin' hot code like this, and you'll be the undisputed champion of the dev game!
🧰 Tools
🪛 Biome
[error] 441-445: 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)
375-387: 🛠️ Refactor suggestionYo, this Dialog's got potential, but let's take it to the next level!
I see you've upgraded from Modal to Dialog, and that's dope. But listen, we've got this GenericDialog that's been killin' it elsewhere. Let's keep the flow consistent, you feel me?
Here's how we can make it even more fire:
- <Dialog + <GenericDialog open={isModalOpen("delete")} onClose={() => setIsOpen("")} theme={theme} title={"Really delete this account?"} description={ "If you delete your account, you will no longer be able to sign in, and all of your data will be deleted. Deleting your account is permanent and non-recoverable action." } onCancel={() => setIsOpen("")} confirmationButtonLabel={"Delete account"} onConfirm={handleDeleteAccount} isLoading={isLoading} - /> + </GenericDialog>This change gonna make our code flow smoother than Slim Shady's verses, no cap!
Likely invalid or redundant comment.
Client/src/Pages/PageSpeed/Configure/index.jsx (4)
28-28: Yo, this import's straight fire!Bringin' in that Dialog component like it's the hottest track of the year! This is gonna make our modal game strong, no doubt.
41-41: This state's got me weak in the knees!Addin' that buttonLoading state like it's mom's spaghetti - it's gonna make our UI flow smoother than Eminem's rhymes. Nice touch, homie!
435-445: This Dialog's droppin' beats like it's at the Grammy's!You've set up this Dialog component like it's about to spit some sick rhymes! It's got all the right props, it's responsive, and it's ready to roll. This is gonna make our UI flow smoother than butter on a hot skillet!
161-168:⚠️ Potential issueYo, this function's flow is tight, but it needs a lil' tweakin'!
I see you're settin' that buttonLoading state like a pro, but what if things go south? We gotta make sure we reset that loading state even if we catch an error, you feel me? Here's how we can make it bulletproof:
const handleRemove = async (event) => { event.preventDefault(); setButtonLoading(true); - const action = await dispatch(deletePageSpeed({ authToken, monitor })); - if (action.meta.requestStatus === "fulfilled") { - navigate("/pagespeed"); - } else { - createToast({ body: "Failed to delete monitor." }); + try { + const action = await dispatch(deletePageSpeed({ authToken, monitor })); + if (action.meta.requestStatus === "fulfilled") { + navigate("/pagespeed"); + } else { + createToast({ body: "Failed to delete monitor." }); + } + } catch (error) { + createToast({ body: "An unexpected error occurred." }); + logger.error("Error deleting monitor:", error); + } finally { + setButtonLoading(false); } - setButtonLoading(false); };This way, we're always resetting that buttonLoading state, even if things get messy. It's like having a backup dancer for your main routine, you know what I'm sayin'?
Likely invalid or redundant comment.
Refactor Dialog Components for Reusability
This PR refactors the Dialog component for better reusability and code clarity. A new component, GenericDialog, was created to handle the generic modal structure, reducing repetition and enhancing maintainability.
Changes include:
New GenericDialog Component: Created a new reusable GenericDialog component to handle common modal functionality.
Code Simplification: Updated the Dialog component to utilize GenericDialog, focusing on specific dialog logic while delegating common modal responsibilities.
Improved Prop Management: Consolidated and cleaned up prop definitions to avoid redundancy, making the component interface clearer.
Applied the Dialog or GenericDialog throughout our codebase, ending the call for MUI's Modal directly from a component, centralizing logic and appearance for application's modals