Nested blocks: discriminator already exists

[chladog]

When I try to define a block fields inside block field I'm getting following error:

throw new Error('Discriminator with name "' + name + '" already exists');
          ^
Error: Discriminator with name "Socials" already exists

Even though that Socials block actually does not exists anywhere else it's just defined inside one of the block a level higher.
I hope that nested blocks are supported as my desired structure is quite dynamic and would be:
repeater array of "rows" => blocks "row content" => block with blocks (e.g. Homepage Jumbo) => "Socials".

Any way to go around this? If nested blocks are not supported, are you planning to feature them?

[DanRibbens]

Hey @chladog,

We should be able to support reusing blocks. There are some particulars we need to decide on around how to set up the discriminator to handle this.

1. When a block slug is being reused, Payload can assume that the block shares the the same model and not recreate it.

   • Pro: cleaner db blockTypes.
   • Con: could appear to be a bug if somebody is trying to make 2 blocks have the same slug but that are in actually different.

2. Allow duplicate block slugs to be defined but iterate on the slug name so that the blockTypes (what we use as the Discriminator) are unique even if they aren't supplied that way.

   • Pro: definitions can be followed exactly as intended by the config whether they are the same or different
   • Con: blockTypes may not perfectly match supplied slugs

There are probably other considerations, though I think either option would allow you to do what you're attempting. Can you share a sample repo or comment with your configuration to reproduce the issue to solve?

[chladog]

When recreating the simplified showcase I found out it was actually working alright all the way until I added localized: true on type: "blocks" and that caused secondary definition of the nested block type under same discriminator.

Here is the showcase, pain point at :55 and :91 in file /collections/Pages.ts

The motivation behind setting localized on blocks and not to upper-level rows is that we want to have same-styled rows in all languages, though their content (blocks) could be slighty different per locale.
I can either move localized: true upper-level to rows for this flexibility with a drawback of the need to redefine rows or can move it deeper to each component fields to minimalize content re-creation, it won't allow us to have different content per locale, but I guess we can live with that for now.

Though now you see the exact point of failure so it might be easy fix for you ;-)

Here is the showcase repo: https://github.com/chladog/nested-blocks-case
File of interest: https://github.com/chladog/nested-blocks-case/blob/master/src/collections/Pages.ts

Regarding you proposals 1) is obviously more efficient and I believe the human-caused slug duplication is not real problem here.
As it can

1. be desired to actually reuse blocks definition in multiple collections.
2. is easily avoidable even on large scale - can create a script that generates slug based on parents slugs, assert non-existent or uids for example.