Extract componenterrors from client

[adrinr]

Description

In order to add some new validation for settings, we added a new system for handling component errors from the builder, in the design section: #15414
We want to aggregate these errors on a view, but given that the previous error checks (required settings and required ancestors) lived within the client itself, we could not show these in the aggregation.
This PR moves this logic out of the client, passing the full responsibility to the builder. Doing so, we will be able to display these errors as it pleases us.

No changes in logic or functionality should apply, as it should behave exactly as it is currently does.

[linear]

BUDI-9016 Display all components errors aggregated

[qa-wolf]

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

[adrinr]

This cannot be merged until the CHECK_COMPONENT_SETTINGS_ERRORS flag is on. Otherwise, the existing error checks will be lost

[aptkingston]

Nice work @adrinr! Much better to have this all controlled by the builder instead.

I was having a play with it locally to check everything, and it looks like there are some differences with required settings for certain components - particularly the chart block. The chart block definition is huge and has many sections which are conditional, but currently it will correctly flag data source as a required setting, then flag label column and data columns as required too, one after each other as you fill them in.

On this branch, once you pick a datasource it does not correctly flag the other settings as missing required settings - it tries to render the chart and the error you get (Add some rows to your datasource to start using your component) is rendered by the chart itself.

On master

First error:

Second error:

Third error:

This branch

First error (correct):

Second error (incorrect, as this is rendering the real component now. The blue border means it's no longer in an "error" state):

I presume this is just something to do with the complicated definition of the chart block, and maybe the component errors are not properly being re-evaluated whenever one error is fixed.

Apart from this, it all looks good!

[adrinr]

Nice work @adrinr! Much better to have this all controlled by the builder instead.

I was having a play with it locally to check everything, and it looks like there are some differences with required settings for certain components - particularly the chart block. The chart block definition is huge and has many sections which are conditional, but currently it will correctly flag data source as a required setting, then flag label column and data columns as required too, one after each other as you fill them in.

On this branch, once you pick a datasource it does not correctly flag the other settings as missing required settings - it tries to render the chart and the error you get (Add some rows to your datasource to start using your component) is rendered by the chart itself.

On master

First error: Second error: Third error:

This branch

First error (correct): Second error (incorrect, as this is rendering the real component now. The blue border means it's no longer in an "error" state):

I presume this is just something to do with the complicated definition of the chart block, and maybe the component errors are not properly being re-evaluated whenever one error is fixed.

Apart from this, it all looks good!

Good catch! This should be fixed with the recent changes. I missed the "sections" in the manifests, so I now reused the current logic for it

[aptkingston]

We have componentStore.getComponentSettings already - does this basically just do the same thing? That function gets all settings for a certain component type and flattens them into a single array, accounting for sections.

[adrinr]

This does not work, as it flattens the list completely. We have some settings, such as Date column that depends on a higher level dependsOn. So we need to iterate trough them instead to be able to see if it's actually required.
To be clear, this code from here is the same that was being used within the client, I just extracted it