generatePermutations Fail for empty flags

[eudago]

There’s an issue that occurs when we run out of flags. The Flags SDK still generates code for the page, which is fine up to that point. The problem appears when we call generatePermutations with an empty array.
I need this because we have an endpoint to revalidate these pages, and if multiple pages have been generated, we need to revalidate all of them.

Example:

export const productPageFlags = [] as const;

const codes = await generatePermutations(productPageFlags);

⨯ TypeError: items.at is not a function or its return value is not iterable
    at cartesianIterator.next (<anonymous>)
    at POST (src/app/(api)/nextjs/api/revalidate/path/route.ts:80:49)
  79 |     if (isProductPage) {
> 80 |         const codes = await generatePermutations(productPageFlags);

If all the flags have been removed because we no longer want to use them, but might want them again in the future, how should we handle this situation?

[dferber90]

You can manually check whether productPageFlags is an empty array and then simply use __no_flags__ or any other url-friendly placeholder as the code, without calling generatePermutations. Since you won't have any flags there will be nothing trying to consume this placeholder string.

I can add support in the SDK itself, but you can use the above as a workaround in the meantime.

[eudago]

The problem is that when you call precompute, it does return a code. In fact, a code must exist, because in the Next.js file routing—besides the slug—we need the code in order to use the Flags SDK.

For now, I’ve implemented a workaround: if the array is empty, I call precompute instead of generatePermutations.

import { precompute } from 'flags/next';

const code = await precompute(productPageFlags);

[dferber90]

You would not call precompute if productPageFlags is empty and instead also use __no_flags__.

In a nutshell

• If flags are empty, skip precompute, skip generateStaticParams.
• If there is at least one flag, use precompute, use generateStaticParams.

We need to adapt precompute and generateStaticParams so they handle this automatically and you won't need to worry about it going forward.

If your solution works in the meantime, that's great too :)