Pro 6799 design default values invisible fields #4816

ValJed · 2024-11-26T13:31:18Z

PRO-6528

Summary

Adds control over when fields are ready and can be validated, by handling a new fieldReady property for each field.
Must work with async fields like dynamic choices, being able to set a field not ready during fetching and ready when operation is finished.
Reworks schema level convert method. Check errors only when on root convert method to have access to the finale destination object to be able to check non visible fields, as well as non visible parents. No more order problem..

What are the specific steps to test this change?

Cypress tests 🟢

What kind of change does this PR introduce?

Make sure the PR fulfills these requirements:

It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
The changelog is updated
Related documentation has been updated
Related tests have been updated

If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

linear · 2024-11-26T13:31:22Z

PRO-6799 Tech design and quick experiment if possible for setting default values for invisible fields

boutell

I like where you're going with this.

boutell · 2024-11-26T14:25:47Z

modules/@apostrophecms/schema/index.js

@@ -632,6 +632,15 @@ module.exports = {
                }
              );
            } catch (error) {
+              const isVisible = isParentVisible === false


Thank you, I did wonder if there was a cleaner way.

boutell · 2024-11-26T14:26:12Z

modules/@apostrophecms/schema/ui/apos/logic/AposSchema.js

@@ -263,15 +266,15 @@ export default {
      // updating. This is only really a concern in editors that can swap
      // the active doc/object without unmounting AposSchema.
      this.$nextTick(() => {
-        this.schemaReady = true;
+        /* this.schemaReady = true; */


We generally do not use this comment syntax, but maybe you're relying on it to remind you to go back.

This is a draft PR, so not ready for review, it's just for me to have a global vision on my work.

ValJed · 2024-11-27T10:12:38Z

modules/@apostrophecms/schema/index.js

-        const errorsList = [];
+          const isCurrentVisible = isParentVisible === false
+            ? false
+            : await self.isVisible(req, schema, data, field.name);


Notable difference here (previous versions might be buggy). We pass data instead of destination because destination is not fully built at this point.
I think isVisible should compare data as they have been set by the user and not the potential default values.
Tests are green with it but you might have some reasons to not allow this.
Let me know.

Data can be unvalidated stuff of unexpected types etc., it could be anything. Trusting it is problematic. You might get away with that in isVisible because you're not saving the values, but then isVisible must be written carefully to not assume the values are at all well-formed, for instance it must not assume string fields are actually strings yet, etc. because nothing has been validated.

data might contains obsolete values.
You can also have preventFieldsOnly set to true meaning destination will only contains partial fields.
We should think about these and if it has any impact on your implementation.

ValJed · 2024-11-27T13:19:27Z

modules/@apostrophecms/schema/ui/apos/logic/AposSchema.js

-      handler() {
-        this.updateNextAndEmit();
-      }
-    },


We don't need a deep watch here, we can simply call the method when v-model updates fieldState, see above change.

ValJed · 2024-11-27T13:19:40Z

modules/@apostrophecms/schema/ui/apos/components/AposSchema.vue

@@ -52,6 +52,7 @@
        :server-error="fields[field.name].serverError"
        :doc-id="docId"
        :generation="generation"
+        @update:model-value="updateNextAndEmit"


With this, no more need for a deep watcher.

Why not on the compare meta version?

ValJed · 2024-12-02T13:58:27Z

modules/@apostrophecms/schema/ui/apos/logic/AposSchema.js

+          } else {
+            this.next.data[field.name] = this.modelValue.data[field.name];
+          }
+        });


Only indentation in this block

boutell

It is possible that changes are not necessary but see my note here about trusting data, isVisible must be written very defensively if it is going to see unvalidated user input.

boutell · 2024-12-02T14:52:28Z

modules/@apostrophecms/schema/index.js

-        const errorsList = [];
+          const isCurrentVisible = isParentVisible === false
+            ? false
+            : await self.isVisible(req, schema, data, field.name);


Data can be unvalidated stuff of unexpected types etc., it could be anything. Trusting it is problematic. You might get away with that in isVisible because you're not saving the values, but then isVisible must be written carefully to not assume the values are at all well-formed, for instance it must not assume string fields are actually strings yet, etc. because nothing has been validated.

haroun · 2024-12-02T14:14:13Z

modules/@apostrophecms/schema/ui/apos/components/AposSchema.vue

@@ -52,6 +52,7 @@
        :server-error="fields[field.name].serverError"
        :doc-id="docId"
        :generation="generation"
+        @update:model-value="updateNextAndEmit"


Why not on the compare meta version?

haroun · 2024-12-02T15:24:48Z

modules/@apostrophecms/schema/index.js

-        const errorsList = [];
+          const isCurrentVisible = isParentVisible === false
+            ? false
+            : await self.isVisible(req, schema, data, field.name);


data might contains obsolete values.
You can also have preventFieldsOnly set to true meaning destination will only contains partial fields.
We should think about these and if it has any impact on your implementation.

…of deep watching it

…method

…een ran

ValJed · 2024-12-10T09:21:39Z

@boutell @haroun Code could be cleaned but I would like your opinion on the general direction.

ValJed · 2024-12-10T09:22:13Z

modules/@apostrophecms/schema/index.js

