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.

Sign up for GitHub

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

Jump to bottom

react-native-web support #812

Open
1 task done
zoontek opened this issue Mar 17, 2022 · 8 comments
Open
1 task done

react-native-web support #812

zoontek opened this issue Mar 17, 2022 · 8 comments
Labels
enhancement New feature or request

Comments

@zoontek
Copy link

zoontek commented Mar 17, 2022

Proposal

Hi 👋

I'm currently targetting the web for some react-native libraries (ex: react-native-localize).
It could be nice to add support for react-native-web, as it's well used.

Alternatives

Using react-native-test-app + keeping a package.json with a bundler (vite? webpack?)

Implementation Details

  • Add vite to the project
// vite.config.js

/** @type {import("vite").UserConfig} */
const config = {
  resolve: {
    alias: {
      "react-native": "react-native-web",
    },
    extensions: [
      "web.mjs",
      "mjs",
      "web.js",
      "js",
      "web.ts",
      "ts",
      "web.jsx",
      "jsx",
      "web.tsx",
      "tsx",
      "json",
    ],
  },
};

export default config;
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>react-native-test-app</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="../../example/index.web.js"></script>
  </body>
</html>

Additional Context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@zoontek zoontek added the enhancement New feature or request label Mar 17, 2022
@tido64
Copy link
Member

tido64 commented Mar 17, 2022

I've had a few people ask me about this in the past and my answer has always been "sure, why not". But reality is that I am not familiar with react-native-web, and we don't have any teams using this internally (that I am aware of). That doesn't mean that I can't add support for it, my concern is whether it'll be a good experience for everyone.

If this is something that you have strong opinions about, would you be up for contributing web support?

@LRNZ09 LRNZ09 mentioned this issue Oct 11, 2022
Closed
@kelset kelset mentioned this issue Apr 26, 2024
Open
1 task
@szymonrybczak szymonrybczak mentioned this issue Jul 1, 2024
Merged
@okwasniewski okwasniewski mentioned this issue Sep 18, 2024
Merged
@wcandillon
Copy link

We would be very interested to have Web support for RN WebGPU and Skia

@tido64 tido64 mentioned this issue Oct 30, 2024
Open
@mikehardy
Copy link

It is possible to do this on the side with vite or similar support as Mathieu mentions but it seems just adding support directly for react-native-web should be "The Way", as this is "react-native-test-app", not "react-test-app" - we want to test all the react-native platforms, not test react on all the bundlers and such.

react-native-web uses webpack which gets mediocre sentiment scores in state of JS survey but is obviously widely adopted and known, and (most importantly) webpack is just built in to react-native-web as it's default choice, so we can delegate the "adults disagree" arguments to react-native-web and say "they chose it, we use what they chose"

So, just confirming the "sure, why not" stance, though not committing to doing a PR or any timeline, web support just using react-native-web and all of it's current tech stack choices: would that be of interest + on track for merge?

@tido64
Copy link
Member

tido64 commented Nov 4, 2024

So, just confirming the "sure, why not" stance, though not committing to doing a PR or any timeline, web support just using react-native-web and all of it's current tech stack choices: would that be of interest + on track for merge?

If this is really what one would expect if you were to set up a project with react-native-web yourself, then yes. We want to avoid being "odd" as much as possible in terms of what users expect i.e. the tooling, the commands to execute, etc. are all the same.

The only thing I want to add is would you be willing to own this part? As I've mentioned above, we do not use this internally. If something breaks, it is unlikely that we will ever notice it.

@mikehardy
Copy link

mikehardy commented Nov 4, 2024 •
edited
Loading

Agreed 100% on not being "odd", and that is the basis of my thinking, "let's just do it exactly like react-native-web does it". In fact, if any of the details I posted in my "would this work?" comment above are opposite for how react-native-web already directs you to do it in their docs, I'll switch immediately to just doing what they do. KISS principle, basically, no desire to trailblaze here

I did do some research before posting my comment, and I'll mention one other conditional branch that would direct my work effort here: if react-native-web is agnostic in the area of choosing webpack or next.js or vite or metro whatever, my research indicated that no choice will make everyone happy, but that Vite has largest mindshare currently while being simplest. At same time, Expo uses metro with web support. So I'd have to think carefully there but probably go with a Plan B of metro for it's Expo-related react-native ecosystem presence, with a Plan C of Vite. A truly excellent outcome if possible would be for the bundler to be configurable here, but that might just be a dream.

I'd be willing to own it at least at the start (which for me, historically means like year+ - I commit and de-commit pretty slowly), so should be a stable experience. Ideally I can get some CI set up for you though so it will be noticeable if it breaks, even if it's just me maintaining this bit, right? You guys are great to collaborate in my experience so should work out

@tido64
Copy link
Member

tido64 commented Nov 4, 2024

In fact, if any of the details I posted in my "would this work?" comment above are opposite for how react-native-web already directs you to do it in their docs, I'll switch immediately to just doing what they do. KISS principle, basically, no desire to trailblaze here

Yes, this! We should be able to point people at the official documentation. Differences should be earned.

I'd be willing to own it at least at the start (which for me, historically means like year+ - I commit and de-commit pretty slowly), so should be a stable experience. Ideally I can get some CI set up for you though so it will be noticeable if it breaks, even if it's just me maintaining this bit, right? You guys are great to collaborate in my experience so should work out

CI will definitely be mandatory regardless. I'm a bit concerned about what comes after your commitment is up. I'm under no illusion that anyone will be able to support this for practically forever. But in the worst case, if something happens and it becomes unmaintained, I won't be able to support it. In the best case, it will limp along with no meaningful changes and the occasional breaks that might take a while to address. Worst case, I will probably just axe it. In which case, what would that mean for the current users? Maybe I just worry about nothing and everything will be fine.

Somewhat related, I opened this issue with the intent to make it possible to provide out-of-tree platform support so that people can provide their own platform without having to contribute directly in this repo: #2211

Hopefully, after this lands, it means that people can use react-native-web with their favorite bundler.

@mikehardy
Copy link

#2211 is exactly what I thought as you reiterated your concern above about maintenance
If there was a branch with the basic skeleton for that, perhaps -web and -tvos could be developed at same time - but out-of-tree as plugins to both prove the future-state plugin interface and minimize the risk of unmaintained cruft building up in repo where it seems like it should have first-tier support but was never really planned to?

@tido64
Copy link
Member

tido64 commented Nov 4, 2024

If there was a branch with the basic skeleton for that, perhaps -web and -tvos could be developed at same time - but out-of-tree as plugins to both prove the future-state plugin interface and minimize the risk of unmaintained cruft building up in repo where it seems like it should have first-tier support but was never really planned to?

Yes, I'm mostly thinking about removing RNTA, the repository, as a bottleneck for adding new platforms and enable platforms that are not ready to be unveiled to the public. A nice side-effect of that is that we also minimize the risks. In this world, the current set of platforms (i.e. Android, iOS, macOS, visionOS and Windows) will still live in-repo and be maintained by us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@wcandillon @mikehardy @zoontek @tido64