React-bootstrap-typeahead: component prevents from triggering host form#onSubmit

[hyzhak]

Version

[email protected]

Steps to reproduce

<form onSubmit="() => console.log('on-submit')">
  <Typeahead
          labelKey="name"
          multiple={multiple}
          options={options}
          placeholder="Choose a state..."
        />
</form>

Expected Behavior

should trigger onSubmit handler.

Actual Behavior

does nothing

I have fixed this problem before https://github.com/ericgio/react-bootstrap-typeahead/issues/112 but it seem this bug returned again

[hyzhak]

I see degradation came with this commit https://github.com/ericgio/react-bootstrap-typeahead/commit/a37e11f3c9129400cf2c20eecaa5c1c60b282e3d.

In particular with this version https://github.com/ericgio/react-bootstrap-typeahead/releases/tag/v3.1.0:

Remove submitFormOnEnter prop; essentially a no-op after 02c8a70

How does highlightOnlyResult solve issue with missed form#onSubmit support? Is there any other way to submit form after that?

[ericgio]

Thanks for reporting the issue, I can repro. The actual expected behavior here is that form submission is prevented when the menu is open, but should work like a normal text input when the menu is closed. Commenting out the preventDefault statement doesn't fix the issue, so something else is happening here to prevent the submission and I'll need to dig a bit deeper.

How does highlightOnlyResult solve issue with missed form#onSubmit support?

highlightOnlyResult isn't related to form submission per se, but the code change in that commit essentially made submitFormOnEnter obsolete.

[ericgio]

So it turns out the problem is due to the fact that the Typeahead has 2 inputs (main + hint). According to the W3 input spec:

If the form has no Submit Button, then the implicit submission mechanism must do nothing if the form has more than one field that blocks implicit submission, and must submit the form element from the form element itself otherwise.

In other words, because there are two input elements in the form, submission is automatically prevented.

I'd prefer to keep the hint as an input element rather than change it to a div or something else. I've already gone down that route and it introduces a bunch of subtle display bugs. The question then is: how to make the form ignore the hint input? The only solution I can think of is to dynamically change the hint from a text input to a hidden input when the menu is closed. That allows the hint text to display as needed, but "hides" the input under the expected conditions for form submission.

[hyzhak]

oh, sorry @ericgio! Actually I have submit button in the original form. Where I have found that bug.

And correct jsx is:

<form onSubmit="() => console.log('on-submit')">
  <Typeahead
          labelKey="name"
          multiple={multiple}
          options={options}
          placeholder="Choose a state..."
        />
  <input type="submit"
         style={{position: 'absolute', left: '-9999px', width: '1px', height: '1px'}}
         tabIndex="-1"/>
</form>

actually I'm using AsyncTypeahead there but I don't think it is substantially here.

btw thanks for quick response! I'm trying to update all dependencies in the project in particular use actual version of React (v16) and stuck with [email protected] which drops warning in new React. But at least it propagates onSubmit to host form

[ericgio]

@hyzhak: I no longer reproduce the issue when I add a submit button. Can you please provide a minimal repro case?

[hyzhak]

@ericgio oh, I see I've tried to replicated this case and found that, there was one UI scenario. Which is needed for out case, but now it works differently.

Steps to replicate:
_btw the same scenarios as Facebook, Google or any other similar sites with typeahead input field. So very common UX behaviour_:

1) user types request: "qwerty"
2) typeahead shows options (but there is no "query")
3) user just presses Enter (or similar button on mobile device)
4) form#onSubmit is firing

And it has been working until next version after [email protected].
Sure there is option allowNew but it behaviours differently from what our users expect to see, because requires extra step - user still need to choose that "new option" for some reason, and can't just agrees with "new option" by pressing Enter.

[ericgio]

@hyzhak: Thanks for the additional information. It sounds like your goal is for users to be able to easily submit queries that don't match any results by simply hitting enter. Previously, when a user hit enter for a query with no matches, your form would get submitted (along with the arbitrary query), giving you the desired behavior. Now, however, form submission is prevented when the menu is open, so the desired behavior no longer works. Am I understanding you correctly?

[hyzhak]

@ericgio yes, Thanks! You got it right!

[hyzhak]

@ericgio so, what do you think? Is there any chance to see good-old UI behaviour, as it was before v3.1.0? :)

[ericgio]

The behavior you were seeing before was unintended, if not an outright bug, so what you're asking for is really a new feature that allows users to make arbitrary selections when hitting enter. It's unlikely I'll add that as a first-class piece of the API, but it should currently be possible to achieve what you're after. For example, you could use the typeahead's onKeyDown listener to submit the form when the user hits enter:

<form ref={form => this._form = form}>
  <Typeahead
    ...
    onKeyDown={(e) => {
      if (e.keyCode === 13) {
        this._form.submit();
      }
    }}
  />
  <button type="submit">
    Submit
  </button>
</form>

[karangarg45]

@hyzhak You found any other workaround for this?

[ericgio]

@hyzhak: I know it's not ideal, but I think the workaround above should address your use case. Assuming that's true, I'm going to close this issue as resolved. Let me know if I'm missing something, however.

[aloverso]

@ericgio Appreciate the workaround, my team is also facing the same issue. However, this has opened a new bug for us:

<Typeahead
    ...
    onKeyDown={(e) => {
      if (e.keyCode === 13) {
        this.submitSearch(this.state.selected)
      }
    }}
    onChange={(selected) => {
      this.setState({ selected });
      this.submitSearch(selected);
    }}
  />

Our desired behavior (regarding enter key) is:

1. that a user may type a search query that returns no results in the typeahead options, they may still press enter and allow that search to be submitted.
2. when a user types a search query, uses the arrow keys to highlight a typeahead option, and presses the enter key, the given highlight option should be submitted as the search.

With the above solution, as described by your workaround, we are seeing 2 search queries get submitted when scenario 2 happens. For example, a user types "rea" and selects the option "react", and presses Enter. The onKeyDown event fires, and a search for the query "rea" is submitted. Then, the onChange event fires and a second search query for "react" is submitted. The correct behavior is for only one search to be submitted (the search for the full term, "react")

[ericgio]

@aloverso: if you want a submission to happen during the change event, I'd suggest using allowNew so the custom option shows up in the menu. That way the UX and submission handling is the same for both arbitrary and suggested options. Does that not work for your purposes?