Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While working on the RecordBoard, I have face a few issues with Record Fields ; mainly, the logic got over complex over the last months as we have added more cases. Especially, we started maintaining an initialValue state, an editMode state, and editValue state.
I've decided to make a first step to make FieldInput and FieldDisplay behave as proper "components". It is still a bit over complex in my opinion but I have removed several states.
Here is how it works after this PR:
Record Store
We maintain a separated record-store recoil state. Ideally, we don't need to have it and we can rely on apollo instead. For now we keep it. Fields assume this record-store recoil state has been populated with the right data.
Use:
useSetRecordInStore
prealably to sync records from apollo in this storeFieldDisplay and FieldInput
The base of FIelds is still FieldDIsplay and FieldInput. Right now they are sharing many useFieldType hooks. I think we should go one step further and introduce useFieldTypeDisplay and useFieldTypeInput. Once done, we can fully separate FieldDisplay from FieldInput components. I also think we should complete the renaming to RecordFieldDisplay and RecordFieldInput
Field Context and FieldInputScope
Right now in the code we are still having both. We need to clarify this as it creates a coupling between TableCell, InlineCell and FieldContext. I think it is fine. Right now, FieldInput and FIeldDisplay expect FieldContext to be setup in the hiearchy
Field Draft Values vs Field Value
I am introducing a "draft value" which is very similar to the field value but accept broader user inputs as we decided to let the user a lot of freedom while typing and then validating the input on cell blur
How to use Fields (summary)
on fieldInput opening (in tableCell or inlineCell), programatically call to populate the draftValue
I think we can still improve a lot the API of FieldInput but I'll stop here for now