+          destination,
+          destinationPath = '',
+          hiddenAncestors = false
+        }) {


This method might be moved somewhere else

ValJed · 2024-12-10T09:23:14Z

modules/@apostrophecms/schema/index.js

+            }
+
+            if (typeof error !== 'string') {
+              self.apos.util.error(error.path + '\n' + error.stack);


Makes sense to me to show what field failed, error path being the name.

I think it is better to log this detail later when logging the overall error. But I wouldn't die on that hill.

Will the error type ever be a string? I believe that went away in A3/A4...

I guess it's smart to check.

boutell

I like the general strategy. Still think it makes more sense to set aposPath on each field just once in schema.validate and its related functions.

boutell · 2024-12-10T19:39:48Z

CHANGELOG.md

@@ -7,6 +7,8 @@
 * Focus properly Widget Editor modals when opened. Keep the previous active focus on the modal when closing the widget editor.
 * a11y improvements for context menus.
 * Fixes broken widget preview URL when the image is overridden (module improve) and external build module is registered.
+* In th schema convert method, we wait all sub convert to run, to have access to the final destination object in order to check if 


boutell · 2024-12-10T19:42:11Z

modules/@apostrophecms/schema/index.js

        } = {}
      ) {
        const options = {
          fetchRelationships,
          ancestors,
-          isParentVisible
+          ancestorSchemas,
+          ancestorPath


I think it is better to compute the aposPath of a field once, in the validate method of schema and its related functions, rather than pushing this boulder up the hill on each convert call 🪨

Yes good point. We agree that we are talking about the schema path and not the actual destination one.

boutell · 2024-12-10T19:44:06Z

modules/@apostrophecms/schema/index.js

+            }
+
+            if (typeof error !== 'string') {
+              self.apos.util.error(error.path + '\n' + error.stack);


I think it is better to log this detail later when logging the overall error. But I wouldn't die on that hill.

Will the error type ever be a string? I believe that went away in A3/A4...

boutell · 2024-12-10T19:44:18Z

modules/@apostrophecms/schema/index.js

+            }
+
+            if (typeof error !== 'string') {
+              self.apos.util.error(error.path + '\n' + error.stack);


I guess it's smart to check.

ValJed self-assigned this Nov 26, 2024

ValJed marked this pull request as draft November 26, 2024 13:31

boutell reviewed Nov 26, 2024

View reviewed changes

ValJed force-pushed the pro-6799-design-default-values-invisible-fields branch 2 times, most recently from 6de153c to 9bbcd21 Compare November 26, 2024 17:22

ValJed commented Nov 27, 2024

View reviewed changes

ValJed marked this pull request as ready for review November 27, 2024 13:17

ValJed requested review from boutell and haroun November 27, 2024 13:17

ValJed commented Nov 27, 2024

View reviewed changes

ValJed commented Dec 2, 2024

View reviewed changes

boutell requested changes Dec 2, 2024

View reviewed changes

haroun requested changes Dec 2, 2024

View reviewed changes

ValJed force-pushed the pro-6799-design-default-values-invisible-fields branch 4 times, most recently from f0a8ef6 to 3fe5a9c Compare December 9, 2024 18:24

ValJed added 11 commits December 10, 2024 10:01

reworks schema convert mehod to make it more understandable

0d499c5

wip

dbc28ab

rollbacks code

a1bb170

fix backend convert method

471f75e

do not run validateAndEmit if field isn't ready

3bb052e

removes comments

be2ec8b

rollbacks aposschema

1e6bd19

removes emit input mixin

082639b

updates logicn in choices mixin

58dc331

updateNextAndEmit when fieldState is udpated through v-model instead …

ee2f0ec

…of deep watching it

adds constant to validateAndEmit to make code more readable

2e2661b

ValJed added 16 commits December 10, 2024 10:01

fix convert method, use data instead of destination inside isVisible …

d137d38

…method

add changelog

fc5666f

removes comments

65df650

reworks to manager fields errors and visible when all converts have b…

9ea5540

…een ran

adds new tests to check schema nesting isVisible detection

96e21d5

mocha tests passing

6dda768

wip trying to keep errors format that is nested

c350d1c

Tests green, keep same error format

e7adaee

working with same errors format, checking for all fields if visible

505a73a

wip tests

647a792

add test

3a1fa44

rename methods

d83e1e6

fixes paths by using only dots

cbf794a

prepares support for relationships (no confitional fields currently)

db94f7c

test nested conditional fields

f8e73cd

lint fixes

2341d53

ValJed force-pushed the pro-6799-design-default-values-invisible-fields branch from 52e6290 to 2341d53 Compare December 10, 2024 09:02

updates changelog

8aae2c7

ValJed requested review from boutell and haroun December 10, 2024 09:20

ValJed commented Dec 10, 2024

View reviewed changes

boutell requested changes Dec 10, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pro 6799 design default values invisible fields #4816

Pro 6799 design default values invisible fields #4816

ValJed commented Nov 26, 2024 •

edited

Loading

linear bot commented Nov 26, 2024

boutell left a comment

boutell Nov 26, 2024

boutell Nov 26, 2024

ValJed Nov 26, 2024

ValJed Nov 27, 2024

boutell Dec 2, 2024

haroun Dec 2, 2024

ValJed Nov 27, 2024

ValJed Nov 27, 2024

haroun Dec 2, 2024

ValJed Dec 2, 2024

boutell left a comment

boutell Dec 2, 2024

haroun Dec 2, 2024

haroun Dec 2, 2024

ValJed commented Dec 10, 2024

ValJed Dec 10, 2024

ValJed Dec 10, 2024

boutell Dec 10, 2024

boutell Dec 10, 2024

boutell left a comment

boutell Dec 10, 2024

boutell Dec 10, 2024

ValJed Dec 12, 2024

boutell Dec 10, 2024

boutell Dec 10, 2024

Pro 6799 design default values invisible fields #4816

Are you sure you want to change the base?

Pro 6799 design default values invisible fields #4816

Conversation

ValJed commented Nov 26, 2024 • edited Loading

Summary

What are the specific steps to test this change?

What kind of change does this PR introduce?

Make sure the PR fulfills these requirements:

linear bot commented Nov 26, 2024

boutell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boutell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ValJed commented Dec 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boutell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ValJed commented Nov 26, 2024 •

edited

Loading