Skip to content

feat: support 'editable' prop on TextInput #517

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

Merged

Conversation

pplytas
Copy link
Contributor

@pplytas pplytas commented Aug 22, 2020

Summary

Prevent fireEvent from calling event handlers on TextInput when editable prop is false.
Fixes #476

Implementation:
Added isTextInputComponent() helper function to check if element is a TextInput and if it is then check editable prop instead of onStartShouldSetResponder

Test plan

Added tests for standalone TextInput and TextInput with a nested Text component.

@pplytas pplytas marked this pull request as ready for review August 22, 2020 15:03
src/fireEvent.js Outdated
*/
// eslint-disable-next-line import/no-extraneous-dependencies
const { TextInput } = require('react-native');
return element && element.type === TextInput;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit pick but wouldn't this work here too return element?.type === TextInput

Copy link

@DallasCarraher DallasCarraher Aug 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, I like your first proposal. I'm not sure if proposal 2 is necessary but I'll wait to hear what someone else has to say.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go with 1 for now, we do something similar in src/helpers/getByAPI.js

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch @DallasCarraher!
Went with the 1st approach as suggested.
6cbc3c07a509f1c0f0754e83129e81a30268a87

return <TextInput placeholder={placeholder} onChangeText={onChangeText} />;
};

test('should not be fooled by non-native editable prop', () => {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry maybe I'm naïve or missing something here so I apologize if this is a silly question, but what is this testing? The editable prop isn't being spread / drilled down in your TextInputWrapper so it shouldn't affect the nested TextInput anyway right?

Copy link
Contributor Author

@pplytas pplytas Aug 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm I added this test since we have a similar one for TouchableOpacity above it, but it seems like it is not necessary in the case of TextInput where we don't care about the event propagating to the custom parent component. I'll remove it thanks!

5f861da352b569c124db17b3f93c5e63dd0ccf77

src/fireEvent.js Outdated
@@ -12,10 +34,14 @@ const findEventHandler = (
const handler = getEventHandler(element, eventName);
const hasHandler = handler != null || hasDescendandHandler;

const isHostComponent = typeof element.type === 'string';
const isHostComponent =
typeof element.type === 'string' || isTextInputComponent(element);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please revert this check. host components are always of string type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

74b8c8a28e8957324404b77615288060fc34f9fc

expect(onChangeTextMock).not.toHaveBeenCalled();
});

test('should not fire on disabled TextInput with nested Text', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need for this test, can we remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, this test is also mentioned in #517 (comment).
Should we keep it therefore or remove it?

const NEW_TEXT = 'New text';

const { getByPlaceholderText } = render(
<View>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could add the custom TextInputWrapper here and combine all cases into a single test :)

@pplytas pplytas requested a review from thymikee September 1, 2020 17:21
Copy link
Member

@mdjastrzebski mdjastrzebski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :-)

@pitpitpat thank you for your work!

@pplytas pplytas force-pushed the feature/support-editable-on-textinput branch from 78c1e82 to 95b397a Compare September 7, 2020 19:17
@pplytas
Copy link
Contributor Author

pplytas commented Sep 7, 2020

Squashed the fixups. Ready to go!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support "editable" on TextInput
4 participants