51–60 of 62 posts
If you haven't already, you should be betting on React. It's the future: > 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 t…
It's the now. Elm is the future elm-lang.org
We're considering trying react for a new project, and just read about the adoption of Babel [1] instead of the internal transpiler previously used for JSX. One question: does this mean that JSX will be able to use ES6 syntax supported by Babel out of the box? If so, will this be the default for this new version of React? I ask the questions also because we would really like to be able to use React with CoffeeScript,…
From personal experience I'll just use ES6. 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 adopt…
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')..
If you haven't already, you should be betting on React. It's the future: > 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 t…
I'm extremely excited about this release because of the change to context from Owner-based to Parent-based. 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.
About the refs, I've been using a small helper: h.ref(this, 'some-element.children-element'); and its companion h.$ref(this, 'some-element.children..'); for the jquery version. 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').. Which basically transforms to this.refs.header.refs.se…
But that should continue to work fine.
If you haven't already, you should be betting on React. It's the future: > 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 t…
Seriously: do you think it can revert the "native mobile apps is the only future" trend?
we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node. 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…
we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node. 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…
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 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 mak…
If you haven't already, you should be betting on React. It's the future: > 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 t…
Sure, it's the future but currently it's still quite far away, React Native is available only for iOS (and in a quite beta state) and the components are not fully sharable between both of them yet. But yes, I agree, I can't wait for this !