You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible to change the value of a TextInput that has a maxLength prop. The following test fails for instance :
test('it should not allow to write a text longer than maxlength in a text input',()=>{constTestComponent=()=>{const[value,setValue]=useState('');return(<RNTextInputplaceholder="placeholder"maxLength={1}onChangeText={setValue}value={value}/>);};render(<TestComponent/>);fireEvent.changeText(screen.getByPlaceholderText('placeholder'),'text');screen.debug();expect(screen.queryByDisplayValue('text')).toBeFalsy();});
Expected behavior
I'd expect that only the substring of length equal to maxlength is set as value.
Regarding the implementation I'm not sure though if this should be done by fireEvent because it just calls props and we'd have to check what the event is and have special checks in that case so maybe it's something that should be done once we have an implementation of userEvent.type. So actually I'm saying this is not really a bug but rather a use case that userEvent.type should support
The text was updated successfully, but these errors were encountered:
@pierrezimmermannbam that would fall under environment simulation category. I'm not sure whether this is worth adding since this feature would simulate RN env for test, while not really guaranteeing that RN will behave the same. If this is something that concerns you you can do it, however as part of the research please analyse how real RN apps behave regarding this prop under iOS and Android. Atm the right place would be fireEvent implementation.
Describe the bug
It is possible to change the value of a TextInput that has a maxLength prop. The following test fails for instance :
Expected behavior
I'd expect that only the substring of length equal to maxlength is set as value.
Regarding the implementation I'm not sure though if this should be done by fireEvent because it just calls props and we'd have to check what the event is and have special checks in that case so maybe it's something that should be done once we have an implementation of userEvent.type. So actually I'm saying this is not really a bug but rather a use case that userEvent.type should support
The text was updated successfully, but these errors were encountered: