I am against using margins. Can we somehow use padding instead?

a question to all of those styles - don't they impact all modals in the system?

Those styles shouldn’t affect all modals in the system because they don’t have classNames like modal-content__header, modal-content__main etc.

it feels like this could be a reusable modal with a table inside, so how about making it a reusable component like ModalWithTable/ModalTable/TableBasedModal - let's decide on the naming .

I mean - we can take the common part to the reusable component, but keep the ConfirmExpirationDateModal component for things that are "unique" for this modal, so calling all the hooks etc. but then just call the reusable component with proper props

you shouldn't call .find in a loop. The map should be built above so that you have O(1) access here.
(No need to refactor it here as it was existing code)

this feels weird, I would like to understand more context of it that we set a state with a promise 🤔

I know it looks a bit weird, but we store the resolve function in the state so that onSave can await the modal response:

const shouldUpdateExpirationDate =
        await this.confirmExpirationDateSave(itemsWithMismatchedExpiry);
      if (!shouldUpdateExpirationDate) {
        return Promise.reject();
      }

When the user responds in the modal ("No"/"Yes"), method handleExpirationModalResponse calls:

    // Resolve the promise returned by confirmExpirationDateSave.
    if (this.state.resolveExpirationModal) {
      this.state.resolveExpirationModal(shouldUpdate);
    }

and this works because we passed "resolve" reference in method confirmExpirationDateSave to this resolveExpirationModal state

and after this we reset the modal state:

    // Close the modal and reset its state.
    this.setState({
      isExpirationModalOpen: false,
      resolveExpirationModal: null,
      itemsWithMismatchedExpiry: [],
    });

I actually was inspired by a similar pattern in AddItemsPage.jsx (inbound return), where confirmAlert returns a Promise and resolves it directly via button callbacks, for example:

  confirmExpirationDateSave() {
    return new Promise((resolve) => {
      confirmAlert({
        title: this.props.translate('react.inboundReturns.message.confirmSave.label', 'Confirm save'),
        message: this.props.translate(
          'react.stockMovement.confirmExpiryDateUpdate.message',
          'This will update the expiry date across all depots in the system. Are you sure you want to proceed?',
        ),
        willUnmount: () => resolve(false),
        buttons: [
          {
            label: this.props.translate('react.default.yes.label', 'Yes'),
            onClick: () => resolve(true),
          },
          {
            label: this.props.translate('react.default.no.label', 'No'),
            onClick: () => resolve(false),
          },
        ],
      });
    });
  }

but I can't (probably) do the same here so I needed to store the resolve in state

thanks for the explanation @SebastianLib. I still don't like it, but on the other hand I don't have any quick idea how to resolve this issue in those old class components.

decide on the naming, either use the *expirationDate everywhere only or *lotExpirationDate

Are those translations fetched?

I didn't fetch translations, but I will change that

thanks for the explanation @SebastianLib. I still don't like it, but on the other hand I don't have any quick idea how to resolve this issue in those old class components.