facebook / react Goto Github PK

The following URL is not found -
http://facebook.github.io/react/blog/2013/06/05/facebook.github.io/react/docs/syntax.html

And it is linked from - http://facebook.github.io/react/blog/2013/06/05/why-react.html

On IRC today someone was missing a tag in ReactDOM. Should we export createDOMComponent() as an escape hatch?

Not sure if it's bug or feature.

Line numbers are reported according to the package output, not the original file line number.

Please make "requireable" npm release, #10 already fixed and only new version on npm is needed. I've developed a source transform for JSX for browserify — reactify which doesn't work properly because of #10

If you have

componentWillReceiveProps: function() {
    this.setState({x: this.state.x + 1});
    this.setState({x: this.state.x + 1});
}

At the very very least, it should not be broken when we require it.

It could be preferable to use:

bower install --save react

So that the installation is automatically saved in the bower.json.

Should we let people invoke setState in componentWillUnmount? It seems harmless, but currently we throw. In theory, this.state should be cleared out when unmounting (but we do not for backward compatibility reasons).

Aside, as we get better at clearing asynchronous callbacks on unmount, we should seriously consider clearing this.state and this.props when unmounting.

I was getting errors from grunt because of this and maybe this was also causing some confusion of mine before. Not sure what the right thing to do here, but perhaps it should filter by file extension (and hidden-ness? my vim swap filenames start with ..)

If you go on our site, there's nothing that talks about synthetic events, mock DOM, reconciliation, etc. I think documenting this would have a huge impact.

NormalizedEventListener uses Object.create which is unavailable in IE8 and isn't added by es5-shim. (edit: no longer.)

It is added by es5-sham but the common questions doc on the React site doesn't say that es5-sham is also required. Not sure if this is a docs problem or if there's a good way to avoid Object.create.

(Side note: it's a little bit of a pain to test in IE8 since neither the website nor most of the examples include es5-shim (or es5-sham).)

Looks like it's mostly a problem with Ruby 1.8 yaml vs 1.9 yaml. One strips the trailing space and the other leaves it in.

There's also the issue of reordering. So at the very least we shouldn't re-write _config.yml if the version is the same.

iOS Safari really doesn't want you clicking anything that's not an <a> tag. This is a known issue: http://stackoverflow.com/questions/5421659/html-label-command-doesnt-work-in-iphone-browser/6472181#6472181

The way you fix this is by putting an empty "onclick" attribute on nodes you wish to emit click events. Yep.

So presumably:

div({onClick: function(){alert('clicked');}}, 'click me');

should emit:

<div onclick>click me</div>

on iOS. Ensuring that the click event is actually reachable from an iOS device.

As the stack overflow link points out, this is also an issue for <label> elements associated with <input> elements. In order to behave as a clickable label, they must also include an empty "onclick" attribute.

label(null, input({type: 'checkbox'}), check me);
<label onclick><input type="checkbox> check me</label>

This happens in both JSXTransformer 0.3.0 and 0.3.2

Something like:

/** @jsx React.DOM */
      <div
        a={(1)}  // BAD: this works only if you remove the parens here.
        b={2}
      >
        hi2u!
      </div>

/** @jsx React.DOM */
      React.DOM.div(
        {a:(1,)  // BAD: SYNTAX ERROR
        b:2}, null
      )

JSX is nice, but those using compile-to-JS language have to change the transpiler to connect to the JSX compiler. Is there any chance of adding alternative DOM syntax to JSX so it does not break every compile-to-JS language? Something gettext-style would be nice. So in addition to:

var HelloMessage = React.createClass({
  render: function() {
    return <div>{'Hello ' + this.props.name}</div>;
  }
});

var HelloMessage = React.createClass({
  render: function() {
    return _dom_("<div>{'Hello ' + this.props.name}</div>");
  }
});

Browsers do special things on self-closing tags like <p>:

http://jsfiddle.net/bbrGq/1/

React should warn or throw if it detects a nested React.DOM.p.

I encountered this issue when demoing to airbnb today.

Steps to repro:

• create src/ dir
• create regular js module src/React.js containing module.exports = 7; and src/Component.jsx which contains require('./React')
• run: jsx -x jsx src/ src/ to build .js files alongside .jsx (a very common use case of this tool)
• Observe React.js gets overwritten with a file that throws an exception

This manifests itself as: any time you pass something to -x that is not js, if you require React (which are js files) it will get overwritten.

This is very confusing. I think we really need to turn all of the magic off in this tool unless --relativize is provided. That includes debranching __DEV__, relativizing module names, and this sort of thing. That is, only the JSX desugaring should happen.

Trying to run jsx to build into a subdir seems to just exit with no error message:
jsx -w src/ public/js (public/js does exist)

However, if run in directly in public it works without a hitch:
jsx -w src/ public

https://travis-ci.org/facebook/react/builds/8558655 shows

359 spec 2171 expect 0 skip 0 fail

running tests locally...

285 spec 1536 expect 0 skip 0 fail

I looked back over the past few days and I see it happening there so it's not a strictly new problem.

Any idea what's up @benjamn?

This is the common case - let's make it the default, so you don't need to wrap methods in React.autoBind.

Did a search and didn't find any related issue, so here I go:
Apparently react, as of today, still hijacks the DOM element id (haven't gotten the chance to try it yet), rendering it a bit unpractical for CSS. I was wondering why this rather than using an attribute like data-react-uid. Is this a performance/compatibility issue? What's the motivation behind using the id internally to target elements instead of an attribute?

Sure, it's still possible to use classes, bit I think one less quirky gotcha like this would make react much more appealing.

Currently, when two escaped entities are outputted the space between them is removed. For the code below the expected output is "Hello World", but the actual output is "HelloWorld" (without a space between "Hello" and "World").

var Hello = React.createClass({
    render: function() {
        return <div>{this.props.greeting} {this.props.name}</div>;
    }
});

React.renderComponent(<Hello greeting="Hello" name="World" />, document.body);

See this jsfiddle: http://jsfiddle.net/j7skc/1/
Reported here: https://groups.google.com/forum/?fromgroups#!topic/reactjs/tCFACnPMZ6Q

Looks like we aren't checking the constructor type to figure out that we should unmount rather than receive new props. This may be fixed in master already (haven't checked); @yungsters or @jordow can you take a look (and add a test)?

We currently have 2 paths for having child content in ReactNativeComponents: this.props.children and this.props.content. Supporting both of these paths makes our code more complicated than it needs to be, and really a single child is the same as content.

We were using this for <option> to make sure it only had a single text child, thought it doesn't look like we are anymore...

Since tests are injecting plugins with the same name multiple times, they fail. This shouldn't be happening since we dumpCache https://github.com/facebook/react/blob/master/src/eventPlugins/__tests__/AnalyticsEventPlugin-test.js#L33

must added the following comments ?why?no another way?!

/**
* @jsx React.DOM
*/

Hello! I've been using React and combining it with Browserify. My goal for this was to be able to use Node modules with React, by using this workflow:

1. Write JSX logic, include require()'s to installed Node modules
2. Use react-tools to compile the JSX to JS
3. Browserify said JS, which would then include the Node modules

However, the compiled JSX from react-tools changes something like require('foo') to require('./foo'), and creates a stub file. This very much breaks importing modules. This seems to happens because of commoner, which is part of the compiling workflow.

Is there a workaround for this?

Various frameworks uses custom attributes. React could allow to extend default data- and aria- prefixes. Something like this:

React.registerCustomAttributePrefix('e-');
React.registerCustomAttributePrefix('ng-');

Inspired by #71 (comment)

This will reduce the number of assumptions imposed by bin/jsx considerably.

We should still use --relativize for our grunt tasks, but that's our poison to pick.

cc @petehunt @zpao

/** @jsx React.DOM */ is pretty annoying noise. Let's stop requiring it. We can probably keep it simple for now but if we want to make JSX more generic and standalone we might need to do this a bit more carefully.

This should work:

<div>
  {/* this is a comment */}
</div>

cc @petehunt

Learning the library. Any tips on getting it to play nice with RequreJS ?

Looks like it needs a shim but I can't figure out what exactly.

thanks!

The way React renders DOM is really interesting. I was wondering if there's any plan to include a functionality that sets the style of the rendered content without css name pollution. Something like the following:

style: function() {
  return {
    fruit: {border: '1px solid black'}
  };
},
render: function() {
  return <div className="fruit">{'Hello'}</div>;
}

Even with the most basic tutorial code, I'm unable to get past this error thrown at JSXTransformer.js:46.

Error Trace:

Uncaught SyntaxError: Unexpected token < JSXTransformer.js:46
exports.run JSXTransformer.js:46
execute JSXTransformer.js:101
runScripts

Full source:

<html>
  <head>
    <title>Hello React</title>
    <script src="react.min.js"></script>
    <script src="JSXTransformer.js"></script>
  </head>
  <body>
    <div id="content"></div>
    <script type="text/jsx">
        var CommentBox = React.createClass({
          render: function() {
            return (
              <div class="commentBox">
                Hello, world! I am a CommentBox.
              </div>
            );
          }
        });
        React.renderComponent(
          <CommentBox />,
          document.getElementById('content')
        );
    </script>
  </body>
</html>

Basically what the title says. After install react-tools, using jsx -w will correctly detect existing files (but not transform them), and upon any write to any watched file jsx will exit with error code 1. Commoner tests all pass.

Exact steps I followed, in Ubuntu 12.10:
0) Install node.js via manual instructions at https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager for Ubuntu/Mint

1. Install react-tools with 'sudo npm install -g react-tools'
2. Create file helloworld.js in , as described by the Getting Started tutorial.
3. In a new terminal, jsx -w
4. Edit helloworld.js and add a comment.
5. Notice that jsx exited, echo $? prints 1.

akrieger@vb:/www$ ls js/
helloworld.js
akrieger@vb:/www$ ls html/js/
akrieger@vb:/www$ jsx -w js/ html/js/
["helloworld"]
<edit helloworld.js, save edit>
akrieger@vb:/www$ echo $?
1
akrieger@vb:/www$ ls html/js/
akrieger@vb:/www$

Can we have DOMPropertyOperations.setValueForProperty complain on invalid properties? A coworker was confused why colspan=... was being silently ignored.

I'm not sure whether this is as intended, or a problem with JavaScript, but I fiddled around with your example on facebook.github.io/react and tried this code:

var Timer = React.createClass({
  getInitialState: function() {
    return {secondsElapsed: 0};
  },
  tick: React.autoBind(function() {
    this.setState({secondsElapsed: this.state.secondsElapsed + 0.1});
  }),
  componentDidMount: function() {
    setInterval(this.tick, 100);
  },
  render: function() {
    return React.DOM.div({},
      'Seconds Elapsed: ' + this.state.secondsElapsed
    );
  }
});

React.renderComponent(Timer({}), mountNode);

JSX Has been the file extension for ExtendScript files since at least 2005.
http://www.adobe.com/devnet/scripting.html

ExtendScript supports some amount of E4X syntax, but is not compatible with the facebook/jsx syntax.

Since at least May 15th 2012 "jsx" has been "a faster, safer, easier JavaScript".
http://jsx.github.io
https://github.com/jsx

cc @jeffmo

Would be cool and useful if <div title="hello {there}"> compiled down into

React.DOM.div({title: "hello " + there})

or similar, though it looks like I'm fighting an uphill battle here:

22:56 < balpert> any reason why <div title="hello {there}"> shouldn't interpolate?
22:58 <@zpao> lbljeffmo: that's in your court :)
22:58 <@lbljeffmo> balpert: because that's hard :)
22:58 <@lbljeffmo> We'd basically need to eval strings
22:58 < balpert> I mean, <div>hello {there}</div> already works?
22:58 <@lbljeffmo> let me think for more than a second...
23:00 <@lbljeffmo> also, we'd need to escape the output
23:00 < balpert> what do you mean?
23:00 <@zpao> well, react will escape the whole attr when creating html
23:01 <@lbljeffmo> what would it interpolate to?
23:01 < balpert> {title: "hello " + there}?
23:01 < balpert> or maybe something like {title: ["hello ", there]} if we made that work
23:01 <@zpao> yea
23:01 <@zpao> same as <div title={'hello ' + there}/>
23:02 <@lbljeffmo> I'm hesitant because it changes the semantics of a string (but I'm still processing…)
23:02  * zpao isn't sure this is really quite a path we want to go down but it interesting to think about
23:02 < balpert> yeah, I'm unsure too
23:03 < balpert> a coworker asked though and it would seem to make JSX a bit more consistent
23:03 <@lbljeffmo> also, string literals would act differently from refs to string lits
23:03 < balpert> lbljeffmo: what do you mean?
23:03 <@zpao> well, JSX ≠ templating, which it sounds like your coworker actually wants
23:03 <@lbljeffmo> var stuff = "dude"; var myStuff = "Hello {stuff}"; <div title={stuff} />;
23:04 <@lbljeffmo> we only have the opportunity to re-write the string if we can analyze it at compile time
23:04 <@lbljeffmo> not at run time
23:04 < balpert> correct
23:04 < balpert> I definitely wouldn't expect that interpolation to work
23:05 <@lbljeffmo> seems unclear to a noob though who hasn't thought about the depths of the transform though
23:05 <@lbljeffmo> I'm inclined to suggest that this would be something you'd want to do with a templating library and then pass the result of the template processing in
23:07 < balpert> lbljeffmo: I dunno, it seems pretty simple to have JSX interpolate {...} in attrs and element bodies
23:07 < balpert> I don't think anyone who knows anything about how JSX works would get confused when var myStuff = "Hello {stuff}"; <div title={stuff} /> doesn't work
23:08 <@lbljeffmo> ya maybe not
23:09 < balpert> well, something to think about
23:09 <@zpao> at that point we might as well just make jsx handlebars
23:09 < balpert> obviously not a big deal
23:10 <@zpao> handlerbars + xml
23:10 <@lbljeffmo> but the "jsx is not a templating tool" argument still makes a lot of sense to me -- using a real templating utility seems more modular and less slippery-slopey down the new-templating-features slope
23:13 < balpert> this particular feature doesn't feel at all like "new features" to me, but I agree with your general argument
23:14 < balpert> obviously (to me, at least) it doesn't make sense to add loops or anything like that to JSX
23:14 < balpert> at least, certainly not some {{#each ...}} thing
23:14 <@lbljeffmo> see also: http://wiki.ecmascript.org/doku.php?id=harmony:quasis

Currently, when mounting two nested components, componentDidMount fires on the outer element before the inner one:

http://jsfiddle.net/spicyj/udaq9/

I can't remember now why I was frustrated by this earlier in the week but I'd expect the inner component to be mounted completely before the outer component's componentDidMount method runs so that it can rely on the children being fully mounted.

Agree/disagree?

I have been playing around with the library. I am trying to use their JSX syntax, and was just wondering how you guys get it to play nicely with jslint/jshint?

JSLint obviously does not like the JSX syntax - ("expected an identifier and instead saw ' <';" - JavaScript syntax error), so how do I get around this in my .jshintrc file?

cc @petehunt @zpao

I'm trying to programatically invoke the JSX transformer (using the version of react-tools in the npm registry) by running something like

require('react-tools').transform(someCode);

Which then throws this error:

Error: Cannot find module './build/React'

If I comment out the lines in main.js that require/use ./build/React the react-tools module loads fine and the transformer runs correctly.

I don't know what's going on - I tried cleaning the project, but grunt test just hangs without any output. My CPU fan starts spinning up so it's probably thinking about something very hard.