[form lib] Fix issues + add test coverage#64647
Conversation
|
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
|
@elasticmachine merge upstream |
04f97bb to
886c653
Compare
|
@elasticmachine merge upstream |
|
@XavierM I set you as reviewer. You don't need to review the code, I mainly want to make sure the changes in the form lib did not create any regressions in your forms. Cheers! 👍 |
jloleysens
left a comment
There was a problem hiding this comment.
Read through the code and most of the changes make sense to me! Great work @sebelga .
Left a few comments, but nothing to block on.
| @@ -21,7 +21,7 @@ import { useState, useRef, useEffect, useMemo } from 'react'; | |||
| import { get } from 'lodash'; | |||
There was a problem hiding this comment.
I did not see changes to the returned form object to prevent update loops for form subscribers. IIRC I did see form.subscribe being wrapped in a useCallback? I assume that change was made somewhere else?
There was a problem hiding this comment.
Are you referring to the PR4 in the meta? #65654
There was a problem hiding this comment.
Ah yes that is exactly what I had in mind 👍
| setTimeout(() => { | ||
| fn(this.value); | ||
| }); | ||
| fn(this.value); |
There was a problem hiding this comment.
I recall talking about this observable previously, what issue was this causing (and what does executing sync fix)?
There was a problem hiding this comment.
This was one of the guilty to create latency and flakiness in the tests. We want to be as synchronous as possible and having to wait the next tick had some weird consequences in a
<FormDataProvider pathsToWatch="type">
// We want this logic to render immediately.
</FormDataProvider>Going synchronous made it all work as expected.
|
|
||
| test('should display a loading while fetching the repositories', () => { | ||
| /** | ||
| * TODO: investigate why we need to skip this test. |
There was a problem hiding this comment.
Weird, what changes here triggered these failures?
|
Thanks for the review @jloleysens ! Let me know if "I did not see changes to the returned form object to prevent update loops for form subscribers" is indeed the PR4 that I planned on doing or if it something else 👍 Cheers! |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
XavierM
left a comment
There was a problem hiding this comment.
I tested all the forms in the SIEM app and I did not see any problems due to all this good work. Thanks @sebelga to make our life easier.
I am wondering if it will be possible to get the FormDataProvider to respect the props pathsToWatch. It is still being executed even if the field changing is not the one set in the props pathsToWatch. If you are interested, I can show you but it is still the same behavior as before.
|
Thanks for the review @XavierM ! The current issue is that whenever the form object changes, the |


This is the first of several PR to get the form lib ready for
v1.0.0. See the meta issue (#65654) for the detail plan.Adding the tests revealed in the discovery of an issue in the lib. Fixing the issue lead to fixing the consuming code (mainly the mappings editor) and fixing the tests. At the same time, I finally realized why we had so many flakiness in the CI for our component integration tests and hopefully got rid of it for the mappings editor (we still might have other falkiness elsewhere but that was out of scope for this PR).
I re-wrote the git history with the following commit
Testbed (029db06)
Form lib tests (3c9c232)
Initial tests for the public API of
useForm()<Form /><UseField /><FormDataProvider />From lib fixes and refactors (7d20029)
<UseField />to forward any unknown prop to the children component<UseField />formData$with an empty object. This allows us to be declarative: what is declared in the JSX is what we get out of the form.new Subject()memory leak. There is now a getter (getFormData$()), this avoids creating a new instance of the Subject on each re-render.setTimeoutcall in the Subject class. We want to be as synchronous as possible.form.getData()that was not passing the returned data through theserializer.Mappings editor fixes and refactors (6a60f57)
<EditField />that was warpping the whole content with a<FormDataProvider />.The EditField component was wrapping the whole content with a FormDataProvider, watching for the "type" and "subType" changes (but declaring them inside its children() render). This was a very bad design and it is not supported anymore as the fields now need to be present in the DOM in order to have their data populated and thus being able to subscribe to their changes.
<SubTypeParameter />used in both places.Fix tests (d12ac63)
nextTick,waitForandwaitForFunccalls inside the tests to make them deterministic.setup()to mount component<LoadMappingsProvider />testsuseRequesthook but I didn't investigate.Other changes (139ce47)
Fixes #59030
Fixes #65741