Don't treat redundant 'initialValue' at Form.Item level as warning
See original GitHub issue- I have searched the issues of this repository and believe that this is not a duplicate.
What problem does this feature solve?
Currently, if a field is set w/ initialValues prop on the Form component, and again set at the Form.Item level w/ the initialValue
prop, Antd logs a verbose warning in the console: Warning: Form already set 'initialValues' with path 'my_list.0.my_field'. Field can not overwrite it.
This can be especially obtrusive if you have the same component rendered multiple times, thus causing a big wall of red text.
In my view, I think that setting initialValue at both levels should be viewed as okay usage, and the behavior should stay as is but w/o a warning (i.e. the value at the top level is used instead of the value at the Form.Item) This is the case if you initialize the form state w/ existing data when the Form component is first rendered, but would like a default value at the component level if the field is not initially set. In some places we use form.getFieldValue
to check whether the field has been initialized, but in other places this would be quite tedious, and generally I think it is not necessary to have to write out this logic.
Please let me know your thoughts, thank you!
What does the proposed API look like?
No API change. Just stop logging a warning.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:10
- Comments:15 (6 by maintainers)
I think I have the same issue here. I want to initialize my form with the saved values when editing so I put the saved object in the initialValues of the
<Form>
component. However, each<Form.Item>
can have a default/initial value. And in this case, I get lots of annoying error/warning logs. Am I doing something wrong here or this use case is not managed ?I also approve @dobrynin use-case.
Furthermore, Antd documentation (https://ant.design/components/form/#Form.Item) states that:
initialValue | Config sub default value. Form initialValues get higher priority when conflict
When reading this documentation I assume that current behavior (upper level priority) is expected and totally normal. Why the warning if the docs tells you exactly what you can expect? It’s not like it’s a surprise…
If you really want to go for this design, please at least update the documentation. Maybe there is some side-effects we should know about?