shouldn't it follow our current convention with passing config, as params is not the only property we can pass to axios?

nitpicky, but let's name it as quantityUom and change the UoMType to UomType, as imho it's more JS' way of naming things.

I think lines 13-23 should belong to a custom hook, maybe usePackageSpecification.js and just return quantityUom from it.

You actually have a point about creating a separate hook for that chunk of code, but I think that this should not be a hook directly connected to a subsection, but an options hook, hear me out...

So currently in out app there are many instances where we do the exact thing as I did above for quantityUom.
We fetch these options, store them in redux and access them usually in the same component

So I feel like it should be a pattern for us that we can follow. I suggest creating hooks for this specific case where we dispatch(fetch...) and return this from a selector in that custom hook.

I am unsure about the naming (as always) but my initial suggestion is to follow a naming for hook use....Options and the directory option-data.

What do you think?
@kchelstowski @alannadolny

@drodzewicz good point. I think we could name it like useOptionsFetch, we could pass there the functions:
useOptionsFetch([fetchQuantityUom, ...])
and it the hook itself just map through this list and run the functions.
Although please, remember about adding the AbortController, and also, as a dependency let's add the locale - recently we've forgotten to add it as a dependency, but let's reduce the amount of "translations bugs" that will come up when the crowdin is invoked again.

I don't think we want to create an abstract/generic useOptionsFetch hook, I was thinking about a separate options hook for every other case like I pushed the example for QuantityUnitOfMeasure.
So some example are hooks like useRatingTypeCodeOptions, useInvoiceStatusOptions etc... that could potentially look the same as useQuantityUnitOfMeasureOptions

My reasoning for that is that I want to handle the fetch and a value return in the same hook, and handling a value return would be a little complicated to do in a generic way.

Ok, I misunderstood the intentions.
What I've been thinking about was a generic fetch hook, to which we could pass fetch functions and potentially the dependency array.
I don't think we need to return the options from the hook directly if they are from Redux, since we have a global access for them, but we could also combine our ideas and leave your hook and create one more hook that would be called inside yours, just for fetching stuff (useEffect + dispatch). Let's wait for others to give their opinion on that one.

If you decide to create the usePackageSpecification hook, I think this could be placed there, but you would have to return the setValue from this hook and pass it to the PricingSection from ProductSupplierFormMain component.
But on the other hand I don't mind keeping it there - I just think that such calculations that are strictly connected to a specific section, should be handled in this section's hook.

I'm 50-50 about this one, so I'll let you guys decide.

yes, I see what you mean but I feel like in this case, it is alright to calculate this value in our main hook for product sources. I don't think it adds any complexity to the readability of the code since it is the same place where we transform/manipulate the form data for the API call, but that's my opinion.

if it's on one hand required, why is it nullable additionally?

I think we should add AbortController