7 ms·
React v0.12
- johne20 12y agooff topic a bit, but why do the CDN urls 301 redirect?
- BinaryBullet 12y agoDo you mean the fb.me link, or did you see one of the fbcdn.net links redirect? If you mean the fb.me link, that's Facebook's URL shortening service, so those will always redirect (as far as I know).
- zpao 12y agoMostly what @BinaryBullet said. fb.me is a urlshortener and then it hits real CDNed files. I (as maintainer of React) suggest not actually using fb.me urls in production. Use cdnjs or jsdelivr. Or host it yourself. We've been meaning to put together a proper CDN hosting setup for JS libraries but just haven't gotten around to it.
- johne20 12y agoOk, thanks. That is what I am actually doing now (host it yourself). It might be nice to mention that in the documentation/article that those links shouldn't not be used on production. Currently it is definitely not the messaging that comes across. eg. "Minified build for production: http://fb.me/react-0.12.0.min.js" http://fb.me/react-0.12.0.min.js"
- johne20 12y agoOut of curiosity why don't you suggest using the fb.me urls in production? It would be nice to take advantage of the reach of Facebook to know that a decent percentage of users would have hit the CDN'ed react url before hitting non-fb site(s).
- josebalius 12y agoSo are ES6 classes for components coming in 0.13?
- zpao 12y agoMaybe. We're still working on the details about what that will look like. Chances are we'll have some basic support if you're doing a limited set of things. Stay tuned.
- lobster_johnson 12y agoYou can use ES6 classes today: class Button { render() { return <button>{this.props.label}</button>; } } Button = React.createClass(Button.prototype); Of course, it would have been nice to be able to skip that last line, and extend/mix in some React base class instead.
- jbhatab 12y agoI don't know if I'm reading the changes wrong, but I'm not liking how I have to do an extra step if I don't use jsx. I want to use coffescript and not have to do extra stuff. I definitely feel this forced vibe around making everyone use jsx, but have yet to hear any compelling reasons why it's better.
- hardwaresofton 12y agoWhere did you see the increased difficulty if you weren't using JSX?
- Fishkins 12y agoI haven't used React, but maybe he's referring to this: "Composite Component functions can no longer be called directly - they must be wrapped with React.createFactory first. This is handled for you when using JSX."
- jbhatab 12y agoAs the others have stated, react requires me to add this line: var MyComponent = React.createFactory(require('MyComponent')); It's not a huge deal, but I keep getting this sense that jsx is strongly tied to react and this reaffirms that they are going to keep it that way. I do trust the react team still, but it makes me weary of future releases.
- chenglou 12y ago(I'll re-link to sebmarkbage's answer here in case people see this post and get confused: https://news.ycombinator.com/item?id=8523876 https://news.ycombinator.com/item?id=8523876) In short, this is somewhat of a transition step for the (imo) even better way of specifying your render with pure vanilla js collections. This goes in the opposite direction of what you're worried about. You can view `createElement/Factory` as the stepping stone, with the _additional_ benefit of allowing you to use es6 classes very soon. Smaller API surface and + using more js features rather than library-specific ones; what's not to like? =) As for your worries about JSX: yes, it does come from React since the beginning. But we've taken an extra step of making it clear that this doesn't have to be React-specific: http://facebook.github.io/jsx/ http://facebook.github.io/jsx/. You can plug this in CoffeeScript. If not, see my previous point.
- limsup 12y agoCan someone explain what the "spread operator" is and how to use it?
- heydenberk 12y agoSpread is like python's *args. Instead of this: var mapArgs = function() { var args = Array.prototype.slice.call(arguments, 0, arguments.length - 1); var mapper = Array.prototype.slice.call(arguments, arguments.length - 1); return args.map(mapper); }; You can do this: var mapArgs = function(...args, mapper) { return args.map(mapper); }; And you can also use it to apply. Instead of: var max = Math.max.apply(null, [1, 2, 3, 4]); You can do: var max = Math.max(...[1, 2, 3, 4]);
- jbaudanza 12y agohttps://gist.github.com/sebmarkbage/07bbe37bc42b6d4aef81 https://gist.github.com/sebmarkbage/07bbe37bc42b6d4aef81
- claar 12y agoWow, the example in that gist: var component = <Component {...props} foo={'override'} />; Wha?? For me, there's a point in a language where the benefits of syntactic sugar are outweighed by readability concerns.
- jxm262 12y agoheydenberk explained it well, but just to add some clarity on why you'd want to use prototype.apply for array as an argument - http://stackoverflow.com/questions/2856059/passing-an-array-as-a-function-parameter-in-javascript http://stackoverflow.com/questions/2856059/passing-an-array-... http://stackoverflow.com/questions/1316371/converting-a-javascript-array-to-a-function-arguments-list http://stackoverflow.com/questions/1316371/converting-a-java... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I'm still learning more about JS and so I'm no expert, but it seems to be similar in concept to use the ... in other languages. I think Groovy has something similar and Java has the varargs. They have obvious differences, but conceptually I think of it as passing in a variable number of args.
- hardwaresofton 12y agoAs a person who is using react, this is a welcome change! I'm glad they're taking time to get rid of the kludgy code that wasn't quite consistent.
- jbhatab 12y agoHey can you explain how they improved consistency because I just don't understand how the new changes help. I may just not understand what they did at a fundamental level.
- hardwaresofton 12y agoIMHO it's more consistent because the things that react has been modifying have been Elements all along (DOM Elements). React called them components, and it's always felt like a kludge to create some thing that WAS a DOM element (boiling down to React.DOM), and then set it's "tagname" as an after-thought. Things like prop are tied directly to the DOM Element, further suggesting that the "thing" the component was, was actually a DOM Element. I guess it's really subjective, but I think it'll be clearer to explain to people now: "React manages creation and rendering of dynamic/intelligent (DOM) Elements" (bonus points for no overlap with the Web Components terminology) But then again a lot of this is just my opinion, consistency
- palcu 12y agoA sincere and big thank you for building and evolving this awesome tool that simplified UI madness in browsers. :-)
- glittershark 12y agoAlways really happy to see a ton of breaking changes in a pre-1.0 release, and very pleased that they're all moving towards simplifying the public API.
- fiatjaf 12y agoI don't get the React.isValidComponent -> React.isValidElement change. Wasn't "class" the name of the abstract idea of component and "component" the name of the actually rendered component, the class materialized in a DOM?
- spicyj 12y agoSee this post for a description of our terminology: http://facebook.github.io/react/blog/2014/10/14/introducing-react-elements.html http://facebook.github.io/react/blog/2014/10/14/introducing-... If I write var C = React.createClass(...); var e = <C />; var c = React.render(e, document.body); then C is a class, e is an element (previously "descriptor"), and c is the actual mounted component. Components are generally accessible only through "this", refs, and the return value of React.render.
- fiatjaf 12y agoI really don't see the point of making so much breaking changes just to simplify the public API. The thing was working, it was good. It didn't need any changes. God would have rested. But well, the developers were there and, you know, they cannot see a repository without commits for much time, right?
- ssorallen 12y agoTheir earlier blog post gives reasons for each of the API changes they made: https://facebook.github.io/react/blog/2014/10/14/introducing-react-elements.html https://facebook.github.io/react/blog/2014/10/14/introducing...
- spicyj 12y agoWe made these changes to try to make React better for everyone, but if you would like to continue using React 0.11, please do.
- fiatjaf 12y agoPlease, don't take this as an offense. I didn't mean to. This was an attempt of a joke, but it clearly didn't come out the way I wanted. I love React, I love you guys for making React and I'm sorry for this comment.
- bostonvaulter2 12y agoI've been looking into React.js recently and I have a general question. Is it possible to use React.js with zurb foundation cleanly? It appears that it will not work well because Foundation expects to modify the state of the DOM for Foundation elements. Are there any workarounds?
- biscarch 12y agoAfter looking into this I've come to the conclusion that rewriting the JavaScript to handle events through React's system is the best way to include Foundation's JS components. (This is something I'm planning to do with Foundation-for-Apps since I won't be using Angular). That said, the styles are still usable without modification and you could tell React to not handle pieces of the DOM in some cases for the existing JS.
- jaredgrippe 12y agoI have a huge problem with this change explained here: https://gist.github.com/deadlyicon/da8c020662ea8e6002dc https://gist.github.com/deadlyicon/da8c020662ea8e6002dc
- chenglou 12y agoRest assured, see sebmarkbage's and my reply here: https://news.ycombinator.com/item?id=8523732 https://news.ycombinator.com/item?id=8523732 https://news.ycombinator.com/item?id=8524465 https://news.ycombinator.com/item?id=8524465
- jaredgrippe 12y agoThe object literal syntax also sucks :( https://gist.github.com/deadlyicon/79c09610cac5a67f4a5d https://gist.github.com/deadlyicon/79c09610cac5a67f4a5d
- spion 12y agoAgreed. * JSX more tightly coupled, * less straightforward JSX->JS mapping - I used to be so excited to tell people how JSX simply maps to function calls in JS... well, now it generates boilerplate instead. * worse non-JSX syntax I don't buy the ES6/CS/TS argument - wrapping classes with createFactory before exporting seems fine to me, and I use typescript. Also, from what I can see the object literal syntax is always worse. So its basically all about Jest. The only reason I see is that a mocking tool can't handle factories. Makes me a bit sad. Seems like a good example of "test induced design damage" to me. How about adding plugins to that mocking tool instead?
- jaredgrippe 12y agoOne of my favorite patterns in React is using functions to wrap a React component. It goes something like this: App.Button = React.createClass({ render: function(){ var className = 'btn '+this.props.className <a href className={className}>{this.props.children}</a> } }); App.BigButton = function(props){ props = props || {}; props.className = 'btn-large '+props.className return App.Button.apply(null, arguments) }; How would you do something like this?
- spicyj 12y agoThe suggested way of doing this is define a new component like so: var BigButton = React.createClass({ render: function() { return ( <Button {...this.props} className={'btn-large ' + this.props.className} /> ); } }); (Before React 0.12 introduced the JSX spread syntax, this was handled by transferPropsTo.)
- sebmarkbage 12y agoThis is actually an anti-pattern that we're explicitly trying to get rid of. The fewer components you have, the fewer optimization hooks you have. This also have subtle changes in semantics, and disables local optimizations in the consuming files. The idea of a lightweight declaration of a component (e.g. a just function) is definitely still on the table and might be resurrected in a different form. https://github.com/reactjs/react-future/blob/master/01%20-%20Core/03%20-%20Stateless%20Functions.js https://github.com/reactjs/react-future/blob/master/01%20-%2...
- simplify 12y agoI'm disappointed that JSX is now so coupled to React. I was looking forward to JSX being used by many different JavaScript frameworks[1], but this change reveals the devs are not interested in moving that direction. [1] Example: https://github.com/mrsweaters/mithril-rails https://github.com/mrsweaters/mithril-rails
- spicyj 12y agoWe do actually want JSX to be flexible and usable for not just React, which is why we're trying to write a formal specification of the syntax with multiple parser implementations: http://facebook.github.io/jsx/ http://facebook.github.io/jsx/ We intentionally don't specify semantics to give different transpilers the flexibility to compile the JSX into whatever's appropriate for the library you're using.
- sebmarkbage 12y agoYea, note that mithril is on that list. The syntax was where people unified. There wasn't agreement on semantics and this is moving closer to that. It's possible that this will eventually unify again. E.g. around a replacement for an object literal. E.g. a standard record type.
- simplify 12y agoA specification is great, and I'm happy to see that. However, even though it's true that transpilers can compile JSX with arbitrary semantics, it still requires writing your own transpiler. JSX is a great syntax, and these changes mean nothing if you're a transpiler writer. What I was hoping for was the JSX transpiler that React uses would become flexible enough for any library to use, without the need to modify/rewrite the transpiler itself. Yes it's possible for someone else to write something like this, but writing a compiler is no small feat =/
- malandrew 12y agoJSX is a great syntax It's really not. It's just mixing syntaxes to solve the problem that mixed syntaxes causes. Higher order functions (i.e. createFactory) is a much better solution.
- xiaoma 12y agoOuch. I've been building dynamic components using transferPropsTo(), which is now deprecated. It's very flexible and working well, so I'm a bit bummed to see it go. render: function() { // after building up some object, propsObj that is determined by state return this.transferPropsTo( Component(propsObj) ); }
- lobster_johnson 12y agoNo problem, just do this instead: render: function() { // Assign propsObj here return <Component {...propsObj}/>; }
- scwoodal 12y agoAre the v0.11 docs available anywhere other than the Github markdown files?
- Kiro 12y agoHow are bindings in React not two-way? Update an input field and it updates the underlying JS object. Update the object and it updates the input field. I thought that was the definition of two-way, regardless of what happens behind the scenes.
- insin 12y agoIt doesn't update the underlying object for you by default. If you use an uncontrolled component (by giving it a defaultValue/defaultChecked prop) you have to pick up the new value using an event or directly via the DOM. If you do it this way, you can't update the displayed value by changing the props passed to it. If you use a controlled component (by giving it a value/checked prop), its displayed value won't update unless you pick up the new value from an event and set it in whichever JS object you have holding its state for the next render. There's a helper for doing that, or it's easy enough to roll your own event handler which takes care of all your fields. http://facebook.github.io/react/docs/forms.html http://facebook.github.io/react/docs/forms.html
- malandrew 12y agoWhat options are there for syncing flux stores on the server and client? I ask this because the increasing move towards microservices seems to suggest that "joins" are going to start taking place on the client via waitFor. For example, if I get model A and it depends on Models B, C and D. I don't want to have to wait for the client to fetch model A before it knows it needs to fetch models, B, C and D. Ideally, as model A passes through the server side store layer, it already starts fetching models B, C and D so it has those ready to serve to client, (or better yet it anticipates that the client is going to want B, C and D and eagerly sends that data to the client).
- collyw 12y agoThat sounds like a problem of pushing too much processing to the client side.
- collyw 12y agoA downvote for pointing that out. Can someone explain why I would want to do joins on the client side, when there is mature, well tested, well understood technology for doing joins on the server side? All the data is going to be on the server, so no danger of loosing a connection.
- deleted 12y ago[deleted]
- colinramsay 12y agoI think a real-world example might help to describe what you mean. Perhaps you could normalise the data in a way (on the server-side) that would remove the need for this setup?
- moondowner 12y agoThe license change paragraph mentions patents. Anyone knows which Facebook patents are used in React?