question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Default values don't trigger dependencies

See original GitHub issue

Prerequisites

Description

I have a schema with two dependencies, one nested inside the other. I have default values for all of my attributes such that the whole form should be immediately populated once the topmost checkbox is checked. However, default values are only populated as deep as the first dependency.

Steps to Reproduce

  1. Go to playground
  2. Check the Enabled? box
  3. Notice filter_type is populated with its default value, but filters is not shown and therefore has no value. In other words, the default value of filter_type does not trigger the showing of the filters dependency.
  4. Change filter_type to custom and then back to expression. You’ll see that now the filters field shows properly with its default value.

Expected behavior

Because filters is conditionally shown based on the value of filter_type, I would expect that the default value I have set for filter_type would trigger showing filters.

Actual behavior

Even though filter_type has a value that should trigger its dependencies, because its value is initially set via a default value, those dependencies are not triggered by the default value.

Version

1.8.1 or whatever the playground is running

Initial Investigation

What I believe the issue to be is, because the getDefaultFormState is only called once in the Form component (link), the first layer of dependencies is triggered and defaults are returned in the formData parameter for the first layer. However, because the second and deeper layers of nested data are dependent on the previous layer being populated with defaults, they are not triggered.

E.g. In my playground example when enabled is set to true it means the default state can be inferred for filter_type since it is dependent on enabled and enabled is provided as existing inputFormData to getDefaultFormState. However, since filters is dependent on filter_type and since filter_type is not provided in inputFormData the dependencies are not triggered.

To solve this, getDefaultFormState needs to be called more that once until all dependencies have been triggered by all default values. A rudimentary way of accomplishing this would seem to be looping over getDefaultFormState with the output of the previous call being the inputFormData of the next until a deep equals comparison shows that the inputFormData and output formData are equivalent. Although this is likely not the smartest way to solve the problem.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:5

github_iconTop GitHub Comments

1reaction
sampsonbrycecommented, Jun 4, 2020

This issue seems to come from the fact that when traversing down the schema tree and populating defaults, if a default key is found it is prioritized over recursing again.

https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/core/src/utils.js#L171

This line of code checking for the defaults key seems to go against the comment in that function

// Compute the defaults recursively: give highest priority to deepest nodes.

By returning so early if a default key is found, we don’t traverse to the deepest nodes in the tree first. I would changing the order of execution of the function to check for the default key after all recursion has occurred if the intended behavior is to actually go to the deepest nodes first.

Feel free to close this for now though. The issue appears to be resolved by only setting default nodes on fields that are leaves in the schema tree. This can be exemplified in a modified version of the playground listed in the issue description. new playground

0reactions
lucaswimancommented, Oct 14, 2022

It looks like @sampsonbryce’s playground link is working now. Is this still valid?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Problem with "Reset the dependent to its default values if the ...
I have a fresh install of Drupal 7 with a basic dependency created. The dependent and controlling fields are both term reference fields, ......
Read more >
Default value for dependent fields - IdeaExchange - Salesforce
Currently dependent fields cannot have a default value. It is clearly a weakness and a very usefull feature to add.
Read more >
react useEffect trigger although dependency value remain the ...
I have a scenario like this. on first load don't do anything, then if user select an option on the page then do...
Read more >
Have dependent fields default to a value based on controlling ...
I tried field dependencies, but that defaults to the default value of the field (which in this case is --None--).
Read more >
Understanding Dependencies in useEffect | Bits and Pieces
The effect runs after any of these values changes (and after the initial ... And if you were wondering, no, you should not...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found