Downshift: [react-native] Button props - Cannot read property activeElement of undefined

[eyalcohen4]

• downshift version: 1.28.0
• node version: 8.5.0
• npm (or yarn) version: 5.6.0
• react-native version: 0.52.0
• react version: 16.2.0

Relevant code or config

What you did:
Hey! tried to use the new and experimental react-native version (Thanks for that!), With Button instead of TextInput as the trigger.

What happened:
Cannot read property activeElement of undefined error has thrown.

Reproduction repository:
https://github.com/eyalcohen4/downshift-react-native-bug

Problem description:
I think its related to the access attempt for document property of environment object, while it's missing on react-native when I print environment.

Suggested solution:
Check if we are in react-native env using isReactNative before this condition -
if ( !isReactNative() && this.props.environment.document.activeElement === this.props.environment.document.body ) { event.target.focus() }

Will be happy to make a PR if it looks like the right solution.
cc @kentcdodds @eliperkins

[kentcdodds]

That solution sounds good to me! What do you think @eliperkins?

[eliperkins]

Hm, I’m not too familiar with what the use-case would be here, but my knee jerk reaction would be that we should still attempt to call focus on the input field, which we should be able to do if there’s a ref for it. But putting the check there for now seems like a nice way to degrade gracefully, rather than throw an error!

_{Sent with GitHawk}

[eyalcohen4]

In my particular example there is only a button -
It's the use case of a drop-down without Auto complete.

maybe we should refocus the button (which is what I think line 569 trying
to achive) in native environment - I'll reaserch for a way to implement
this.

Thanks!

On Mon, Feb 19, 2018, 5:56 PM Eli Perkins [e-mail] wrote:

Hm, I’m not too familiar with what the use-case would be here, but my knee
jerk reaction would be that we should still attempt to call focus on the
input field, which we should be able to do if there’s a ref for it. But
putting the check there for now seems like a nice way to degrade
gracefully, rather than throw an error!

Sent with GitHawk http://githawk.com

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/paypal/downshift/issues/334#issuecomment-366733612,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APhbhvWc1JXaXm4vwjZYWryBkqNCleiNks5tWZmYgaJpZM4SKnkj
.

[kentcdodds]

Hmmm.... The intention of the existing code is to refocus on the target of the event (which is normally the input but could also be a button in the case of a drop-down. I'm not sure how focus works in native mobile apps, but if you do have to manage focus, then we should probably do it in the same way.

[eliperkins]

maybe we should refocus the button (which is what I think line 569 trying
to achive) in native environment - I'll reaserch for a way to implement
this.

I'm not sure that React Native exposes a way to really accomplish "focusing a button" (see this doc on highlighted vs selected state on Collection Views in iOS to get a sense of what native props we might emulate this with), so I'd say for the case of _only_ a button, we're fine with no-op'ing this away on React Native. I still think it'd be good to call focus on the input, if one exists (probably based on what getInputProps was called on). This might be a bit tricky, since I don't think Downshift currently captures a ref for the input.

[kentcdodds]

We used to apply a ref but changed things because it was simpler the way things are now. I'm not opposed to adding a ref back (similar to how getRootProps works, so we'd need an optional refKey as well). I'd prefer to only _use_ the ref for React Native though. Let's leave the current logic as-is for browsers :+1:

[eyalcohen4]

Get it, Cool.
To summarize and make sure I understand - I'll apply a ref as in getRootProps for the input both on web and native, but for now will only use it (in order to refocus) when: button_handleClick called, we are in native environment, and a ref exist.

Let me know if you think or meant something different.
Hope to make it by the weekend,
Thanks for the help, I'm really enjoying using Downshift with react-native.

[eliperkins]

I'll apply a ref as in getRootProps for the input both on web and native, but for now will only use it (in order to refocus) when: button_handleClick called, we are in native environment, and a ref exist.

I think we could get away with only getting a ref when in React Native for now, since that's the only place we'll use the ref. This will help prevent any quirks we might see on web by attempting to get a ref here too.

What do you think @kentcdodds ?

[kentcdodds]

Sounds great!

[trevorwhealy]

Copied the axios example (http://downshift.netlify.com/?selectedKind=Examples&selectedStory=axios&full=0&addons=1&stories=1&panelRight=0), and found the port over to React Native to be pretty easy, but was surprised that any dropdown item I click (or anywhere I click) triggers this ActiveElement error.

Not sure what I'm doing wrong, but happy to add my basic example to the docs, because I don't see any simple starter for a basic working setup with RN. Guessing it has to do with the ref like you mentioned above, but as far as I can tell, I'm doing everything the suggested way.

import React, { Component } from 'react';
import { TextInput, View, Text, Image } from 'react-native';

import axios from 'axios';
import Downshift from 'downshift';

const CustomInput = TextInput;
const CustomResult = View;

const RootView = ({ innerRef, ...rest }) => <View ref={innerRef} {...rest} />;

class AxiosAutocomplete extends Component {
  this.state = { items: [] };

  fetchRepository = axios.get().then(this.setState({ items }))

  render() {
    return (
      <Downshift
        render={({
          getInputProps,
          getItemProps,
          isOpen,
          getRootProps,
        }) => (
          <RootView {...getRootProps({ refKey: 'innerRef' })}>
            <CustomInput
              {...getInputProps({
                onChange: (value) => {
                  this.fetchRepository(value);
                },
              })}
            />
            {isOpen && (
              <View>
                {this.state.items.map((item, index) => (
                  <CustomResult key={index} {...getItemProps({ item })}>
                      {item}
                  </CustomResult>
                ))}
              </View>
            )}
          </RootView>
        )}
      />
    );
  }
}

[kentcdodds]

TREVOR!!!! I miss you already buddy!

This is great. I don't think you're doing anything wrong. If you could dig a little further to see what's going on then we can get that error fixed.

As for an example, I'm not very into the react native world, but I think that a snack.expo.io link would be sweet :)

[andrroy]

@kentcdodds I am getting the same error as @trevorwhealy. In input_handleBlur (see here), setting downshiftButtonIsActive crashes the app because this.props.environment.document is undefined. I'm not familiar with the code in this library, do you have any suggestions on why this is?

[audiolion]

hey was working on an autocomplete component for react native using Downshift and I am encountering the same error. I am not really sure what is causing it yet, if I find out any useful information I will report back here.

Specifically my error is coming from this section:

https://github.com/paypal/downshift/blob/65b2b0cbb450cd5701ff118a18ba2612d2190fe2/src/downshift.js#L764-L768

when I did console.log(this.props.environment.document) I got undefined

Here is Object.keys(this.props.environment):

there is no document there

[kentcdodds]

If you'd like to make a PR to fix this, that'd be welcome :)

[eyalcohen4]

Hey @audiolion, There is a WIP PR for this issue (#368), but I've haven't found the time and the solution yet to solve it. The issue is already solved, but we need to finish the tests. You can check the PR and send me a DM if you need any help.

[audiolion]

@eyalcohen4 thanks for letting me know, I will see if I have some time to pitch in in the coming weeks.

[slavikdenis]

Any progress on this one? What's wrong with https://github.com/paypal/downshift/pull/451 ?

[eliperkins]

@slavikdenis It looks like #451 has some feedback that still needs to be addressed. Would you like to pick it up and address the remaining feedback?

[audiolion]

@eliperkins are we allowed to make changes to hit patch though? or are you saying make a new PR from that PR?

[eliperkins]

Making a new PR that cherry picks that commit/branches from that branch to start from would be your best bet. That way the original contributor gets credit for the work they've done so far! ✨

If you have issues or questions with how to do that, let me know and I'm more than glad to help out.

[samuelfullerthomas]

hey @audiolion & @slavikdenis I've updated my PR if you want to check it out

[kentcdodds]

I think this has been resolved