jiebi/CodeConvo huggingface dataset:
Change:
New to React. I was following the tutorial and ran into a snag. Copy pasting the example example lead to on line 2 on Chrome. I was using the in-browser JSX transformer. It took me awhile to figure out this is a proposed JavaScript thing and not a built-in React thing. needed to be . This is super unclear from the documentation/tutorial. To me, it reads as if somehow React is taking care of this or it's a React specific syntax; not ES6. The docs link out to the Destructuring assignment, but I think the docs should clearly state "Your browser / environment must support ES6 harmony for this to work."
Well, the docs do say this... Perhaps move this up further as people (like me) following along the tutorial may not bother to keep reading.
Want to send a PR to improve upon the tutorial?
Sure. I'll mess with it tonight.

Discussion:
## Transferring with `...` in JSX <ins> > NOTE: > > In the example below, the `--harmony ` flag is required as this syntax is an experimental ES7 syntax. If using the in-browser JSX transformer, simply open your script with `<script type="text/jsx;harmony=true">`. See the [Rest and Spread Properties ...](http://facebook.github.io/react/docs/transferring-props.html#rest-and-spread-properties-...) section below for more details. </ins> Sometimes it's fragile and tedious to pass every property along. In that case you can use [destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) with rest properties to extract a set of unknown properties. List out all the properties that you would like to consume, followed by `...other`.
Change:
This has no dependencies so I think we should either publish it as a standalone module or direct people to something else from the community. I'm inclined to do the latter since it means we can wash our hands of it. Our internal usage of is tied to our transforms so we've said no to features that would be useful to others outside FB. I'm concerned we'd do that again. Any suggestions for existing projects that we can point to?
Can't we just link to a bunch of "useful scripts" in the docs and leave it at that? People are free to use/modify them, it's implied they're not being maintained and are there just for getting people started. I feel like a lot of people don't understand the current state of , but expect them to be full-blown frameworks and updated with every feature conceivable. Publishing on NPM kind of continues that trend and I suspect no-one on Team React really cares about the addons enough. So I would say, make them available in the docs (as code/files) and let the community sort out publishing/improving/direction.
...Can I "steal" the code and post it somewhere else under my name? I do need it for another CSS repo of mine, and it's really not React-specific.
After talking with Jed at the conference, I think I'll just point people at
Pete hunt already has react-classset module on npm I believe as well
According to the react-classset has been deprecated in favor of the above mentioned library.
It is. They're pretty much the same except for some negligible differences so I deprecated the former (the latter has an active maintainer).

Discussion:
var ReactServerRendering; var ReactTestUtils; <del> var cx; </del> var reactComponentExpect; var mocks; describe('ReactCompositeComponent', function() { beforeEach(function() { <del> cx = require('cx'); </del> mocks = require('mocks'); reactComponentExpect = require('reactComponentExpect');

return this.refs.anch; }, render: function() { <del> var className = cx({'anchorClass': this.props.anchorClassOn}); </del> <ins> var className = this.props.anchorClassOn ? 'anchorClass' : ''; </ins> return this.props.renderAnchor ? <a ref="anch" className={className}></a> : <b></b>;

* @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ <ins> 'use strict'; var warning = require('warning'); var warned = false; </ins> function cx(classNames) { <ins> if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } </ins> if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className];
Change:
Hey guys, I know there are a lot of issues here so I'll try to make this quick and clear. The issue is that when you generate a sourcemap using the node module by calling , it will always output in the property of the sourcemap that is generated, there is no way to specify the actual source file. I thought that perhaps the option would allow you to change this, but unfortunately it does not -- no matter what you set to, the property always returns as an array with in it only. A small snippet of code to quickly verify this:
Thanks guys for the quick fix! :beers:

Discussion:
if (options && options.sourceMap) { result.sourceMap = output.sourceMap.toJSON(); } <ins> if (options && options.sourceFilename) { result.sourceMap.sources = [options.sourceFilename]; } </ins> return result; } };

} var visitorList = visitors.getVisitorsBySet(visitorSets); <ins> if (options.sourceFilename) { options.filename = options.sourceFilename; } </ins> return transform(visitorList, input, options); }
Change:
is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !

Discussion:
renderCode={true} transformer={transformer.bind(null, this.state.harmony)} showCompiledJSTab={false} <ins> showLineNumbers={true} </ins> /> <label className="compiler-option"> <input

); var CodeMirrorEditor = React.createClass({ <ins> propTypes: { lineNumbers: React.PropTypes.bool, onChange: React.PropTypes.func }, getDefaultProps: function() { return { lineNumbers: false }; }, </ins> componentDidMount: function() { if (IS_MOBILE) return; this.editor = CodeMirror.fromTextArea(this.refs.editor.getDOMNode(), { mode: 'javascript', <del> lineNumbers: false, </del> <ins> lineNumbers: this.props.lineNumbers, </ins> lineWrapping: true, smartIndent: false,  // javascript mode does bad things with jsx indents matchBrackets: true,

transformer: React.PropTypes.func, renderCode: React.PropTypes.bool, showCompiledJSTab: React.PropTypes.bool, <ins> showLineNumbers: React.PropTypes.bool, </ins> editorTabTitle: React.PropTypes.string },

return JSXTransformer.transform(code).code; }, editorTabTitle: 'Live JSX Editor', <del> showCompiledJSTab: true </del> <ins> showCompiledJSTab: true, showLineNumbers: false </ins> }; },

onChange={this.handleCodeChange} codeText={compiledCode} readOnly={true} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXContent =

onChange={this.handleCodeChange} className="playgroundStage" codeText={this.state.code} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXTabClassName =

@include code-typography; } <del> div.CodeMirror-linenumber:after { content: '.'; </del> <ins> div.CodeMirror-linenumber { text-align: right; </ins> } .CodeMirror, div.CodeMirror-gutters, div.highlight {
Change:
TestUtils.isDOMComponent(...) uses deprecated Element.getDOMNode(), resulting in console warnings when running tests. In my case, running 175 unit tests results in 700+ such warnings, drowning the output of the tests.
How are what tests are you running?
The tests are standard unit tests for custom React components. For example, I have a Toggle component that dispatches an event with type '' when clicked.
I'm also seeing the same issue testing under karma and mocha.
it looks like you this TODO? Can we get this fixed? Happy to help, but not sure what the right heuristic is.
This is unfortunate. I don't quite know what the right heuristic should be for 0.13, but we're changing it for 0.14 anyway since refs on DOM component will just be regular DOM nodes so I think we'll just power through. :/
Maybe we can do ?
I was thinking that we can reuse string types for ART and React Native too. We wouldn't want a React Native node to hit this.
maybe then?
It is not an own property. (And will be deprecated anyway so not a great heuristic.)
Lets just move fast on the ref === real DOM node stuff instead of spending time figuring this out.

Discussion:
isDOMComponent: function(inst) { // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. <del> return !!(inst && inst.getDOMNode && inst.tagName); </del> <ins> return !!(inst && inst.tagName && inst.getDOMNode); </ins> }, isDOMComponentElement: function(inst) {

// Should be document order, not mount order (which would be purple, orange) expect(log).toEqual(['orangepurple', 'orange', 'purple']); }); <ins> it('does not warn for getDOMNode on ES6 classes', function() { var Foo = React.createClass({ render: function() { return <div />; } }); class Bar extends React.Component { render() { return <div />; } } spyOn(console, 'warn'); var foo = ReactTestUtils.renderIntoDocument(<Foo />); expect(ReactTestUtils.isDOMComponent(foo)).toBe(false); var bar = ReactTestUtils.renderIntoDocument(<Bar />); expect(ReactTestUtils.isDOMComponent(bar)).toBe(false); var div = ReactTestUtils.renderIntoDocument(<div />); expect(ReactTestUtils.isDOMComponent(div)).toBe(true); expect(console.warn.calls.length).toBe(0); }); </ins> });
Change:
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.

Discussion:
var elementFactory = ReactElement.createFactory(tag); var FullPageComponent = ReactClass.createClass({ <ins> tagName: tag.toUpperCase(), </ins> displayName: 'ReactFullPageComponent' + tag, componentWillUnmount: function() {

expect(console.warn.calls.length).toBe(0); }); <ins> it('should support injected wrapper components as DOM components', function() { var injectedDOMComponents = [ 'button', 'form', 'iframe', 'img', 'input', 'option', 'select', 'textarea', 'html', 'head', 'body' ]; injectedDOMComponents.forEach(function(type) { var component = ReactTestUtils.renderIntoDocument( React.createElement(type) ); expect(component.tagName).toBe(type.toUpperCase()); expect(ReactTestUtils.isDOMComponent(component)).toBe(true); }); }); </ins> });
Change:
In following JSX fragment I should guarantee that will never be or : Otherwise throws an error although construction is correct: Should instead of check for ?
Someone else mentioned this being surprising to me too.
I've been experiencing the same issues recently
As far as I understand it, the idea is that is basically the equivalent of a HTML-type. You're not meant to use it as , but as so that you cannot accidentally pass unsafe data. So should be or , in this model it does not make sense to have .
That doesn't mean that people won't write it as – doing so is even pretty reasonable if you're careful about naming your vars/props and do .
The simplest workaround is to coerce into an empty string with . +1 for having React do this internally.
Got surprised by this today, upgrading from to . Was it a "bug" in (i.e. it shouldn't have accepted ), or is it a bug in ? Anyway, will use as suggested by just wanted to point out that it seemed to "work" in .

Discussion:
'Can only set one of `children` or `props.dangerouslySetInnerHTML`.' ); invariant( <del> props.dangerouslySetInnerHTML.__html != null, </del> <ins> typeof props.dangerouslySetInnerHTML === 'object' && '__html' in props.dangerouslySetInnerHTML, </ins> '`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. ' + 'Please visit https://fb.me/react-invariant-dangerously-set-inner-html ' + 'for more information.'

); }); <ins> it('should allow {__html: null}', function() { expect(function() { mountComponent({dangerouslySetInnerHTML: {__html: null} }); }).not.toThrow(); }); </ins> it("should warn about contentEditable and children", function() { spyOn(console, 'error'); mountComponent({contentEditable: true, children: ''});
Change:
'For communication between two components that don't have a parent-child relationship, you can set up your own global event system.' So far I've really enjoyed React. It's conducive to modularize your components. However, as you modularize your components, it gets harder to communicate. A global event system doesn't scale and essentially couples components that shouldn't be coupled. A simple example, a faceted navigation sidebar containing two subviews. Some filters and a search bar, and a list of things: SibebarView | -- Filters -- Search Input -- Filter Button | -- List View In essence, an event stream from your search input should update the list. By the advice above, it seems like you'd say create a singleton EventEmitter which the search input : As you can see, this is a very specific event which the SidebarView has to know about. Also let's say you have a global search input. Over time it seems like you have to be increasingly specific about event names. I have a feeling Flux is supposed alleviate this problem somehow, but if so is there any way we can give some more detail here and/or point people in the right direction? Seems like a common use case.
Flux is indeed one way of solving this problem. I created a PR to mention it.
thanks! for others' reference:
one step further might be nice to throw in a quick if-you-understand-a-little-about-flux example.

Discussion:
Notice the use of `bind(this, arg1, arg2, ...)`: we're simply passing more arguments to `handleClick`. This is not a new React concept; it's just JavaScript. <del> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. </del> <ins> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. [Flux](https://facebook.github.io/flux/) pattern is one of the possible ways to arrange this. </ins>
Change:
I didn't realise this was in the addons bundle, would be good to get it to the docs. Would be good to also include an example of using or something similar.
rAF batching isn't supported and won't go in the docs, but batchedUpdates should.
is rAF batching discouraged, or just not suitable for shipping with core? Would it be reasonable to link to an up-to-date npm project on the batchedUpdates page?
We don't use it at Facebook and it's not clear that it solves real problems, so we don't want to maintain it or have to fix bugs related to it. should give enough control over batching.
There are also known issues with rAF batching (mostly around controlled components).
Should we deprecate and eventually remove the RAF batching?
It's never been supported in any fashion.
(i.e., it's already deprecated?)
shouldn't this file be deleted in that case?
That's not exposed as a public API in any of our builds, but sure, we can delete it – PR incoming.
Killed in
We should document ReactDOM.unstable_batchedUpdates.
Since when did we start documenting features? Haven't we always left them intentionally undocumented? We also have unstablerenderSubtree and unstable_handleError and others, but I thought the decision was to not document them until they become stable. We document them as part of the release process. It was a different situation when it was an addon, the issue made sense at that time.
Sure.

Discussion:
<del> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule ReactRAFBatchingStrategy * @typechecks static-only */ /* global requestAnimationFrame:true */ 'use strict'; var ExecutionEnvironment = require('ExecutionEnvironment'); var ReactUpdates = require('ReactUpdates'); var requestAnimationFrame = require('requestAnimationFrame'); function tick() { ReactUpdates.flushBatchedUpdates(); requestAnimationFrame(tick); } var ReactRAFBatchingStrategy = { isBatchingUpdates: true, /** * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ batchedUpdates: function(callback, a, b, c, d) { callback(a, b, c, d); } }; if (ExecutionEnvironment.canUseDOM) { requestAnimationFrame(tick); } module.exports = ReactRAFBatchingStrategy; </del>
Change:
There seems to have been an API change between React 0.12 and 0.13 that's not covered in the documentation. When using with the option, the source map is now returned as a plain JavaScript object. Previously it would return an instance of and you'd need to call to get the actual source map. Is this an intentional change that just got overlooked when writing the documentation?
That's just an oversight. We aligned JSXTransformer to use the same code as react-tools (as opposed to duplicating efforts with slight variation). This originally changed in react-tools last year - , and then I made JSXTransformer just use react-tools in . I didn't notice that we're doing a bit more post-processing in react-tools. We can add a bit to the changelog for this.

Discussion:
* `es3` restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility). * The transform for the call spread operator has also been enabled. <ins> ### JSXTransformer #### Breaking Changes * The return value of `transform` now contains `sourceMap` as a JS object already, not an instance of `SourceMapGenerator`. </ins> ### JSX #### Breaking Changes
Change:
"Getting started" defined to . "Adding Markdown" defined to . Should be unify to or ?
Nice find. We should use the same version. Are you interested in creating a PR to update it?
Yes I am. I looking at I think will attempt to unify the . I would like to create a PR so I'll do that soon.

Discussion:
<title>Hello React</title> <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/JSXTransformer-{{site.react_version}}.js"></script> <del> <script src="https://code.jquery.com/jquery-1.10.0.min.js"></script> </del> <ins> <script src="https://code.jquery.com/jquery-2.1.3.min.js"></script> </ins> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </head> ```
Change:
The  CSS property should not be getting a suffix automatically because a unit-less value can represent the number of spaces that make up the width in a tab. The JS name for this property is . See in the React docs.
A solution for now is to use the which is pretty much equivalent.
Sounds like a good idea. Are you interested in creating a PR to add it?
Yes, the only thing I don't know is whether there needs to be anything special done to also include and handle object already in place
We autogenerate the vender-prefixed styles there (which you might have seen below where you changed code) so that's all you need to do! Thanks again.

Discussion:
개발 하다보면 CSS 속성들이 단위 없이 그대로 유지되어야 할 때가 있을 겁니다. 아래의 프로퍼티들은 자동으로 "px"가 붙지 않는 속성 리스트 입니다: <ins> - `boxFlex` - `boxFlexGroup` </ins> - `columnCount` - `fillOpacity` - `flex` - `flexGrow` <ins> - `flexPositive` </ins> - `flexShrink` <ins> - `flexNegative` </ins> - `fontWeight` - `lineClamp` - `lineHeight`

- `order` - `orphans` - `strokeOpacity` <ins> - `tabSize` </ins> - `widows` - `zIndex` - `zoom`

opacity: true, order: true, orphans: true, <ins> tabSize: true, </ins> widows: true, zIndex: true, zoom: true,
Change:
Our tests currently only pass in the browser when running in Chrome. This is because it supports WebComponents already. However they fail in every other browser. I think this is because of when is actually loaded. It's currently getting packaged into react-test because we're requiring it. It creates a new which is resulting in nodes we create with to have a different prototype than what is expected in WebComponents. WebComponents's new Node prototype has a different implementation of which does an check which our nodes are failing. I think if we loaded into the browser before we loaded JS, the node we create for markup wrapping would have the right prototype.

Discussion:
var React = require('React'); var ReactMount = require('ReactMount'); var ReactTestUtils = require('ReactTestUtils'); <del> var WebComponents = undefined; </del> <ins> var WebComponents = WebComponents; </ins> try { <del> WebComponents = require('WebComponents'); </del> <ins> if (WebComponents === undefined && jest !== undefined) { WebComponents = require('WebComponents'); } </ins> } catch(e) { <del> /* leave WebComponents undefined */ </del> <ins> // Parse error expected on engines that don't support setters // or otherwise aren't supportable by the polyfill. // Leave WebComponents undefined. </ins> } describe('constructAndRenderComponentByID', function() {

;(function(){ var urls = [ <ins> '../src/shared/vendor/third_party/webcomponents.js', </ins> '../vendor/jasmine/jasmine.js', '../vendor/jasmine/jasmine-support.js', '../vendor/jasmine/jasmine-html.js',
Change:
Consider following snippet: Expected DOM Current behaviour Demo: W3C Specs:
I made a pull request, but was a bit faster. The pull requests are different, so maybe it is good that there are two. :smile:
That's wonderful, Thx!

Discussion:
// autoFocus is polyfilled/normalized by AutoFocusMixin // autoFocus: HAS_BOOLEAN_VALUE, autoPlay: HAS_BOOLEAN_VALUE, <ins> capture: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, </ins> cellPadding: null, cellSpacing: null, charSet: MUST_USE_ATTRIBUTE,
Change:
We currently use the transaction queue too much and build up a giant array on mount. Here's one simple example of where we add things to the queue unnecessarily:
I don't know of anything else easy here.

Discussion:
internalInstance._currentElement ); } <del> transaction.getReactMountReady().enqueue(attachRefs, internalInstance); </del> <ins> if (internalInstance._currentElement.ref != null) { transaction.getReactMountReady().enqueue(attachRefs, internalInstance); } </ins> return markup; },
Change:
At gh-pages branch, there are and files. I think those file name must be and .
Thanks! I just pushed the change to the stable branch so this should be updated on the site and in the gh-pages branch as soon as it builds.
Thanks!

Discussion:
--- id: getting-started-ja-JP title: 始めてみましょう <ins> permalink: getting-started-ja-JP.html </ins> next: tutorial-ja-JP.html redirect_from: "docs/index-ja-JP.html" ---

--- id: tutorial-ja-JP title: チュートリアル <ins> permalink: tutorial-ja-JP.html </ins> prev: getting-started-ja-JP.html next: thinking-in-react-ja-JP.html ---