Conversion of Service Dialogs Form from Angular to React #9592

elsamaryv · 2025-08-25T10:48:19Z

Revamp of service dialogs (Also includes its conversion from Angular to React)

@miq-bot add-label enhancement
@miq-bot add-label wip

Fryguy · 2025-08-25T15:34:50Z

cypress/support/commands/common.js

@@ -0,0 +1,37 @@
+/* eslint-disable no-undef */
+
+// Look for notification popups and disable them if present


Are these for "real" notifications or for debug-type notifications? If the latter, then this shouldn't be needed because if you run the webpack-dev-server and the rails server with CYPRESS=true then those debug-type notifications won't be there.

I think I went the same way, creating a command to get rid of these notifications before I knew CYPRESS variable to do CYPRESS=true bin/webpack for compiling assets for development

Fryguy · 2025-08-25T15:36:02Z

cypress/support/commands/customization/service-dialogs.js

+/* eslint-disable no-undef */
+
+// Drag and drop a component to a section
+Cypress.Commands.add('dragAndDropComponent', (componentName, targetSectionIndex = 0) => {


Because there are commands being defined globally, but are specific to service dialogs, I think the names should be prefixed with something like serviceDialog to avoid any name collisions and to clarify their purpose.

Fryguy · 2025-08-25T15:36:33Z

cypress/support/commands/customization/service-dialogs.js

+});
+
+// Login and navigate to add a new service dialog
+Cypress.Commands.add('navigateToAddDialog', () => {


well, maybe not this one because it also includes login and navigation

app/javascript/packs/component-definitions-common.js

Fryguy · 2025-08-25T15:38:56Z

I know this is still WIP, but can @GilbertCherrie , @asirvadAbrahamVarghese please review to get a first pass on it?

app/javascript/components/common/inline-flash-message/index.jsx

asirvadAbrahamVarghese · 2025-08-27T03:49:46Z

app/javascript/components/common/inline-flash-message/index.jsx

+import PropTypes from 'prop-types';
+import { InlineNotification } from 'carbon-components-react';
+
+const InlineFlashMessage = ({ message, setMessage }) => {


if it’s just to pass through any actions required for the close button click maybe we could rename the prop to something like onCloseClick (I’m clueless when it comes to naming, so it’s your call)

Should we consider changing message to messageInfo, given that its an object? - again thats your call

if it’s just to pass through any actions required for the close button click maybe we could rename the prop to something like onCloseClick

This component pulls InlineNotification component from carbon-components-react and is used to display contextual messages inline with other contents in the UI. onCloseButtonClick is actually a property of the InlineNotification component - It is an event handler that is only called when the user clicks the close button(if it is visible).

I meant the setMessage prop from our component that we’re using as the handler for onCloseButtonClick in InlineNotification, I feel like onCloseButtonClick ={onCloseClick} (or anything similar) seems better in this context

asirvadAbrahamVarghese · 2025-08-27T03:50:03Z

app/javascript/components/common/inline-flash-message/index.jsx

+      title={message.title || ''}
+      subtitle={message.subtitle || ''}
+      lowContrast
+      hideCloseButton={!setMessage}


It might be better to control hideCloseButton through a separate boolean prop and set a default for it 🤔

asirvadAbrahamVarghese · 2025-08-27T03:50:12Z

app/javascript/components/common/inline-flash-message/index.jsx

+      lowContrast
+      hideCloseButton={!setMessage}
+      onCloseButtonClick={
+        typeof setMessage === 'function' ? () => setMessage(null) : undefined


I was thinking if we should directly do:
onCloseButtonClick={setMessage}
So that react will pass down the event automatically when setMessage handler is called similar to how we’d pass the event manually like:
onCloseButtonClick={(event)=>setMessage(event)}

So if in case we want to access any event methods (preventDefault, stopPropagation) from this component sometime later we can do:
<InlineFlashMessage setMessage={(event)=>{ event.preventDefault(); }} .... />

asirvadAbrahamVarghese · 2025-08-27T03:50:43Z

app/javascript/components/common/inline-flash-message/index.jsx

+};
+
+InlineFlashMessage.defaultProps = {
+  message: null,


since we are doing if (!message) return null; at the top of the component, we can safely skip setting message as null from default props unless its marked required by PropTypes.shape({}).isRequired - the value received will be undefined and would still match our if(!message) condition

asirvadAbrahamVarghese · 2025-08-27T03:51:52Z

app/javascript/components/common/inline-flash-message/index.jsx

+
+InlineFlashMessage.defaultProps = {
+  message: null,
+  setMessage: undefined,


We can set a no-op function as default instead of undefined:
setMessage: () => {},
If thats throwing any eslint error(empty blocks), we can do:

setMessage: () => { // default callback },

so that it prevents errors like “Cannot call setMessage of undefined”.
this also means we don’t have to explicitly verify typeof setMessage === 'function' before passing existing function reference directly: onCloseButtonClick={setMessage}
or even if we are creating a new arrow function on every render that calls onCloseButtonClick:

onCloseButtonClick={() => { // any other action setMessage(); }}

asirvadAbrahamVarghese · 2025-09-01T06:17:55Z

app/javascript/components/date-time-picker/index.jsx

+} from 'carbon-components-react';
+import { getCurrentDate, getCurrentTimeAndPeriod } from '../service-dialog-form/helper';
+
+const CustomDateTimePicker = (field) => {


Correct me here if I am wrong
We will be using the component like:

<CustomDateTimePicker label="Custom Date Time Picker" initialData={{ date: '11/06/2025', time: '23:11', period: 'PM' }} onChange={(data) => { // any actions with on change data }} />

So I was thinking - just like we did with InlineFlashMessage, inline destructuring of component props is generally cleaner instead of accessing them via field object:
const CustomDateTimePicker = ({ label, onChange, initialData }) => {...

and then add props validations and default props for them:

CustomDateTimePicker.propTypes = { initialData: PropTypes.shape({ date: PropTypes.string, time: PropTypes.string, period: PropTypes.string, }), onChange: PropTypes.func, label: PropTypes.string, }; CustomDateTimePicker.defaultProps = { initialData: { date: '', time: '', period: '' }, onChange: () => {}, label: '', };

Note: date, time and period having an empty string as default value ({ date: '', time: '', period: '' }) shouldn't be a problem as they are falsy in JS, fallback methods like getCurrentDate and getCurrentTimeAndPeriod will still be triggered to set states initial values

asirvadAbrahamVarghese · 2025-09-01T06:18:14Z

app/javascript/components/date-time-picker/index.jsx

+const CustomDateTimePicker = (field) => {
+  const { initialData, onChange } = field;
+
+  const [date, setDate] = useState(initialData.date || getCurrentDate);


I guess it would be better to call the function immediately (getCurrentDate) instead of passing the reference for React to call it automatically to get the initial state value when initialData.date is not available:
const [date, setDate] = useState(() => initialData.date || getCurrentDate());

also include the lazy initialization () =>🔝, like we did with time and period states initializations, so that the arrow function is only executed during the initial render, on subsequent re-renders, react knows it already has a state value and doesn't need to call the function again. The performance difference would be negligible here I believe, but it's better to use the arrow function for any initialization that creates objects, makes calculations or anything that could potentially be expensive.

asirvadAbrahamVarghese · 2025-09-01T06:19:18Z

app/javascript/components/date-time-picker/index.jsx

+  const { initialData, onChange } = field;
+
+  const [date, setDate] = useState(initialData.date || getCurrentDate);
+  const [time, setTime] = useState(() => initialData.time || getCurrentTimeAndPeriod().time);


On initial render, time would look like this which is not in our expected "hh:mm" format, it should have been "09:54", But the invalid time error: "Enter a valid 12-hour time" is not displayed, probably thats because isValid state is initially true

Right after time field is edited the error is displayed since our state isValid state is now updated:

No issues with this implementation, this should work well once we apply zero-padding to the hour value in getCurrentTimeAndPeriod(similar to what we did with minutes).
It should be padded after converting to 12-hour format, otherwise, the modulo will reduce it to a single digit again.
hours = ${hours % 12 || 12}.padStart(2, '0');
Which should work well:

asirvadAbrahamVarghese · 2025-09-01T06:19:47Z

app/javascript/components/date-time-picker/index.jsx

+  };
+
+  const handleDateChange = (newDate) => {
+    if (newDate.length > 0) {


if (newDate.length) should be fine here since 0 is also falsy in JS and any number greater than 0 will be truthy

asirvadAbrahamVarghese · 2025-09-01T06:20:37Z

app/javascript/components/date-time-picker/index.jsx

+    const newTime = event.target.value;
+    setTime(newTime);
+    validateTime(newTime);
+    if (isValid) onChange({ value: combinedDateTime(), initialData });


Tried "11:5" in the time field, which doesn't match our pattern, so it's treated as an invalid time, the regex correctly returns false, which we also assign to the isValid state:

Given the condition(if (isValid) onChange({ ... });), we don't expect the onChange prop to be triggered in this case but it still gets called since isValid is still true(initial state value is true):

This is because state updates are asynchronous & batched and won't be reflecting immediately, when setIsValid is called react schedules the state update and updated value will be available only in the next render(only after the current event scope) not immediately after the call. So within the same event, we will still be accessing the previous state(which is true).

Returning the regex result from validateTime and using it for both setting state and controlling onChange should work fine:

const validateTime = (value) => { const timeRegex = /^(0[1-9]|1[0-2]):[0-5][0-9]$/; // Matches 12-hour format hh:mm return timeRegex.test(value); }; const handleTimeChange = (event) => { const newTime = event.target.value; setTime(newTime); const isValidTime = validateTime(newTime); setIsValid(isValidTime); if (isValidTime) onChange({ value: combinedDateTime(), initialData }); };

asirvadAbrahamVarghese · 2025-09-01T06:20:58Z

app/javascript/components/date-time-picker/index.jsx

+    const newTime = event.target.value;
+    setTime(newTime);
+    validateTime(newTime);
+    if (isValid) onChange({ value: combinedDateTime(), initialData });


The combinedDateTime function is also impacted the same way, we are updating the time state from here & then trying to access the state value from the same event scope, we will be having the previous time value due to react's batched updates.
Time field value is updated to "12:53" but time state will still provide its previous value "12:5" inside the same method scope:

Instead of relying on stale state we could update combinedDateTime to use the same input we're using for the state (in a way that it uses parameter value if available or the state value, thus other state values(date & period) are set):

const combinedDateTime = ({ dateValue, timeValue, periodValue } = {}) => `${dateValue || date} ${timeValue || time} ${periodValue || period}`;

🔝 we can also avoid the intermediate variable(const dateTime) by returning the string immediately

Now from handleTimeChange we can pass the value for time like:

if (isValidTime) { onChange({ value: combinedDateTime({ timeValue: newTime }), initialData, }); }

So that correct updated time is returned from combinedDateTime

asirvadAbrahamVarghese · 2025-09-01T06:21:21Z

app/javascript/components/date-time-picker/index.jsx

+        year: 'numeric',
+      }).format(newDate[0]);
+      setDate(formattedDate);
+      onChange({ value: combinedDateTime(), initialData });


Like discussed below, due to batched state updates we might want to update combinedDateTime to receive the updated date string:

const combinedDateTime = ({ dateValue, timeValue, periodValue } = {}) => `${dateValue || date} ${timeValue || time} ${periodValue || period}`;

and then from handleDateChange pass the date string value:

const handleDateChange = (newDate) => { if (newDate.length) { const formattedDate = new Intl.DateTimeFormat('en-US', { ..... onChange({ value: combinedDateTime({ dateValue: formattedDate }), initialData, }); } };

asirvadAbrahamVarghese · 2025-09-01T06:21:42Z

app/javascript/components/date-time-picker/index.jsx

+
+  const handlePeriodChange = (event) => {
+    setPeriod(event.target.value);
+    onChange({ value: combinedDateTime(), initialData });


Same as above, due to batched state updates we might want to update combinedDateTime to receive the updated period string:

const combinedDateTime = ({ dateValue, timeValue, periodValue } = {}) => `${dateValue || date} ${timeValue || time} ${periodValue || period}`;

and then from handlePeriodChange pass the updated period value:

const handlePeriodChange = (event) => { const newPeriod = event.target.value; setPeriod(newPeriod); onChange({ value: combinedDateTime({ periodValue: newPeriod }), initialData, }); };

asirvadAbrahamVarghese · 2025-09-01T06:22:00Z

app/javascript/components/date-time-picker/index.jsx

+
+  return (
+    <div>
+      <FormLabel>{field.label}</FormLabel>


Is the label prop expected to always be provided? The label element still gets rendered in the DOM even when no label is provided:

conditionally rendering it can help prevent unused elements in the DOM:
{label && <FormLabel>{label}</FormLabel>}
So that Label won't be rendered:

In this case, {field.label} will always be present. It comes from the dynamic-field-configuration file

defaultDateTimePickerValue: { **label: __('Default value')**, name: 'value', field: 'date-time-picker' },

asirvadAbrahamVarghese · 2025-09-01T06:26:03Z

app/javascript/components/date-time-picker/index.jsx

+  SelectItem,
+  FormLabel,
+} from 'carbon-components-react';
+import { getCurrentDate, getCurrentTimeAndPeriod } from '../service-dialog-form/helper';


Dealing with dates can be bug-prone. we should be fine for now with simple date logics but as logic grows, pulling in a utility like date-fns would help.

asirvadAbrahamVarghese · 2025-12-05T07:22:15Z

app/javascript/components/service-dialog-form/edit-tab-modal/index.jsx

+        schema={createSchema(usedTabNames, tabInfo.name)}
+        initialValues={{
+          tab_name: tabInfo.name,
+          tab_description: tabInfo.description,


Looks like the Edit Tab modal isn’t storing the description field value after saving and reopening:

asirvadAbrahamVarghese · 2025-12-05T07:43:02Z

app/javascript/components/service-dialog-form/edit-field-modal/index.jsx

+  };
+
+  // Custom form template
+  const FormTemplate = ({ formFields }) => {


Better if we can move this FormTemplate component outside of EditFieldModal component
It gets recreated on every render of EditFieldModal

asirvadAbrahamVarghese · 2025-12-05T09:26:50Z

app/javascript/components/service-dialog-form/index.jsx

@@ -0,0 +1,730 @@
+/* eslint-disable radix */
+import React, { useState, useRef, useEffect, useCallback } from 'react';


Looks like useCallback is not used

asirvadAbrahamVarghese · 2025-12-05T09:27:31Z

app/javascript/components/service-dialog-form/index.jsx

+  const dragEnterItem = useRef(null); /** Stores the information of component where the dragged item is being hovered before release. */
+  const draggedItem = useRef(null); /** Stores the information of component being dragged. */
+  const hoverItem = useRef(null); /** Stores the tab and section position during the drop event. */
+  const nextSectionId = useRef(1); /** Counter for generating unique section IDs */


To me it looks neat to use useRef for this, since the counter doesn’t need to cause unnecessary re-renders and the value sticks around
I’m just not sure if there are any downsides compared to using the state managing hooks like useState/useReducer

asirvadAbrahamVarghese · 2025-12-05T09:27:46Z

app/javascript/components/service-dialog-form/index.jsx

+            }
+          }
+        })
+        .catch((error) => {


Do we need to display the API error on the UI so it’s clear what failed? If that’s not required, we could just add an underscore prefix _error

asirvadAbrahamVarghese · 2025-12-05T09:27:50Z

app/javascript/components/service-dialog-form/index.jsx

+    }
+  }, [dialogData, dialogAction]);
+
+  const [isSubmitButtonEnabled, setIsSubmitButtonEnabled] = useState(false);


For complex components, it’s better if we keep all the state up at the top of the component

asirvadAbrahamVarghese · 2025-12-05T09:27:56Z

app/javascript/components/service-dialog-form/index.jsx

+    evaluateSubmitButton();
+  }, [data]);
+
+  const onTabAction = (type, event) => tabAction({


Looks like onTabAction is not used

asirvadAbrahamVarghese · 2025-12-05T09:28:06Z

app/javascript/components/service-dialog-form/index.jsx

+  const [selTab, setSelTab] = useState(null);
+
+  const [showSectionEditModal, setSectionEditModal] = useState(false);
+  const [selSection, setSelSection] = useState(null);


Like mentioned above, better if we can move these states to the top

asirvadAbrahamVarghese · 2025-12-05T09:28:11Z

app/javascript/components/service-dialog-form/index.jsx

+
+
+  const onModalHide = () => setTabEditModal(false);
+  const onModalShow = () => {


Looks like onModalHide & onModalShow are not used

asirvadAbrahamVarghese · 2025-12-05T09:28:26Z

app/javascript/components/service-dialog-form/index.jsx

+
+  /** Function to render the Tab's name. */
+  const renderTabName = (tab) => (
+    <div className="dynamic-tab-name">


I was thinking maybe we could prefix these classnames with the component name, like service-dialog-dynamic-tab-name
I’m just being cautious because while doing the C11 migration, I’ve noticed styles keep getting overridden here and there because of duplicate class names

asirvadAbrahamVarghese · 2025-12-05T09:28:34Z

app/javascript/components/service-dialog-form/index.jsx

+        {renderTabs()}
+      </Tabs>
+    </div>
+  );


I am not sure if these renderTabName, renderSections, renderAddSectionButton , renderTabs, renderTabContents should be moved outside to avoid re-creation on every parent component render

asirvadAbrahamVarghese · 2025-12-05T09:28:39Z

app/javascript/components/service-dialog-form/index.jsx

+      description: data.description,
+      dialog_tabs: data.formFields
+        .filter((tab) => tab.tabId !== 'new') // Filter out the "Create new tab" option
+        .map((tab, index) => ({


Maybe we could turn these filter and map iterations into a single reduce to avoid looping over the array multiple times?

asirvadAbrahamVarghese · 2025-12-05T09:28:59Z

app/javascript/components/service-dialog-form/index.jsx

+          }
+        </div>
+        {/* Form submit/cancel buttons */}
+        <div className="custom-button-wrapper">


Same thought as I mentioned here about class names

asirvadAbrahamVarghese · 2025-12-05T10:45:36Z

app/javascript/components/service-dialog-form/helper.js

+  return result;
+};
+
+const getFieldsInfo = (fields) => {


If there is no other logic to add, we can use parseFieldsInfo directly when required instead of a wrapper getFieldsInfo

asirvadAbrahamVarghese · 2025-12-05T10:45:50Z

app/javascript/components/service-dialog-form/helper.js

+
+const getTabsInfo = (tabs) =>
+  tabs
+    .map((tab) => ({


Like mentioned above we can use reduce instead of map + filter I believe

asirvadAbrahamVarghese · 2025-12-05T10:46:01Z

app/javascript/components/service-dialog-form/helper.js

+});
+
+export const formattedCatalogPayload = (data) => {
+  const payload = payloadForSave(data);


We can do this directly instead of using payloadForSave

export const formattedCatalogPayload = (data) => { const payload = { action: 'create', resource: getDialogInfo(data) }; return payload; };

asirvadAbrahamVarghese · 2025-12-05T10:46:07Z

app/javascript/components/service-dialog-form/helper.js

+  const trimmed = value.trim().toLowerCase();
+
+  const isDuplicate = usedNames
+    .filter((name) => name.toLowerCase() !== currentName.toLowerCase())


I think we can do this using some instead of filter, map and includes

const isDuplicate = usedNames.some((name) => name.toLowerCase() !== currentName.toLowerCase() && name.toLowerCase() === trimmed );

asirvadAbrahamVarghese · 2025-12-05T10:49:30Z

app/javascript/packs/component-definitions-common.js

 ManageIQ.component.addReact('MiqCustomTab', MiqCustomTab);
 ManageIQ.component.addReact('MiqDataTable', MiqDataTable);
 ManageIQ.component.addReact('MiqMarkdown', MiqMarkdown);
+ManageIQ.component.addReact('ServiceDialogForm', ServiceDialogForm);


Do we need to maintain alphabetical order here?

asirvadAbrahamVarghese · 2025-12-05T10:51:43Z

app/stylesheet/ddf_override.scss

    margin-right: 5%;
  }
 }
+// CSS to adjust the UI for field array items in service dialog form


We can remove these if they won’t be required later on...

asirvadAbrahamVarghese · 2025-12-08T10:43:24Z

app/javascript/components/service-dialog-form/helper.js

+};
+
+// Get the current time and period
+export const getCurrentTimeAndPeriod = () => {


Turns out we have moment lib, so may be we could use that to format dates & times:

const now = moment(); return { time: now.format("hh:mm"), period: now.format("A") };

Moment should handle the 12-hour conversion and zero-padding automatically I guess

asirvadAbrahamVarghese · 2025-12-08T10:44:10Z

cypress/support/commands/common.js

+
+// Look for a server error pop up and close if visible
+Cypress.Commands.add('closeErrorPopupIfVisible', () => {
+  cy.get('body').then(($body) => {


This gets called after navigating to 'Customization', is that error coming from an API during navigation maybe only sometimes or is this similar to the session timing bug with memcached? Something like this ⬇️

asirvadAbrahamVarghese · 2025-12-08T11:43:43Z

app/javascript/components/service-dialog-form/index.jsx

+  const renderTabs = () => data.formFields.map((tab, tabPosition) => (
+    <Tab
+      key={`tab${tabPosition.toString()}`}
+      draggable


Should the tabs be draggable too?

Seems like the drop action isn’t working with them

asirvadAbrahamVarghese · 2025-12-08T18:19:35Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/add/checkbox.cy.js

+
+    // Enable Required
+    cy.get('.edit-field-modal input[name="required"]')
+      .check({ force: true });


I’m guessing the force: true is needed because the input is small and Cypress thinks it’s hidden. Maybe we can target the label with the for attribute instead to interact with the input, like we did for the Default Value checkbox:
cy.get('.edit-field-modal label[for="checked"]').click();

asirvadAbrahamVarghese · 2025-12-08T18:19:54Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/add/checkbox.cy.js

+
+  it('should disable save button when label or name is not entered', () => {
+    const getSubmitButton = () => {
+      return cy.get('.edit-field-modal button[type="submit"]')


If you want to make the form element selectors more generic, you can use the selectors from the support commands for buttons, selects, labels, legends, and inputs. But if you’ve got two forms showing at the same time, things could get messy, for example, if you try to target the Cancel button in the modal form while there’s also a Cancel button in the main form, both will match and you’ll end up indexing them, which isn’t reliable I think

asirvadAbrahamVarghese · 2025-12-11T17:54:30Z

cypress/support/commands/customization/service-dialogs.js

+Cypress.Commands.add('navigateToAddDialog', () => {
+  cy.login();
+  cy.intercept('POST', '/ops/accordion_select?id=dialogs_accord'); // May not be needed; added to check the server error shown sometimes
+  cy.intercept('POST', '/ops/accordion_select?id=rbac_accord').as('accordion');


Accordion-select and Tree-select APIs are taken care of at the support command level (accordion & selectAccordionItem), so tests don’t need to handle them anymore unless we need to register a new intercept handler

asirvadAbrahamVarghese · 2025-12-11T18:07:09Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/edit.cy.js

+      .click();
+
+    // Step 10: Save the dialog
+    cy.get('.service-dialog-main-wrapper .custom-button-wrapper button').contains('Submit').click();


If we want to target buttons using their text, it’s probably better to just use contains:
cy.contains('.service-dialog-main-wrapper .custom-button-wrapper button', 'Submit').click();

asirvadAbrahamVarghese · 2025-12-11T18:13:23Z

@jrafanie If you get a chance, can you review the Cypress here?

jrafanie · 2025-12-12T22:29:27Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/add/checkbox.cy.js

+    cy.dragAndDropComponent('Check Box');
+  });
+
+  it('should verify default properties of the checkbox', () => {


just searching for "should verify default properties", I can see each type of checkbox, datepicker, dropdown, etc. has a lot of similar assertions. Maybe they can be refactored to have shared helper functions.

The refactoring doesn't need to happen right now, but we're more likely to do it now vs. later.

jrafanie · 2025-12-12T22:31:33Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/add/checkbox.cy.js

+
+    // Enable dynamic option
+    cy.get('.edit-field-modal input[name="dynamic"]')
+      .check({ force: true });


force: true statements should have an explanation why they're needed... if it's being covered by another element, maybe there's a better way to do it by waiting for the object to be fully visible and accessible.

jrafanie · 2025-12-12T22:40:32Z

cypress/e2e/ui/Automation/Embedded-Automate/customization/service-dialogs/add/checkbox.cy.js

+    cy.openFieldEditModal(0, 0, 0);
+
+    // Initial state - button should be disabled
+    verifyButtonState(true);


instead of the comment, maybe the function call should look like this:

verifyButtonEnabled(false);

Currently, it looks like verifyButtonState(true); expect disabled... and verifyButtonState(false); means enabled which is negative logic. I think this might be easier to read:

verifyButtonEnabled(false); // disabled verifyButtonEnabled(true); // enabled

Or even:

verifyButtonState('enabled'); verifyButtonState('disabled');

(but then you need to check for strings... maybe my first suggestion is clearer. What do you think?

miq-bot added enhancement wip labels Aug 25, 2025

Fryguy reviewed Aug 25, 2025

View reviewed changes

app/javascript/packs/component-definitions-common.js Outdated Show resolved Hide resolved

Fryguy reviewed Aug 25, 2025

View reviewed changes

app/javascript/packs/component-definitions-common.js Outdated Show resolved Hide resolved

Fryguy assigned GilbertCherrie and asirvadAbrahamVarghese Aug 25, 2025

elsamaryv marked this pull request as ready for review August 26, 2025 10:55

elsamaryv requested a review from a team as a code owner August 26, 2025 10:55

asirvadAbrahamVarghese reviewed Aug 27, 2025

View reviewed changes

app/javascript/components/common/inline-flash-message/index.jsx Show resolved Hide resolved

asirvadAbrahamVarghese reviewed Aug 27, 2025

View reviewed changes

asirvadAbrahamVarghese reviewed Sep 1, 2025

View reviewed changes

elsamaryv changed the title ~~[WIP] Conversion of Service Dialogs Form from Angular to React~~ Conversion of Service Dialogs Form from Angular to React Sep 11, 2025

elsamaryv force-pushed the service-dialogs-conversion branch from 78be4a5 to ad336c6 Compare October 7, 2025 09:36

asirvadAbrahamVarghese reviewed Dec 5, 2025

View reviewed changes

asirvadAbrahamVarghese reviewed Dec 8, 2025

View reviewed changes

asirvadAbrahamVarghese reviewed Dec 11, 2025

View reviewed changes

jrafanie reviewed Dec 12, 2025

View reviewed changes

		@@ -0,0 +1,37 @@
		/* eslint-disable no-undef */

		// Look for notification popups and disable them if present

		@@ -0,0 +1,730 @@
		/* eslint-disable radix */
		import React, { useState, useRef, useEffect, useCallback } from 'react';



		const onModalHide = () => setTabEditModal(false);
		const onModalShow = () => {

Conversion of Service Dialogs Form from Angular to React #9592

Are you sure you want to change the base?

Conversion of Service Dialogs Form from Angular to React #9592

Uh oh!

Conversation

elsamaryv commented Aug 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Fryguy commented Aug 25, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elsamaryv Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asirvadAbrahamVarghese Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asirvadAbrahamVarghese Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asirvadAbrahamVarghese Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elsamaryv Aug 28, 2025 •

edited

Loading

asirvadAbrahamVarghese Aug 27, 2025 •

edited

Loading

asirvadAbrahamVarghese Aug 27, 2025 •

edited

Loading

asirvadAbrahamVarghese Aug 27, 2025 •

edited

Loading