jiebi/CodeConvo huggingface dataset:
Change:
I'm trying to programatically invoke the JSX transformer (using the version of in the npm registry) by running something like Which then throws this error: If I comment out the lines in that require/use the module loads fine and the transformer runs correctly.
Bah, I changed build filenames last minute and didn't properly test the module after :( Thanks for finding this! I guess we should write some tests for the node module too, not just our phantomjs tests. (Very) Short term, you should be able to change to and that will fix the problem. - I guess it's time to figure out what we want to do with npm versions vs library versions. Should we just bump them both for the time being?
Nope, that alone won't do it, we're not even packaging. I totally screwed up the node module :( Fix soon!
Yeah, doesn't look like there's even a directory there. :)

Discussion:
'use strict'; <del> var React = require('./build/React'); </del> <ins> var React = require('./build/react'); </ins> var visitors = require('./vendor/fbtransform/visitors').transformVisitors; var transform = require('./vendor/fbtransform/lib/transform').transform;

"README.md", "main.js", "bin/jsx", <del> "build/React.js", </del> <ins> "build/react.js", </ins> "vendor/fbtransform/", "vendor/woodchipper.js" ],
Change:
Please make "requireable" npm release, already fixed and only new version on npm is needed. I've developed a source transform for JSX for browserify — which doesn't work properly because of
1 pushed to npm:

