was there a reason it became a .jsx file?

to be honest, I don't know, but I am changing it back to .js

let's chain id and code to follow the convention below.

something doesn't feel right to me about this one. If you need such a flag, it should be a separate flag imho.
I didn't see the context yet, so I would eventually extend the topic in the file where this displayErrorMessage prop is passed.

what's the purpose of that method, what does it do behind the scene? An empty object is truthy, so I assume that this method will always return true, hence the && isRowDirty might not make sense?

This empty object is a fallback in Object.values, so it returns an empty array, and then we are checking if something is true within this array. True means that we entered a value in any field in the row.

I didn't realize the fallback is inside the ( ). I think this shortcut is not intuitive (not passing predicate to the _.some function). This is why I hate lodash for methods that are available in the pure JS 🥲

The naming of this function probably does not make sense.
if has errors on index and is dirty which means that row is invalid, soooo maybe the method should be isRowInvalid ?

what's the purpose of those two consts? Could the name be more intuitive on what it means, not what it does?

After getting to know the context, let's at least name it as invalidLinesButton/validLinesButton

I was bothered about the naming here, so thanks for the suggestion.

the same comment on that one - by reading appliedFiltering it's difficult to understand what's the purpose of that method.
Moreover I think the name of a method should not be an adjective.

what does it change out of curiosity to change from yyyy to YYYY?

This was my mistake during rebase, when I noticed that I didn't replace LL with MMMM DD, yyyy I just changed it by hand. It doesn't matter if this one is yyyy or YYYY

the same comment as somewhere above/below - won't it always be truthy, since an empty object is truthy and so is an empty array?

the same answer as above/below 😆

this is why I said something didn't feel right to me - imho it feels like a workaround. errorMessage is supposed to receive a string message and in this case we pass a boolean.
I think if we need such a case, we should think about making the errorMessage as optional prop and add a new one hasErrors that would handle the logic you need.
I think it would be better than mixing the expected type of the errorMessage and adding displayErrorMessage prop.

Basically, I added a displayErrorMessage prop to avoid having this hasErrors 😆
The idea of this is to avoid passing hasErrors and errorMessage each time. For now, we can only pass errorMessage and this prop is an indicator of whether we have to display an error. The displayErrorsMessage is an additional prop turning on/off the captions under the input field. For me, this is a little bit easier to use than the solution you proposed. I am interested in what other developers think about that, so If they have similar feelings as you, I can change it.

cc @awalkowiak @drodzewicz

on one hand you say:

errorMessage and this prop is an indicator of whether we have to display an error.

so if errorMessage is the indicator, then what the displayErrorMessage is? Imho the errorMessage should NOT be the indicator, because the name says error message, so we expect it to be a string, not a boolean/an indicator.

If we wanted somewhat a compromise, I'd suggest either (I think not recommended since you would have to change it in every place that has been done) changing from errorMessage to error object that would receive message and showMessage properties or......

I'll let the others speak, but I strongly feel like we should not mix the destination of the errorMessage to use it once as a string and once as somewhat an indicator and pass a boolean.

Eh, the errorMessage is a string, if it has content then the error is displayed, if it doesn't the the content is not visible (this is what I meant by indicator here).
The displayErrorMessage is just a prop for showing the caption under the input. If we don't pass it, then the error is visible by default.

Yeah, it should be a string, but you actually pass there hasErrors which is a boolean.
I still don't feel convinced about the approach on that. @drodzewicz @awalkowiak what do you think?

@alannadolny you can do a workaround to Kacpers requirements 😁

const errorMessage = isFieldValid(row.index, 'destinationParty') ? null : 'validation error';
return (
   <SelectField
     options={buyers}
     errorMessage={errorMessage}
     ...

But if we want to be strict with ourselves I think we would need to add an additional isValid prop which would trigger some error classes and such.
Basically, errorMessage prop should only be responsible for the error message and isValid for everything else like red border classes etc..

Perhaps it would be better to move it to const? Would it be possible to give this function a better name, so it's clear what it triggers?

I know this was implemented in a previous ticket but this caught my eye.
You are extracting translate from usePreferenceTypeVariationsColumns hook which I don't think is a good idea. I feel like translate should have it's own independent hook which just returns the translate function from redux.
It can be as simple as

const useTranslate = () => {
  const {
    translate,
  } = useSelector((state) => ({
    translate: translateWithDefaultMessage(getTranslate(state.localize)),
  }));

  return translate;
}

It's just translate doesn't have anything to do with PreferenceTypeVariationsColumns but this hook is returning. I understand that translate is also used inside this hook but still I strongly believe we should separate this.

The naming of this function probably does not make sense.
if has errors on index and is dirty which means that row is invalid, soooo maybe the method should be isRowInvalid ?

I feel like this whole line

Object.keys(errors).filter(isRowValid).length

should be returned from usePreferenceTypeVariationsFiltering hook as invalidRowCount or something similar.

could maybe move this arrow function to a declared function to have context on what it's doing?
like

const addNewLine = () => {
   prepend(defaultTableRow);
   triggerValidation('productSupplierPreferences');
}

a lot of nested characters, can we split this up a bit 😅

const fieldError = errors?.[index]?.[property];
const fieldErrorMessage = fieldError?.message || fieldError?.id.message;