Cannot correctly attach dropdown to button

[wnvko]

Description

I am trying to attach a dropdown to a button. I need my application to build with no errors!

Steps to reproduce

This is my component where I am trying to attach a dropdown to a button:

import {
  IIgrButtonBaseProps,
  IgrButton,
  IgrButtonBase,
  IgrButtonModule,
  IgrDropdown,
  IgrDropdownItem,
  IgrDropdownItemModule,
  IgrDropdownModule
} from 'igniteui-react';
import { useRef } from 'react';

IgrButtonModule.register();
IgrDropdownItemModule.register();
IgrDropdownModule.register();

export default function IgView() {
  const dropdown = useRef<IgrDropdown>(null);
  const button1 = useRef<IgrButton>(null);
  const button2 = useRef<IgrButton>(null);
  const button3 = useRef<IgrButton>(null);

  function buttonClick1(ev: IgrButtonBase<IIgrButtonBaseProps>): void {
    dropdown.current.toggleTarget(ev.i.nativeElement);
  }

  function buttonClick2(ev: any): void {
    dropdown.current.toggleTarget(ev.i.nativeElement);
  }

  function buttonClick3(): void {
    dropdown.current.toggleTarget(button3.current);
  }

  return (
    <div>
      <IgrButton ref={button1} clicked={buttonClick1}><span>Button 1</span></IgrButton>
      <IgrButton ref={button2} clicked={buttonClick2}><span>Button 2</span></IgrButton>
      <IgrButton ref={button3} clicked={buttonClick3}><span>Button 3</span></IgrButton>
      <IgrDropdown ref={dropdown}>
        <IgrDropdownItem><span>Option</span></IgrDropdownItem>
      </IgrDropdown>
    </div>
  );
}

Result

buttonClick1 is able to show the dropdwon on button click. However, the build fails with Property 'nativeElement' is protected and only accessible within class 'ButtonBase' and its subclasses.

buttonClick2 is able to show the dropdown on button click. However, the build fails with Unexpected any. Specify a different type.

buttonClick3 builds successfully but is not able to show the dropdown on button click it fails on run time with element.addEventListener is not a function on _setTarget of dropdown.

Expected result

Should be able to attach the dropdown to a button (or any other component) and show it on click with no build or runtime errors.

[MayaKirova]

@wnvko I’m not sure what the correct behavior here should be.
Technically this refers to the toggle API: https://www.infragistics.com/products/ignite-ui-web-components/docs/typescript/latest/classes/IgcDropdownComponent.html#toggle

Which takes either an HTMLElement or string (which searches for the html element by id), so this variation would be incorrect IMO:

  function buttonClick3(): void {
    dropdown.current.toggleTarget(button3.current);
}

Since what you’re passing will be an Igr component ref and not an element.

The others look correct in the sense that you’re trying to pass an HTMLElement, however I’m guessing that the nativeElement prop is not exposed. The whole implementation object i as a whole I don’t think is intended for public API usage, so it might be better to avoid using it.

So maybe try setting an id and passing it to the method as string?

Or maybe use slots as in the docs to set the target: https://www.infragistics.com/products/ignite-ui-react/react/components/inputs/dropdown#react-dropdown-example
So that the drop-down can find its target more easily.

[wnvko]

@MayaKirova
Actually, exactly what I need is the Target sample from the documentation. However, even in documentation suggestion is to use this code:

this.dropdownRef.toggleTarget(event.i.nativeElement);

which is not correct!

Additionally, dropdown internally is a Web Components wrapped for React. In Web Components I can pass a component instance to the toggle method. In React I cannot do this, and I have no working solution - one which does not log any errors.

IMO this is a bug and React dropdown should accept component instance in its toggle method.

[MayaKirova]

@wnvko In Web Components the component instance is in fact the HTMLElement, so it makes sense to be able to pass it to an API that expects an HTMLElement. In React the components is a complex object that wraps the wc element, so it's not the same thing.

In theory you could just want to pass a normal HTML element in a react scenario as well, lets say a normal button:

  <button onClick={(e) => this.onBtnClick(e)}>Test</button>
  public onBtnClick(e) {
    this.dropdownRef.toggleTarget(e.target);
  }

And if we change the API for the react to expect something else, maybe a React component, we would break that most simple scenario.

Otherwise, I agree that this is incorrect:

this.dropdownRef.toggleTarget(event.i.nativeElement);

As I mentioned i refers to an internal object, so I don't think it should be used in the docs.

[MayaKirova]

@wnvko @dkamburov @ChronosSF Since the original API expects an HTML elements or string and the react wrappers do not change the original method's signature and parameters, the API in React also makes sense for me to expect an HTML element or string.

What I can suggest is a feature request to expose the nativeElement as a public getter from the React wrappers so that it would be easier to get the HTML element. Otherwise the only option for the user would be to use the string override (which is the id) or use slots when dealing with our React wrappers.

Let me now what you think.

[wnvko]

@MayaKirova
Exposing the nativeElement looks good to me.

[dkamburov]

Merged in dev-tool, will come up with the next release

[damyanpetev]

@wnvko @MayaKirova Would that be consistent w/ Blazor? IIRC there's some additional handling that resolves a component or element refs internally, which would've been nice to keep consistent across. Might also be easier to gen, though in the context of React the ideal use would be to assign a target prop to the dropdown and toggle open state instead of a method.
There's might also be slight snag w/ this approach for the future:
Currently, the library uses class components (legacy) which do handle ref={} by default by providing the instance of the component automatically. That's no longer true for Function components - those cannot be given refs, because there's no instance by definition. For those the expectation is to currently forwardRef to a DOM element https://react.dev/learn/manipulating-the-dom-with-refs#accessing-another-components-dom-nodes
Point being, we're likely to move to those and we might want to follow the general pattern that's expected of such components, in which case the extra exposed element will be more/less irrelevant. That also makes methods harder to use, since those need to be exposed on a separately of vary across components.

PS: Whoever did the samples... like why?