Discussion:
} async function createBundle(bundle, bundleType) { <del> if (shouldSkipBundle(bundle, bundleType)) { return; } </del> const filename = getFilename(bundle, bundleType); const logKey = chalk.white.bold(filename) + chalk.dim(` (${bundleType.toLowerCase()})`);

); } <ins> bundles = bundles.filter(([bundle, bundleType]) => { return !shouldSkipBundle(bundle, bundleType); }); </ins> if (process.env.CIRCLE_NODE_TOTAL) { // In CI, parallelize bundles across multiple tasks. const nodeTotal = parseInt(process.env.CIRCLE_NODE_TOTAL, 10);
Change:
Trying to run jsx to build into a subdir seems to just exit with no error message: (public/js does exist) However, if run in directly in public it works without a hitch:
Are there any files in yet? Also potentially useful: what are you running, and what OS?
There is a file in src which builds when not using a subdir in the public dir. node version is 0.8.23 and im on OS X Mountain Lion
Installed 0.8.23 but no luck reproducing. Will try on a Mountain Lion machine tomorrow. Thanks for the report. Do you see this failure with an empty file? If using an empty file makes the failure go away, perhaps you can try cutting out different parts of the file to figure out the minimal contents that trigger the failure? It could be a problem with on Mountain Lion, though. That's my hunch.
One more idea: the module cache might have gotten into a bad state somehow. Try clearing it by deleting the directory ?
The same file builds fine if I use (note the lack of public/js). Deleting that directory didn't work for me.
I know this is still broken. Still working on a fix.
:heart:
I had same problem on ubuntu. Yesterday "jsx --watch" worked just fine for me. Today when I ssh-ed again and ran "jsx --watch reactjs/ js/" it just silently does nothing.
- I was having issues w/ vim file writes not being caught so I hacked together - Feel free to try it and let me know if it works (Haven't had the time to test on Ubuntu yet...) - We might use the file watcher in that repo in Commoner / JSX in the future.
:+1: Work like a charm. Thank you very much!
Ok. I think I now know what the issue is. jsx created a file in the output directory. If that file is still there when running jsx again it will quick silently.
Awesome!

Discussion:
}, "dependencies": { "base62": "~0.1.1", <del> "commoner": "~0.8.0", </del> <ins> "commoner": "~0.8.3", </ins> "esprima": "https://github.com/facebook/esprima/tarball/a3e0ea3979eb8d54d8bfade220c272903f928b1e", "recast": "~0.4.8", "source-map": "~0.1.22"
Change:
:+1:
+1
+1
I'mma jump on the :+1: bandwagon too. Great idea.
I don't want to keep duplicated issues opened so just to sumup: said it makes sense to implement "namespacing" using colons as opt-in, config-defined option, where one of the possibilities would be a member expression. I don't have enough time to implement it this way, so I closed my issue. More on why&how in jeffmo's final comment and in in general
+1
+1
A non JavaScript-first implementation that wouldn't require changes to :
PR landing for JSX member expressions , can close this.

Discussion:
utils.catchup(openingElement.range[0], state, trimLeft); <del> if (nameObject.namespace) { throw new Error( 'Namespace tags are not supported. ReactJSX is not XML.'); </del> <ins> var isFallbackTag = false; if (nameObject.type === Syntax.XJSIdentifier) { if (nameObject.namespace) { throw new Error( 'Namespace tags are not supported. ReactJSX is not XML.'); } isFallbackTag = FALLBACK_TAGS.hasOwnProperty(nameObject.name); </ins> } <del> var isFallbackTag = FALLBACK_TAGS.hasOwnProperty(nameObject.name); utils.append( (isFallbackTag ? jsxObjIdent + '.' : '') + (nameObject.name) + '(', state ); </del> <ins> utils.append(isFallbackTag ? jsxObjIdent + '.' : '', state); utils.move(nameObject.range[0], state); utils.catchup(nameObject.range[1], state); </ins> <del> utils.move(nameObject.range[1], state); </del> <ins> utils.append('(', state); </ins> var hasAttributes = attributesObject.length;
Change:
This makes it basically unusable in any nontrivial project. While people shouldn't be using this in production, we should still fix this bug for newbies and people using it for hackathons.
This should be relatively easy. What should we do with inline tags?

Discussion:
var inlineScriptCount = 0; <ins> // This method returns a nicely formated line of code pointing the // exactly location of the error `e`. // The line is limited in size so big lines of code are also shown // in a readable way. // Example: // // ... x', overflow:'scroll'}} id={} onScroll={this.scroll} class=" ... //                                 ^ var createSourceCodeErrorMessage = function(code, e) { var sourceLines = code.split('n'); var erroneousLine = sourceLines[e.lineNumber - 1]; // Removes any leading indenting spaces and gets the number of // chars indenting the `erroneousLine` var indentation = 0; erroneousLine = erroneousLine.replace(/^s+/, function(leadingSpaces) { indentation = leadingSpaces.length; return ''; }); // Defines the number of characters that are going to show // before and after the erroneous code var LIMIT = 30; var errorColumn = e.column - indentation; if (errorColumn > LIMIT) { erroneousLine = '... ' + erroneousLine.slice(errorColumn - LIMIT); errorColumn = 4 + LIMIT; } if (erroneousLine.length - errorColumn > LIMIT) { erroneousLine = erroneousLine.slice(0, errorColumn + LIMIT) + ' ...'; } var message = 'nn' + erroneousLine + 'n'; message += new Array(errorColumn - 1).join(' ') + '^'; return message; }; </ins> var transformCode = function(code, source) { var jsx = docblock.parseAsObject(docblock.extract(code)).jsx; if (jsx) { <del> var transformed = transformReact(code); </del> <ins> try { var transformed = transformReact(code); } catch(e) { e.message += 'n    at '; if (source) { if ('fileName' in e) { // We set `fileName` if it's supported by this error object and // a `source` was provided. // The error will correctly point to `source` in Firefox. e.fileName = source; } e.message += source + ':' + e.lineNumber + ':' + e.column; } else { e.message += location.href; } e.message += createSourceCodeErrorMessage(code, e); throw e; } </ins> var map = transformed.sourceMap.toJSON(); if (source == null) {

runScripts = function() { var scripts = document.getElementsByTagName('script'); // Array.prototype.slice cannot be used on NodeList on IE8 var jsxScripts = []; for (var i = 0; i < scripts.length; i++) {

jsxScripts.push(scripts.item(i)); } } console.warn("You are using the in-browser JSX transformer. Be sure to precompile your JSX for production - http://facebook.github.io/react/docs/tooling-integration.html#jsx"); jsxScripts.forEach(function(script) {
Change:
See Return a string from and call . You get this amazing error message:
We should probably add an that whatever is returned from is in fact an object.
Invariant all the things :)
This also seems to apply when using an array, not the string only. Which makes it a pretty real-world bug IMHO (compared to the weird string scenario). Or is there a reason you don't want states to be arrays?
This will happen whenever state is anything but an Object (I think there is a check in there for arrays). Since we use merge it needs to be an object, arrays are no good either.

Discussion:
} this.state = this.getInitialState ? this.getInitialState() : null; <ins> invariant( typeof this.state === 'object' && !Array.isArray(this.state), '%s.getInitialState(): must return an object or null', this.constructor.displayName || 'ReactCompositeComponent' ); </ins> this._pendingState = null; this._pendingForceUpdate = false;

); }); <ins> it('should work with a null getInitialState() return value', function() { var Component = React.createClass({ getInitialState: function() { return null; }, render: function() { return <span />; } }); expect(() => <Component />).not.toThrow(); }); it('should work with object getInitialState() return values', function() { var Component = React.createClass({ getInitialState: function() { return { occupation: 'clown' }; }, render: function() { return <span />; } }); var instance = <Component />; ReactTestUtils.renderIntoDocument(instance); expect(instance.state.occupation).toEqual('clown'); }); it('should throw with non-object getInitialState() return values', function() { [['an array'], 'a string', 1234].forEach(function(state) { var Component = React.createClass({ getInitialState: function() { return state; }, render: function() { return <span />; } }); var instance = <Component />; expect(function() { ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: Component.getInitialState(): ' + 'must return an object or null' ); }); }); </ins> it('should detect valid CompositeComponent classes', function() { var Component = React.createClass({ render: function() {
Change:
Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)

Discussion:
var children = {}; var childMapping = ReactTransitionKeySet.getChildMapping(sourceChildren); var transitionConfig = this.getTransitionConfig(); var currentKeys = ReactTransitionKeySet.mergeKeySets( this._transitionGroupCurrentKeys,

* in `next` in a reasonable order. */ mergeKeySets: function(prev, next) { <ins> prev = prev || {}; next = next || {}; </ins> var keySet = {}; var prevKeys = Object.keys(prev).concat([MERGE_KEY_SETS_TAIL_SENTINEL]); var nextKeys = Object.keys(next).concat([MERGE_KEY_SETS_TAIL_SENTINEL]);

// Most of the real functionality is covered in other unit tests, this just // makes sure we're wired up correctly. describe('ReactTransitionGroup', function() { <ins> var container; </ins> beforeEach(function() { React = require('React'); ReactTransitionGroup = require('ReactTransitionGroup'); mocks = require('mocks'); <ins> container = document.createElement('div'); </ins> }); it('should warn after time with no transitionend', function() { <del> var container; var a; container = document.createElement('div'); a = React.renderComponent( </del> <ins> var a = React.renderComponent( </ins> <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" /> </ReactTransitionGroup>,

}); it('should keep both sets of DOM nodes around', function() { <del> var container = document.createElement('div'); </del> var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" />

expect(a.getDOMNode().childNodes[0].id).toBe('two'); expect(a.getDOMNode().childNodes[1].id).toBe('one'); }); <ins> describe('with an undefined child', function () { it('should fail silently', function () { var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> </ReactTransitionGroup>, container ); }); }); </ins> });

five: true }); }); <ins> it('should support mergeKeySets with undefined input', function () { var prev = { one: true, two: true }; var next = undefined; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ one: true, two: true }); prev = undefined; next = { three: true, four: true }; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ three: true, four: true }); }); </ins> });
Change:
I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .

Discussion:
var getDebugConfig = function() { return { "debug": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

return { "debug": true, "mocking": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

getConfig: function() { return { "debug": false, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": false

"engines": { "node": ">=0.10.0" }, <del> "preferGlobal": true </del> <ins> "preferGlobal": true, "commonerConfig": { "version": 1 } </ins> }
Change:
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".

Discussion:
For the remainder of this tutorial, we'll be writing our JavaScript code in this script tag. <ins> > Note: > > We included jQuery here because we want to simplify the code of our future ajax calls, but it's **NOT** mandatory for React to work. </ins> ### Your first component React is all about modular, composable components. For our comment box example, we'll have the following component structure:
Change:
Here's an example: (no jsfiddle because that's broken in IE8)
I tried to fix this bug yesterday but had a bad time trying to find a fix for a similar cases. I looked at current well maintained libraries and didn't find a way to make scroll bubble or capture it on IE8. Seems like trying to fix it would be a waste of time and would make code much complex, for a browser that is slowly dying. My suggestion is to point that out on the documentation.
Seems like this isn't so easy. Let's do what says and document it.
do you think that we should do a everytime someone uses onScroll on any browser or would that be annoying? I would say it would be annoying but it would also be very frustrating to figure that it's a React limitation after some hours of debugging on IE8 (ugh!)
+1 on the warning -- would be super helpful.
reopening so we can add a warning
Warning was in
Now that events are listened on demand, maybe the warning should be moved to method, where support is already checked?
It also prints the warning if you render on the server, its annoying :/
That's odd, I wouldn't expect that code to run at all when using server rendering.
I see this warning when I'm doing with . Any chance to disable it?
I also see this error when using ssr
This is happening to me with JSDOM as well and in my case our team project standards aren't going to accommodate leaving these errors in the console when tests are run. How can I suppress or stub this out. It's not just obnoxious it is preventing me from getting my work merged in our project.
/ - I am now seeing this error after upgrading my version of Enzyme to . Did you find a way to suppress these warnings for JSDOM?
If you're having problems please file a new issue. Nobody actively reads old issues, and requests for help here will get lost.

Discussion:
* `Object.create` – Provided by `es5-sham.js` from [kriskowal's es5-shim](https://github.com/kriskowal/es5-shim). * `console.*` – Only needed when using the unminified build. If you need to polyfill this, try [paulmillr's console-polyfill](https://github.com/paulmillr/console-polyfill). <ins> ### Cross-browser Issues Although React is pretty good at abstracting browser differences, some browsers are limited or present quirky behaviors that we couldn't find a workaround. #### onScroll event on IE8 On IE8 the `onScroll` event doesn't bubbles and IE8 doesn't have an API to define handlers to the capturing phase of an event, meaning there is no way for React to listen to these events. Currently a handler to this event is ignored on IE8. See the [onScroll doesn't work in IE8](https://github.com/facebook/react/issues/631) GitHub issue for more information. </ins>
Change:
Please see: and do the following: 'Toggle' to make the list-item fade into view. -click/Spam-click the 'Toggle' button again to make the item fade-out of view. 'Toggle' again to try to make the component come back into view. You'll see that the item doesn't come back! If you check the HTML, you can see that the list-item is still there, with the class name "example-leave example-leave-active". I suspect that React should reverse the animation elegantly in the case of the same component being re- in the render function during a leave transition.
Thanks, I was going to point you to but I see that you're the author of it!
Hehe, I thought perhaps it'd be best if I made a proper Issue (with JSFiddle example!) rather than just rudely posting Pull Requests! :)

Discussion:
componentWillReceiveProps: function(nextProps) { if (!nextProps.children && this.props.children) { this.savedChildren = this.props.children; <ins> } else if (nextProps.children && !this.props.children) { // We're being told to re-add the child.  Let's stop leaving! if (this.isMounted()) { var node = this.getDOMNode(); var className = this.props.name; CSSCore.removeClass(node, className + '-leave'); CSSCore.removeClass(node, className + '-leave-active'); if (this.props.enter) { CSSCore.addClass(node, className + '-enter'); CSSCore.addClass(node, className + '-enter-active'); } } </ins> } },
Change:
I don't know where the right place to link to them is. Maybe "Getting started", "Tutorial" and "Tooling integration"?

Discussion:
that support `*.tmLanguage`. * Linting provides accurate line numbers after compiling without sourcemaps. * Elements use standard scoping so linters can find usage of out-of-scope components. <ins> ### Debugging [React Developer Tools](https://github.com/facebook/react-devtools) is a [Chrome extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en) that allows you to inspect the React component hierarchy in the Chrome Developer Tools. </ins>
Change:
I couldn't find a reference to the fact that jsx transform attaches to the component spec, this would be nice to document somewhere (more importantly, that not using jsx means debugging messages will be littered with ). I found this while using .
That would be very nice indeed. If you want to take a stab at it, the docs are in the repo in the markdown format. Would love to have you on the contributor list :)

Discussion:
var app = <MyComponent someProperty={true} />; ``` <ins> JSX will infer the component's name from the variable assignment and specify the class's [displayName](/react/docs/component-specs.html#displayName) accordingly. </ins> See [Multiple Components](/react/docs/multiple-components.html) to learn more about using composite components. > Note:

<!-- TODO: Document mixins here directly. --> <ins> ### displayName ```javascript string displayName ``` The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods Various methods are executed at specific points in a component's lifecycle.
Change:
Replace with and no parse error happens. What’s going on?
I had the same issue with this: We actually have an internal task tracking this at Facebook but I don't think it's been looked in to yet. Here's a comment explaining why it happens:
Fixed in esprima-fb () when for esprima-fb, jstransform and react are sorted out.
I'm actually going to leave this open for now so we remember to do the version update.
Now fixed in

Discussion:
<div class="right">&copy; 2013 Facebook Inc.</div> </footer> </div> <ins> <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-41298772-1', 'facebook.github.io'); ga('send', 'pageview'); </script> </ins> </body> </html>
Change:
The link to "JSX in depth" in the "displayName" section on the "Component Specs and Lifecycle" page points to This url is not correct, the correct url is:
Thanks! Fixed in . You can close this.

Discussion:
string displayName ``` <del> The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </del> <ins> The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](/react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods