291–300 of 318 posts
Earlier quoted context omitted.
The "concerns about patent usage" is a tired trope as well. Yes, if you use React you're basically agreeing not to sue Facebook over patents. Except if Facebook was acting in bad faith they'd probably have enough patents you could be found in violation of to ruin you anyway. If your software is non-trivial, it's already violating patents you probably never even heard of. But the real kicker is that if you're not usin…
The patent retaliation is more broad than the provision in the Apache license though, which basically only revoke the patent grants for a specific work if you sue over patent infringement in the same work. http://en.swpat.org/wiki/Patent_clauses_in_software_licences...
React, like most JS projects, is licensed under an MIT/BSD style license (they're too similar to be worth the distinction in this context).
The alternative to having the FB patent grant wouldn't be to have the Apache 2.0 patent grant. It would be having no patent grant, as is the case with AngularJS, Ember and jQuery.
Which is completely beside the most important point: if you don't use React, you might be still affected by React-related patents owned by Facebook and there's no patent grant preventing them from suing you -- and this holds true for all patents owned by everybody else.
The default for JS projects is no patent grant. FB is actually more benign than any of the alternatives by providing a patent grant at all.
Not only is the argument entirely theoretical (If FB doesn't sue you over React patents, they might still sue you over non-React patents or someone else might sue you over React patents FB doesn't hold) but it's also invalid (FB doesn't benefit from offering a patent grant compared to not offering a patent grant -- which would have been the default for open source projects like React).
If you just want to argue that FB could have done more, yes of course they could have. But that's like shouting at someone giving you a free penny why they don't give you a free dollar.
Earlier quoted context omitted.
As someone who uses a different component-based js framework, can you not just put a breakpoint in the chrome dev tools on the renderComponent method for that component?
renderComponent is not part of any of your components. I think the React equivalent of what you mean is the render method of a component. The problem I think the OP is talking about is when there is an error thrown somewhere in the react library code (e.g. in renderComponent) and the stack trace doesn't even touch any of your code. That makes it really hard to find the fault behind the error. This is a lot more commo…
Earlier quoted context omitted.
You really need to check out Elm. It's an ML-like language with built in functional reactive framework similar to React, but built to work naturally with the language rather than requiring the FFI binding you'd need if you use Purescript.
Elm's type systems is really constrained compared to PureScript's. It's great for people coming from JavaScript, but not so much for those coming from Haskell. Also, you still need FFI in Elm. elm-lang/virtual-dom is basically just a wrapper around the native virtual-dom library. Also, afaik there's nothing like react native for virtual-dom.
I'm a skeptical native mobile developer. What are some examples of good apps currently in the store, written in React Native?
There are none, really. Maybe Discord? Other than that there are no widely known apps that uses React Native.
Is anyone using TypeScript with React Native? I'd be interested to see how easy that is to integrate.
In that case it would probably make more sense to just use NativeScript instead of React Native. https://www.nativescript.org/
After reading this and other comments here, I sort of just wish there were Haxe bindings for to the React Native stuff.