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

Provide a build with required polyfills, or a separate react-polyfills.js #1507

Closed
steadicat opened this issue May 9, 2014 · 6 comments
Closed

Comments

@steadicat
Copy link

Right now, somewhere buried on the React site, there's a list of polyfills that React requires, with links to a project that has them, intermingled with a bunch of others.

It would be nice if React (optionally) shipped with all the polyfills, and only the polyfills, it needs to function.

This would make it easier for people to fall into the pit of success and build browser-compatible React sites. Also it would save me a bunch of work every time I start a new project.

@syranide
Copy link
Contributor

👍 for Right now, somewhere buried on the React site.

I'm not fond of the idea of bundling it though (for many reasons), they are really useful in being able to leave ugly workarounds in the past. While you may not write code that needs them, the "reusable component" ecosystem would be affected as they would no longer be able rely on the shim/sham being fully available and you end up with people preemptively putting the necessary shims/shams in their "reusable component".

@andreypopp
Copy link
Contributor

Probably dev build can emit an informative warning into browser console if shim is required and is not available.

@petehunt
Copy link
Contributor

+1 andreypopp

@syranide
Copy link
Contributor

@andreypopp 👍

@RReverser
Copy link
Contributor

Is there any expected future work on this or are we fine with #1516 and can close this issue?

@sophiebits
Copy link
Contributor

Nothing planned; I'll close.

josephsavona added a commit that referenced this issue May 15, 2024
#1507 Ensured that declarations of reactive scopes were propagated to parent 
reactive scopes as necessary to ensure that those declarations would be 
available at the appropriate block scope. This meant that some scopes that were 
previously pruned would no longer be pruned. Specifically, an outer scope wo any 
declarations, but which contained a nested scope _with_ a propagated 
declaration, would now end up with non-empty declarations and not be pruned. 

This PR changes to track the declaring scope of each declaration, so we still 
prune scopes that don't have any of their own declarations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants