Tan 3576/useideastatuses variant usage

[brentguf]

Make participation_method query param required for useIdeaStatuses.

This work started because I thought there was a bug, but there wasn't. It's still an improvement worth merging, IMO. We'll have more explicit code that potentially prevents bugs (in case someone forgets to add the participation_method).

Changelog

[notion-workspace]

useIdeaStatuses: streamline variant usage

[IvaKop]

I agree with the idea of making the participation method more explicit but in this case it appears you are making now two requests to get the statuses separately which is more inefficient. Is there a way to get all the statuses at once and map them as options? Or is the ordering the issue here?

Also, I see the smart group component is specifically about idea statuses. I'm sure you considered this but just to double-check that we are sure it also works well with proposals.

[brentguf]

@IvaKop

I agree with the idea of making the participation method more explicit but in this case it appears you are making now two requests to get the statuses separately which is more inefficient. Is there a way to get all the statuses at once and map them as options? Or is the ordering the issue here?

There was no issue if with "issue" you meant a bug.

Smart group creation was the only instance left where we were not passing a participation_method when using useIdeaStatuses. We were getting all statuses (both ideation and proposals statuses) at once. This PR makes things consistent by requiring the participation_method param, which means we'll have two requests now, indeed.

I think the performance cost of two requests vs. one request here is negligible. The requests only occur in the back office when we've selected the status filter on smart group creation and the number of statuses is usually limited.

Also, I see the smart group component is specifically about idea statuses. I'm sure you considered this but just to double-check that we are sure it also works well with proposals.

It's a list of ideation and proposal statuses combined. With the new code, we still list both ideation and proposal statuses, indeed. 🙂

[IvaKop]

@brentguf I see, thank you for the context and the explanation. 🙌
I think it would be preferable to have a mechanism to fetch all the statuses at once instead of having to make separate API calls. I agree the performance cost is low but there is also added complexity that comes with fetching them separately. In addition, the approach you are using will not work easily with pagination (which, granted, is not a problem today).

I agree with you the old approach is not super explicit, though. I suggest we add a third option for participation_method - something like all, instead of having to fetch them separately and then re-combine them. Adding all as an option feels like a minimal change that would keep in place the benefit of your work while circumventing the issues above. Wdyt?