the purpose of all those wrappers is that we have the same <div> with the same classNames applied for all of the list pages, so if we wanted e.g. to change any flex settings or anything, we'd have to go through all of the list pages and change it manually.
Those wrappers could be used for all of the list pages we've recently implemented. If you like the idea, we could create a small tech debt ticket to replace the <div>s with those reusable wrappers.

Sounds good, I think we should do it in a separate ticket ASAP.
This change is not complicated and should not take to long to implement, I would hate it if these components were used in one List page and not the rest.
I think they should also be able to receive an optional className prop to have the ability to add custom classes like

const ListWrapper = ({ children, className }) => (
  <div className={`d-flex flex-column list-page-main ${className}`}>
    {children}
  </div>
);

export default ListWrapper;

ListWrapper.defaultProps = {
  className: "",
}

ListWrapper.propTypes = {
  children: PropTypes.node.isRequired,
  className: PropTypes.string,
};

good idea

I think "tabs" is not necessary here, probably

react.productSupplier.details.label=Details
react.productSupplier.preferenceTypes.label=Preference Types

should be enough

why are you using window.location instead of history?

because it's a gsp page

uh ... I forgot about that 🫣🫣🫣🫣

why was this necessary?
Couldn't we use useSearchParams hook provided by react-router library? https://reactrouter.com/en/main/hooks/use-search-params

I wished so, but it's available since react router v6. When I tried bumping it up to v6 just to use this hook, I got many errors, so it's not that straight forward to move from v5 to v6.

I see, what about useParams https://v5.reactrouter.com/web/api/Hooks/useparams ?

I think the purpose of this hook is to return eventual router params, not our custom query params.

you are right, the naming of the hook is quite misleading...
If we have an opportunity It would be good to add a comment in this hook file explaining what is going on.
Just like you mentioned, upgrading to v6 might be a little more complicated than a simple version bump so at the moment this might be not worth it.

I am not too sure about the naming for this color variable.
I think we should stick to previously defined color naming conventions like --gray-90 or --gray-102 whatever group it fits.
Color variable names are hard to get, worse than any other variable.
I think we should treat these variables the following way
--[primary_color_group_name]-[subgroup_index][color_index]
so an example --gray-102 is

• primary_color_group_name: gray
• subgroup_index: 1
• color_index: 02

The issue I have with --gray-border is that we might want to use this color #DFE4ED for something else than a border also what if in the future we need to create a variable for a different border color like #636D82 do we call it
--gray-border-2?

Since Beata has not named this color, I had no idea how to name it (what number I should assign to it), this is why it became gray-border

I think this component should be a bit more generic and receive the tabs configuration as props instead of defining it in the component specific to only PRoduct Sources page.

During planning I foresaw the implementation fo this component in a following way

1. Have a Generic Tabs component which we will be able to use on many different pages in the future.
2. Have it receive a tabs configuration
   In this example something like

const tabs = {
  [DETAILS_TAB]: {
    label: {
      id: 'react.productSupplier.tabs.details.label',
      defaultMessage: 'Details',
    },
  onClick: (key) => switchTab(key)
  },
  [PREFERENCE_TYPES_TAB]: {
    label: {
      id: 'react.productSupplier.tabs.preferenceTypes.label',
      defaultMessage: 'Preference Types',
    },
   onClick: (key) => switchTab(key),
  },
};

3. have it receive and active tab props like example

<Tabs  config={tabs} active={DETAILS_TAB} />

Tabs are something that will also be implemented in PO view page and it would be a shame if we would have to duplicate the code for it.

I have not gone that deep into the future thinking it might be necessary anywhere else, but this is a great idea and I could refactor it, as there is no big change required there.