FEATURE: Return subcategories on categories endpoint (PR #14492)

When using the API subcategories will now be returned nested inside of each category response under the subcategory_list param. We already return all the subcategory ids under the subcategory_ids param, but you then would have to make multiple separate API calls to fetch each of those subcategories. This way you can get ALL of the categories along with their subcategories in a single API response.

The UI will not be affected by this change because you need to pass in the include_subcategories=true param in order for subcategories to be returned.

In a follow up PR I’ll add the API scoping for fetching categories so that a readonly API key can be used for the /categories.json endpoint. This endpoint should be used instead of the /site.json endpoint for fetching a sites categories and subcategories.

GitHub

We should only run this if the option is present. Otherwise, we’re adding more operations to the default action even if the option is not present and the array is not eventually used.

Minor but the comparison can be moved outside of the loop so the comparison is only done once.

Should we be using a serializer for the categories here?

Is there a reason we need to assign an empty array here?

I would assert that we’re returning the right subcategory in the array here too. A wrong subcategory with the same parent id can be returned and this assertion will still pass.

This will still need to use the same category serializer otherwise we’re sending every single column on the categories table. Some may be sensitive information that should not be exposed to user. Also, we should exclude the subcategory_list attribute from the payload if the option is not present. Otherwise the following is very confusing where the subcategory_ids attribute contain values but the subcategory_list attribute is null.

Screenshot from 2021-10-05 11-36-52

      expect(subcategories_for_category.first["name"]).to eq(subcategory.name)

A commit that appears in this pull request is being discussed here.