jiebi/CodeConvo huggingface dataset:
Check that they were a part of the latest internal sync. For stable releases, prefer that they’ve been landed for a week or so. Only skip this step if you really know what you’re doing! [x] You’re in [x] You’re in [x] You’re in [x] You’re in If not, ping someone on the team![x] Ensure you’re on [x] Do a . [x] Check that your local output matches the commit list. [x] Run in the repo root.[x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] This might change the lockfile. This should not change any . [x] Commit the changes, if any. (see )[x] Edit: is broken in the 16 branch but this shouldn't block RC, and will be fixed asap by and in [x] Run in the repo root. [x] Run in the repo root. [x] Run in the repo root.[x] Run in the repo root. [x] If changes, [x] Maybe: If we still have a separate branch for docs when you’re reading this, we need to cherry-pick that commit to that branch. This makes sure the website decoder knows about the updated error codes. But ideally we should just change docs to serve from master. (See and ) [x] Update export in [x] Update in all : [x] [x] [x] [x] [x] If you see any other packages, update this list :-) [x] Run to verify your changes. [x][x] Run in the repo root.[x] Open in the browser for a smoke test.
[x] It should say “Hello world!”[x] Go to and run [x] [x] Go to the repo root and run [x] Open http://localhost:5000/fixtures/packaging/ and verify every iframe shows “Hello World!”[x] Run [x] Run [x] Go to [x] For every subfolder: [x] For non-stable versions: Run in the subfolder. [x] For stable versions: Run in the subfolder.[ ] [ ] [ ]
w00t~
I’ve tried to update from react 0.12.2 to 0.13.0 which caused several unit tests of my project to fail. I use react to render html on the server side, this includes the basic html structure like , and elements. All unit tests dealing with such elements are failing with react 0.13.0 but they worked fine with 0.12.2. Here is a minimal example : Running this with react 0.12.2, correctly logs the text content of the title:Running this with react 0.13.0 throws a TypeError
I think this is just a bug, not an intentional breaking change. Thanks for reporting.
This is a followup issue for pmndrs/react-three-fiber From my understanding of , the DevTools parse the version number advertised by the renderer in to select how to parse the internal fiber object. Unfortunately this means that third-party renderers that advertise a version lower than the equivalent React version for the release they are using get misclassified: for instance is using which is equivalent to , and since major version is much lower than it uses the default values for the enum which in turns lead to getting identified as and hook inspection being unavailable. A short term solution for renderers is to advertise a React-compatible version number, but ideally this is an implementation detail of the devtools that users of should not have to be aware of (also this means the version number displayed in the devtools is wrong). I'm not sure I'm familiar enough with the internals of the devtools to open a PR for this, but since the version parsing logic is used to detect features that are internal to anyway I guess a solution would be to have the Reconciler package add its own value for the constant along with the parameters sent to the devtools backend, and have the devtools use this string if its available over the renderer version.
Once and land (and get released) newer versions of the reconciler will inject its own version (to be used instead of the renderer version). Unfortunately this won't help you until you upgrade.
! Edits were made last week to this page, maybe it was broken accidentally?
I guess you use https, but the page loads a script over http and that gets blocked. I made a pull request to fix this . I couldn't test it, so fingers crossed that it is right.
I though we were going to remove this page and let this live entirely in the react-magic repo?
The scripts live in the react-magic repo, but I think we'll keep the page on the React site as it's still really useful there.
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 16.x <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Nothing. It's part of WAI-ARIA 1.3
I guess the question is what React considers a "valid" aria prop: specific version (range) of Aria version with a (WR,CR,PR,REC) spec editors consider the aria prop that ever existed
Yeah, it seems they've support for this fairly recently.
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” React isn’t the source of truth for that information. It sounds like the job of a linter rather than something react should warn about.
I think it might be from a compiler.
It's from here:
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” The reason is that they're often misspelled so on the whole it's beneficial to warn for unknown ones. I'll merge the PR.
Fixed by Will appear in 18.
Not sure if this is intentional, but if I run this: The resulting inner div has its set to . the resulting DOM string is: but if I remove the key the result is: If is used as the key, the result is the latter above.
This is intentional. is an intentional value whereas is the lack of a specified value.
If that's the case then IMHO we should escape it properly, as it is now and are treated equally by React (this should be trivial by translating it to or whatever. Although personally I'm not sure when it ever makes sense to have as a key, how about a warning too?
On the first render it works, but then the update silently fails. Expected would be the semicolon being removed, or an error/warning in the development build. Tested on Chrome latest, Firefox latest, with 0.12.1 and master. Minimal: ran into (on IRC).
My first instinct is to put a warning in DEV so we don't incur any costs in prod. This would be similar to our other style key warning ("you used background-color but probably meant backgroundColor" or whatever it is we say).
sounds reasonable, I don't think there's any valid reason to have a semicolon there.
It's only a warning, but it's worth considering that is valid CSS IIRC.
so that wouldn't warn :)
Oh right :), but I've seen plenty of invalid , but perhaps that's an exercise for some other time. Anyway, you might want to ignore white-space after the as well.
I'm working on this issue. I've a warning, but thinking that it may be a good idea to trim any semicolons as well. The warning will serve to let developers know it's invalid syntax, but try and fix the problem while we're at it.
React version: "eslint-plugin-react-hooks": "^4.2.0" Link to code example: (eslint-plugin-react-hooks) did not fire when it is inside of a Promise block. Please find the detailed explanation in example code below. thx
How do you use hooks inside promises? Hooks should only be called in the body of components
that is right, but I was not aware of it when I code it. And I think should have caught the error. Can you update the code for to make sure the bug won't fall through the crack? To be specific, the hook I was trying to access inside of promise is , which is about injecting the relay environment to handle the GraphQL query/mutation. Because Eslint did not capture this issue, I merged the bug into production until users complained...
This is described in the documentation and any tutorials. I'm not the maintainer of react, but it seems to me that the plugin should not check such things.
I think this issue is actually the anon function, which is reported here: Leaving this open to confirm fixing anon function fixes this.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
React version: 17.0.2 React-refresh version: 0.10.0 This issue is similar to , but ignores default exported unnamed functions instead. As a code comment suggests, this is a known limitation: Would a fix be considered? Given the following files, making changes to doesn't trigger a re-render. module: module: Making changes to does not re-render the element in . The transformed module does not register the for refresh. Making changes to does re-render the element in .
This is intentional — even if we fix this case, we need some heuristic for other tools like lint rules. Why are you using this style? Functions should have names so that you get them in stack traces and so on.
Indeed, but then it becomes confusing: If there's no way around, this can be closed and I'll make a suggestion downstream to use The code comment mentioned above should then also be more explicit, replacing "currently" by "intentionally".
However, given that an ignored component prevents a refresh (), I haven't figured out yet whether this is an issue with itself or with . AFAIK, a code update of an ignored component should still trigger a refresh.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: eslint-plugin-react-hooks to Releases on GitHub there about eslint-plugin-react-hooks to look for a CHANGELOG for eslint-plugin-react-hooks CHANGELOG <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Not code related. <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --No change logs. Change logs on the Releases page for eslint-plugin-react-hooks or a separate CHANGELOG. Especially for major version changes so developers are aware of breaking changes that need to be fixed/prioritised. Thank you.
Please feel free to help out filling that in. Thanks!
Thanks. I tried searching for an existing issue but couldn't find one so I thought I'd mention it. I've gone through the commit history (standard process without release notes) but without existing knowledge of the codebase, it's a bit hard to understand what changes affect the user and how. So I'll leave someone more in-the-know to write it. :bowing_man:
I've created a repo to help illustrate what I'm running into: Basically, developing in pure jsx and using the React.createFactory() are not interchangeable under testing using jest. This makes writing unit tests a little trickier. According to this link: , non-jsx components must be wrapped in a React.createFactory(). But, when testing these components using Jest, I've found that these are not interchangeable within tests that mock sub-modules. I'm guessing that the differences stem from using .bind() within React.createFactory:
updated the aforementioned repo with some possible workarounds. hopefully it saves someone else some time. perhaps the documentation can be expanded with an example.
cc
First of all, thank you for an excellent bug report. Very well structured and easy to test. The bad news is that the various wrappers and undoing of wrappers is very complex. It was difficult to get 0.12 into a form where it was a perfect upgrade path. I guess this is a special case where something broke down. I ended up spending a lot of time on this so I'm inclined to just leave 0.12 as broken. :/ The good news is that this works in the master branch so this will be fixed in 0.13. Would you mind submitting a formal pull request with these unit tests to our tests to ensure that it doesn't break again? The exception is asserting on props on mockComponent. We probably won't support that. is considered legacy at this point. It shouldn't be as important in 0.13, since auto-mocked components works better out-of-the-box. We'll probably encourage shallow testing for this use case.
i'll do my best to get the tests into a PR for your test suite. But, fighting some fires at the moment, so I can't promise a drop date. Thanks for looking into it.
Closing as very outdated.
Do you want to request a feature or report a bug? bug What is the current behavior? does not work, the code is not executed, there are two files loaded from the Facebook servers but they both return a 5xx error If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Go to and then click the link at the bottom to go to and then click on the link to jsfiddle in the text What is the expected behavior? that there is some generated output in the result pane Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Chrome (latest stable, Mac OS), Safari (Mac OS)
That’s a pretty old blogpost. I’m not sure why the integration broke, but I recommend to look at more modern examples (e.g. is up to date).
Well, this blogpost is still linked at the bottom here: So this is how I came there. By reading the guide and I thought I would get an uptodate guide with uptodate links ;-)
Fixed now. The new link is It will appear in the blog post the next time we sync our docs. Thanks!
Great. Thanks too.
At the end, there is a confusing explanation about "Duplicated data from props" in the section "What Shouldn’t Go in State?": Perhaps what is trying to be said is something like:
Ah, perhaps what they're really referring to is basically "edit pages", where you might want to diff the before and after, so that you can send only the changed variables. But it really reads quite weirdly, especially for beginners.
This change is needed. I'm new to React and just did a Google search on that part of the documentation for clarification and it came up with this page. I'm guessing that what you've interpreted it to mean is correct, as it makes sense that way.
This may be controversial, but after browsing StackOverflow I believe there's way too many people that load jQuery when they really don't need it. Let's not add to that. I don't think we should be loading jQuery in the tutorial just to do an AJAX request. Let's instead have a dummy object that just returns a static list. Which could simply be replaced to implement AJAX loading. Old post (before I thought of just using static data): Let's replace it with standard XMLHttpRequest code and say something like "Here's some simple code for doing an AJAX request, alternatively you could use your favourite framework like jQuery, MooTools, YUI, ... instead". Having jQuery loaded in the tutorial may make people think that jQuery is necessary to use React.
I was thinking about this more and using a static list would probably be better than AJAX (given the tutorial just AJAX loads a static file). Updated the description to reflect this.
I think that would be fine. I would still put the equivalent jQuery call because that will be the inevitable question.
After reading pretty much everything related to this issue, I think it would be a good idea to add (for now) a little note in the tutorial, just under the code snippet having the jQuery inclusion. I think it's the only place it really needs to be. What do you think ? (So we can finally close this issue)
Agreed. A beginner tutorial isn't the place to debate jquery vs no jquery. The point is familiarity.
For what it's worth, I removed the use of jQuery in the ReactJS.NET version of the tutorial:
^ The note about jQuery not being mandatory got merged. I think this is good for now for newcomers. The react users probably already realized they don't actually need jQuery. Closing for now! =)
It dose not look very good when you are introducing new people to React and the first ting in the tutorial is: "We need to do some Ajax calls, let's just add jQuery".
H:githubreactgrunt Running "delete-build-modules" task Running "jsx:normal" (jsx) task Warning: This socket is closed. Use --force to continue. Aborted due to warnings. on windows. any hint?
The issue arises in the jsx task at line 42: File: [no files] Warning: This socket is closed. Use --force to continue. Error: This socket is closed. at () at doWrite () at writeOrBuffer () at () at () at (c:reactgrunttasks) at Object.<anonymous(c:reactnodemodulesgruntlibgrunt) at (c:reactnodemodulesgruntlibgrunt) at Object.<anonymous(c:reactnodemodulesgruntlibutil) at Task.runTaskFn (c:reactnode_modulesgruntlibutil) var child = spawn({ cmd: "bin/jsx-internal", args: args }, function(error, result, code) { if (error) { (error); done(false); } else { done(); } }); (JSON.stringify(config.getConfig())); So, looks like the spawn child's input stream is not available. Running node bin/jsx-internal" works however, get a message saying "Warning: still waiting for STDIN after 1000ms"
- can you take a look?
I was able to work around this by changing the following in grunttasks to Obviously this change is Windows-only but does provide a possible workaround.
What about changing it to
Yes, I can verify that worked on my machine. Sorry, I used some leftover code for executing batch files which requires going through cmd.
Cool, I can put up a PR for that (unless you have the time,
Sure, I can do that. Thanks for the help!