-
Notifications
You must be signed in to change notification settings - Fork 374
fix: Typing too fast in composer results in dropped characters #4171
Conversation
Composer/packages/adaptive-form/src/components/fields/TextField/TextField.base.tsx
Outdated
Show resolved
Hide resolved
|
I am curious, is there a specific reason for wanting to replicate all of Fabric textfield functionalities? Since we are rebuilding the component from scratch, it is our opportunity to add only what we need. My opinion would be to keep a streamlined input field, like the initial prototypes and make it visually similar to Fabric textfield. In the meantime we can convince Fabric team to update their component / PR against their repo. The challenge with this PR is that since we are importing all the interfaces from office-ui-fabric-react/lib but then re-hardcoding the entire component in Composer, a bump in dependency version would make us diverge more from the TextField offered by the library. Additionally, it is also hard to know what is copied over and what is "ours". |
Composer/packages/adaptive-form/src/components/fields/TextField/TextField.base.tsx
Show resolved
Hide resolved
|
@LouisEugeneMSFT can you look at this again today? |
Composer/packages/adaptive-form/src/components/fields/TextField/TextField.base.tsx
Show resolved
Hide resolved
Composer/packages/adaptive-form/src/components/fields/TextField/TextField.base.tsx
Show resolved
Hide resolved
LouisEugeneMSFT
left a comment
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 looks good to me.
@a-b-r-o-w-n , any other comments?
Description
Root Cause
Our simplified component structure is like
L1: TextField's parent (property editor and\or it's parent)
L2: TextField (hold a local state, uncontrolled value)
L3: Native browser's input which also have a value
A normal workflow is L3's state get changed and propagated to L2 and L2 use local state to set value again to L3, and it's synced.
In our case, L1 component is re-rendered occasionally, which is causing L2 to re-render also, and if it's timing is just at the time L3's value is changed but not being propagated to L2 yet. the changes in L3 will lost and will be override by L2's local state and cursor is moved to the end.
Solution
The first step is a quick fix for this type issue: we fork the TextField component from FluentUI and replace the uncontrolled logic with defaultValue of the native .
For further plan: we need to avoid elements over rendering
Task Item
closes #4102
Screenshots