-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[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! 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
}); | ||
|
||
/** | ||
* The children will be rendered three times: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -21,7 +21,7 @@ import { useState, useRef, useEffect, useMemo } from 'react'; | |||
import { get } from 'lodash'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you referring to the PR4 in the meta? #65654
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes that is exactly what I had in mind 👍
setTimeout(() => { | ||
fn(this.value); | ||
}); | ||
fn(this.value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -63,7 +63,13 @@ describe('<SnapshotRestoreHome />', () => { | |||
expect(find('appTitle').text()).toEqual('Snapshot and Restore'); | |||
}); | |||
|
|||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird, what changes here triggered these failures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.setTimeout
call 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
,waitFor
andwaitForFunc
calls inside the tests to make them deterministic.setup()
to mount component<LoadMappingsProvider />
testsuseRequest
hook but I didn't investigate.Other changes (139ce47)
Fixes #59030
Fixes #65741