Ebrehault listing block

[ebrehault]

Naive implementation.

Comments:

• The call to collect the items is done directly in apps/seven/app/root.tsx, not sure if that's accurate
• I have changed the BlocksFormData type as followed:

export type BlocksFormData = ListingBlockFormData | DummyBlockFormData;

That way we can have a specific typing for each type of blocks instead of having one generic interface with a very unhelpful [x: string]: unknown;.
DummyBlockFormData is there for now as the other specific block types are not existing yet, but it is meant to be removed once everything is properly typed.

---

📚 Documentation preview 📚: https://plone-registry--7603.org.readthedocs.build/

---

📚 Documentation preview 📚: https://volto--7603.org.readthedocs.build/

[davisagli]

I changed the base branch to seven instead of main.

[ebrehault]

I changed the base branch to seven instead of main.

oops, sorry

[sneridagh]

@ebrehault sorry for taking so long to take a look!
It does look good for me so far!

Regarding the typings, I agree the current types are as baseline, we never have been exhaustive on defining them, and we are completing them "on the fly". I am not a TS expert at all, I would leave that to others that know more than me in that regard :)

[sneridagh]

yes, this was the idea, however in the future we should have a generic "visitor" that executes specific extra calls if needed. Using an utilitity for that then call them all and execute them like the rootLoaderDataUtilities.

[ebrehault]

@sneridagh ok, done :)

I was not very comfortable using a very loose typing for the utility method ((...args: any[]) => any), so I have created a more precise typing, and default to the original as DummyUtilityMethod.

That way, you can do things like:

config.getUtilities<ContentSubRequestUtilityMethod>({
  type: 'rootContentSubRequest',
});

and you know for sure what you get.
That's safer.

Ideally, we should bind the typing with the utility type, like when calling getUtilities with type: 'rootContentSubRequest' then we should mandatorily obtain some ContentSubRequestUtilityMethod, but that would change the setUtility and getUtilities signatures, so maybe that should be done in another PR.

[sneridagh]

That's great! We were wondering if we could infer that that automatically in utilities, but this is sufficient, for sure.
Let's do this in another PR, yep.

[ebrehault]

I think my PR is ready.

Last questions:

• not sure why packages/plate/output.css got modified, I did commit it, but not sure I had to
• when adding catalog dependencies in the different packages with pnpm add react-i18next@catalog: --filter @plone/blocks, I saw pnpm-workspace.yaml was modified automatically. My understanding it should not, because catalog is managed in catalog.json. What is the proper pnpm command?