Skip to content
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

Make usage of _ in object keys consistent between external and JSX #4348

Closed
alex35mil opened this issue May 5, 2020 · 6 comments
Closed
Labels
stale Old issues that went stale

Comments

@alex35mil
Copy link
Contributor

JSX:

<button type_="button" />

Compiles to:

var React = require("react");

React.createElement("button", {
      type: "button"
    });

external:

type t;

[@bs.obj] external make: (~_type: string) => t = "";

let x = make(~_type="x");

Compiles to:

var x = {
  type: "x"
};

But when bindings to React components meet external, it's required to use prefix form:

module X = {
  [@react.component] [@bs.module "x"]
  external make: (~_type: string) => React.element = "X";
};

So on the call site it's:

<button type_="button" />
<X _type="x" />
@bobzhang
Copy link
Member

bobzhang commented May 5, 2020

Is this your desired behavior or current behavior? It is a bit strange to me where such name mangling happens

JSX:

<button type_="button" />

Compiles to:

var React = require("react");

React.createElement("button", {
      type: "button"
    });

@alex35mil
Copy link
Contributor Author

This is the current behavior.

The desired one is:

type t;

[@bs.obj] external make: (~type_: string) => t = "";

let x = make(~type_="x");

Would compile to:

var x = {
  type: "x"
};

@stale
Copy link

stale bot commented Apr 26, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Old issues that went stale label Apr 26, 2022
@alex35mil
Copy link
Contributor Author

Not stale.

@stale stale bot removed the stale Old issues that went stale label Apr 26, 2022
@DZakh
Copy link
Contributor

DZakh commented Aug 19, 2023

The issue is solved.

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale Old issues that went stale label Oct 16, 2024
@zth zth closed this as completed Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Old issues that went stale
Projects
None yet
Development

No branches or pull requests

4 participants