-
-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<Field> initialValue / defaultValue prop #387
Comments
Up |
up |
1 similar comment
up |
@erikras, any thoughts here? |
Currently, my implementation is a bit hacky. I created a HOC that I wrap my |
@wmertens has also long requested this. I'd accept a PR implementing this. 👍 The idea is to immediately call |
The case where I need this is in a stepper/wizard form where fields are added dynamically depending on previous form values. Because of this, there isn't a way (IMO) to set the |
No, You know, this is a decent case in favor of final-form/final-form#199. 🤔 |
One more thing: there are use cases for both initial and default values. Maybe the naming isn't right, but consider these scenarios:
IMHO, in 1, the form should be dirty and fields should show errors, in 2 the form shouldn't be dirty but the field can already show errors, and in 3 the form shouldn't be dirty and fields shouldn't show errors. Maybe we can also add per-field flags |
Published a solution in |
@erikras it's my understanding and expectation that The current behavior is that I'm passing initial values to a Thoughts on |
Difficult semantics: the date should be set if no initial value is given, but it shouldn't make the form dirty. Perhaps you should set it as initialValue and let it be overwritten by the form iV if that value is present. However, I would expect field iV to overwrite form iV 🤔 |
@crobinson42 @wmertens @erikras I think the new I'm not sure what the right name would be here, but I think something like this would work: const FieldWithDefault = ({ unsetInitialValue, ...props }) => {
const { initialValues } = useFormState({ initialValues: true });
const initialValue = prop.name in initialValues
? initialValues[prop.name]
: unsetInitialValue;
return <Field initialValue={initialValue} {...props} />;
} |
@redbmk I don't agree with this approach:
My reasoning is by lookin at a hierarchy view of a form with who has priority - the closest data provided to a component/input-field should win. |
Yeah, @redbmk, can you make a case for why/when this third overridable field initial value would be useful? |
@crobinson42 I actually thought I was saying the same thing as you
Here's a simplified example of the scenario I'm facing: const initialValues = existingDataFromServer || {}; // empty object for new entries
// form's initialValues
<Form initialValues={data} {...etc} />
// some fields
<label>
<Field type="checkbox" name="showOnDetailReport" unsetInitialValue={true} />
Show on detailed report
</label>
<label>
<Field type="checkbox" name="showOnSummaryReport" />
Show on summary report
</label> My thinking is if you're editing an existing record from the server, I would want to use the data that was already stored. But if you're creating a new record, it should start out with the value given in the field. I used Maybe the right way to do this is when setting the form's initial values: const initialValues = {
showOnDetailReport: true,
...existingDataFromServer || {},
}; It just seemed a little more intuitive to have the field itself declare what its default should be. If that's too much of an edge case or anti-pattern I'm happy to use a workaround. |
@redbmk I think there's a little ambiguity in the comments here 🤪 Here's my understanding...
|
@crobinson42, hmm... I agree with that concept, and that was what I would have expected
I guess what I'm suggesting is either a breaking change for |
I believe defaultValue should be the DEFAULT. That means, if NO initialValue was passed in, the defaultValue would be used. If there is an initialValue, it should override the defaultValue. One work around is using an OR in initialValues and skip using defaultValue all together like so:
The only problem with this if you need the field to be dirty like defaultValue sets it, you wont get it with this method. |
@erikras should we open another issue for further discussion? Sounds like I'm not the only one that would expect |
I think the normal usage would/should be like inline(defaultValue) and header(initialValue) where in the defaultValue will be the value even if there is an initialValue. |
I have to agree, I also expected the functionality to be exactly what @crobinson42 and @redbmk expected. So logic would be something like this: Currently the https://codesandbox.io/s/react-final-form-simple-example-yx7bh |
Agree with @valstu on this too. Wondering if it makes sense to either support it or have a prop for it? Or make |
also agree with @valstu , isn't this how it was in redux form? |
Running into the same challenge with @erikras I am happy to put up a PR for this. We can either:
My current workaround: import get from 'lodash/get';
import { useFormState } from 'react-final-form';
...
const { initialValues } = useFormState({ subscription: { initialValues: true } });
const field = useField('name', { initialValue: get(initialValues, 'name') }); |
@erikras I created a PR to go in line with what was mentioned above. |
@broveloper Thanks for digging into this and getting the ball rolling! I have a question about the implementation though:
I would expect @wmertens suggested:
I'm not sure if this is what he meant, but it might look something like this:
In this case, if
|
@redbmk indeed, this is least surprising API, it looks great |
@redbmk thanks, applied your suggestions Also, i didn't want to complicate this issue with the debate over if it should be I simply wanted to get the ball rolling on having |
bump |
Are you submitting a bug report or a feature request?
feature request
What is the current behavior?
A
<Form>
is required to be providedinitialValues
to set default values for fields.What is the expected behavior?
<Field>
can accept a propinitialValue
ordefaultValue
that is registered with the parent<Form>
's initial values.This would be oober convenient in many cases where fields are dynamically generated or conditionally rendered in the
<Form>
.I'm happy to work up a PR if you're accept/review the effort @erikras
The text was updated successfully, but these errors were encountered: