React v0.14 Beta 1 released(facebook.github.io) |
React v0.14 Beta 1 released(facebook.github.io) |
> More importantly, this paves the way to writing components that can be shared between the web version of React and React Native. This isn't yet easily possible, but we intend to make this easy in a future version so you can share React code between your website and native apps.
Isn't this what we have all been waiting for? Writing components that are composable, that are "isomorphic or universal", that can run on Native or DOM without any downsides of it's predecessors.
Aside, the article also mentions a migration tool [1] to help you port your code from 0.13 to 0.14. While others may have done so before, it's pretty cool that this is streamlined as part of the beta release.
I've heard that too many times to not be cynical about it.
I do agree to the extent that things like PhoneGap do result in compromises. But React Native is basically a templating tool for native apps – you're still free to write whatever native components you require, but can compose these using React, which is pretty cool. You can then abstract the higher-level components across platforms.
As you say, React is the present, and it's making progressive enhancement easier right now.
It's the now. Elm is the future elm-lang.org
But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow.
Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change."
By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble.
Isn't this what we have all been waiting for?
It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app.
In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components.
I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here.
If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries.
> Isn't this what we have all been waiting for?
> We think the true foundations of React are simply ideas of components and elements: being able to describe what you want to render in a declarative way. These are the pieces shared by all of these different packages (react-native, react-art, react-canvas, react-three). The parts of React specific to certain rendering targets aren't usually what we think of when we think of React.
I've not played with React-native yet (waiting for Android) but I feel this is a positive step towards their vision of "learn once, write anywhere". From the twitter updates it seems, Sebestian Markbage, gave a pretty cool talk on the same topic at ReactEurope yesterday. Can't wait to check that out. https://twitter.com/chantastic/status/616679794479112193
> To make this more clear and to make it easier to build more environments that React can render to, we're splitting the main react package into two: react and react-dom.
Great to see the react team responding positively to the developments in community and not being afraid to take hard decisions (like this one)
Lastly, if you're a web developer and deciding between going the 'web components' route or the React route, this announcement gives you, IMHO, an even more impetus to pick up React.
This only holds if you use Facebook's particular flavour of Flux, I guess.
Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something. I can use refs to do this.refs.subcomponent.onWindowShow() and this makes my code very clean and flexible - it keeps browser event stuff out of my flux stores, and only the actual important user data in there.
Similarly, I use refs to ask an <Input> component whether its value is valid according to some validation rule. I could also give the Input an onValueValidityChanged prop, but that just increases the amount of bookkeeping I need to do. If I'm rendering a form with 2 inputs, name and email, calling "this.refs.name.isValid()" in some onButtonClick handler makes a lot of sense to me.
I really liked how React was separated from particular architecture patterns, but this change makes that a lot more difficult. I really hope this change can still be reversed.
I feel it's a bit premature to separate `react` and `react-dom`. React has proven itself for the web but still has to prove itself as `react-native` and I don't get the friction/complexity being added by break it down into two components for the web. I feel React is more the rendering engine `react-dom` than the class/component system now `react`. What makes React beautiful is to be able to freely mix html into JS and not being limited to the render() call, so I feel the cut is a bit non-organic.
Finally, I love the approach `learn once, write anywhere` but having `react` as a thing by itself points (or at least confuses) to a workflow where you can write components by themselves then plug a rendering engine DOM or native, I don't think that's the initial intent and I don't think that's the intent now of this release as well but it's unnecessary confusing.
[Edit] Don't fully get why I've been downvoted.
I ask the questions also because we would really like to be able to use React with CoffeeScript, but, even if there are many solutions to do so, no one is supported by Facebook and we're worried about future compatibility. Is adopting Babel going to influence the ability to use React with CS?
[1] https://facebook.github.io/react/blog/2015/06/12/deprecating...
One change remove assumption about DOM as rendered target, while another change means DOM must be the rendered target.
Requiring ReacDOM.findDOMNode(ref) should be what they do if they want to encourage multiple rendering target.
The removal of .getDOMNode() was intentionally done in concert with this change: previously, all component classes created with React would magically have that DOM-specific method added to them; this way, component classes are less tied to specific rendering environments. If you need to call ReactDOM.findDOMNode then yes, your components will be tied to the ReactDOM renderer.
Sounds good!
If not already, react-dom will probably be easily replaceable by modules like virtual-dom?
Authoring react-resolver meant jumping through weird hoops to avoid context changing, but this release should mean things will work as expected, rather than having to sort out "gotchas".
There goes my July 4th weekend :)
It's going to be a boon for libraries which use DSL-like ancestor components.
h.ref(this, 'some-element.children-element');
I don't have a strict rule of when using it, but sometimes it's cleaner than having lots of nested callback on an inner children.. I.e. I can just do:
h.$ref(this, 'header.search.input')..
But that should continue to work fine.
Let's say you have a "SearchComponent" with a "SearchButtonComponent" and "SearchInputComponent", I'm okay with using the strategy I suggested because using "SearchInputComponent" without its parent somewhere else in the code would be too risky so the encapsulation is still kept between parent/children.
Presumably the react/react-dom breaks all current third party packages for now?
One of our goals with this release is actually to help with the problem you mention of interdependencies and component versioning: we expect most components to only depend on the "react" package, which will be more stable and updated less frequently.
Thankfully the React community moves fast and package authors are usually quick to update to new React versions.
P.S. We've been making releases every 6 months or so, so we're already at "stable for a few months". We might speed this up a little but we never want the pace to be unmanageable. (The four of us on the core team need to make sure the 10,000 components in the Facebook codebase continue to work, so I assure you we don't take breaking changes lightly.)
Thanks so much for React - it really is an amazing way to work and moving to it has simplified the extremely complex and interactive app I'm building!
Am i the only one getting a bit cynical that we're now hoping that a 1.0 is stable enough 'for a few months'?
This release includes the old methods in the react package with a deprecation warning, but they'll be removed completely in 0.15
Customer components, e.g. an <MyInput> component that wraps a DOM <input> and provides custom onWindowShow() functionality are unaffected.
Isn't that a bit of an antipattern? It seems that sending events down the hierarchy is something that React goes out of its way to make awkward, and on purpose.
In the case you've given, I'm not clear why you wouldn't just bind to the window's focus and blur events from within componentWillMount, anyway.
Another use case that I came across was where we wanted a search dropdown to open in the header when a user clicked somewhere in the middle of the page content. One option would be to make a PageStateStore and add an isSearchDropdownVisible to it, but I don't like doing flux that way because I don't want UI details to be part of my model later.
I think having isVisible in the SearchDropdown state is much more elegant, but that poses the slight problem of how to change that state from the other side of the page. We did that by having the item in the page have an onWantToSearch event, which the page had a handler for that invoked this.refs.header.showSearch(), which in turn invoked this.refs.searchDropdown.setVisible(true), which did a simple this.setState({isVisible: true}).
So, in general, the event first bubbles all up the tree (through custom react onSomething, onSomethingElse props), and then bubbles down the tree (through method calls on refs). This exposes a really elegant design, because it made the Header component be "a thing that allows searching" (because it has a showSearch() method), and the page item an "a thing that allows a user to initiate a search action" (because it has a onWantToSearch event). The available methods and onSomething props of all components perfectly matched the possible behaviors of the components, and no behaviour is "hidden" inside a singleton mesh of flux stores.
There's a CoffeeScript JSX transformer here if you're interested:
https://github.com/jsdf/coffee-react
and we'll continue to support using React without JSX, and though we use Babel now internally, we compile React itself to ES5 before putting it on npm so you don't need to use Babel if you don't want to.
I think the JSX transpiler was deprecated some time ago and pretty much all the react starter templates and examples have been using Babel.
I don't think adopting babel is going to compromise your use of coffeescript, in then babel is just transpiling down to old style javascript.
It's not about the HTML-like JSX part using ES6 or using native classes to extend React.component(with limitations), but simpler object literals, fat arrows and { foo: foo } becoming { foo } make React code look much better. I can endure the ending semicolons, parens and brackets.
Now you don't really gain too much by opting for CS over ES6 for React. And with React's adoption of Babel I think ES6 is going to become the primary way of writing React apps.