Now that it's no longer recommended (or possible, given ES6 classes) to use the StylePropable mixin (and because libraries like react-mixin, that try to turn them into decorators have been nothing but trouble), and given that an official replacement hasn't been developed to my knowledge, what's the recommended way to incorporate the behavior (such as auto-prefixing) of the functions it provided, such as prepareStyles? I'm using ^0.14.0.
Related
I see many instances of # sign like #package_name or #somthing in dart. Although I know the usage of some examples like #override, I can't understand why some packages(eg: #freezed) or dart syntax(eg: #immutable,#lazySingleton) use this operator and what its functionality is.
it's metadata read here about it: dart language-tour
As Kherel mentioned, the # symbol is for metadata. It helps developers keep track of certain functions for future purposes.
If you want, you can then use that metadata for programmatic purposes using the 'dart:mirrors' library.
For example, flutter uses #override to ensure that child classes are allowed their specific behavior, separate from the parents.
The most common usage is to classify functions and classes in some way for easy access. IDEs may also keep track of certain metadata to warn you about the way functions operate (via #TODO or #deprecated, for instance).
What are the advantages of one versus the other?
Is one being deprecated and I should be using the newer one whichever that may be?
Should I be creating Components or React Class to develop my UI?
I see some examples using Component. For example:
export default class ItemList extends Component {
constructor(props) {
//binding functions
this.renderHeader = this.renderHeader.bind(this);
this.renderRow = this.renderRow.bind(this);
super(props);
this.state = {
dataSource: this.props.state.planDataSource,
planName: null
}
}
And others using
var ItemList = React.createClass({
getInitialState: function() {
return {
dataSource: this.props.state.planDataSource,
planName: null
};
},
I am learning react-native by example and I am confused as to which is preferred.
I recently converted a React class to a component and discovered that the "this" pointer does not work because React classes used autobinding and Components require explicit binding.
You should prefer Class over createClass because it will probably be deprecated.
The most notable new feature is support for ES6 classes, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace React.createClass completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate React.createClass.
https://facebook.github.io/react/blog/2015/03/10/react-v0.13.html
No Autobinding
Methods follow the same semantics as regular ES6
classes, meaning that they don't automatically bind this to the
instance. You'll have to explicitly use .bind(this) or arrow functions
=>.
No Mixins
Unfortunately ES6 launched without any mixin support.
Therefore, there is no support for mixins when you use React with ES6
classes. Instead, we're working on making it easier to support such
use cases without resorting to mixins.
https://facebook.github.io/react/docs/reusable-components.html
Unless you're using mixins, always use class (read ES6) instead of React.createClass. Most of the react-native code are in ES6, so it helps to stay up to date with the current standards.
There is no difference regarding performance/UI. class (ES6) is a better way of writing react/react-native/JS code anyways. FWIW: http://es6-features.org/.
As I saw in you comment, you're looking for an answer in simple words:
When looking at the example you provide in your question, you might be thinking "Oh my, why should I use this more verbose version with extends Component if it basically does the same as createClass?"
Well, the syntax using extends Component is the modern way of writing React Native UI Components and Javascript code in general. You should stick to this all the time unless you need a special feature called mixins because using the createClass way of writing components might soon be deprecated in React Native as pointed out by the other answers.
This modern version of Javascript is called ECMAScript 6 (with its compiler called babel which translates the new Javascript syntax into the old one so that that the current browsers can all understand it). It introduced this new more object-oriented way of writing Javascript with classes.
The naming in React is quite confusing when starting to transition to the new JS syntax, because the old syntax with createClass actually is not part of the new object-oriented syntax with classes, methods and such.
This article nicely contrasts the differences between the two syntax styles you asked about in your question.
As an additional tipp, you don't have to bind this to your functions (e.g. this.renderHeader = this.renderHeader.bind(this); in your example if you define your custom functions by using another feature of ECMAScript 6 called arrow functions. This immediately deletes two more lines of code from your example and the two approaches require roughly the same amount of typing.
Recently I have started to use Google Closure Tools for my javascript development. Until now, I have used to write my code in CoffeeScript, however, the javascript generated by CoffeeScript seems to be incompatible with Google Closure Compiler's advanced mode.
Is there any extension to the CoffeeScript compiler adding Google Closure support?
There are various tools that aiming to make CoffeeScript usable with Google Closure Tools. I will describe three of them:
Bolinfest's CoffeeScript fork
Features:
Fixed function binding, loops, comprehensions, in operator and various other incompatibilities
Fixed classes syntax for Google Closure
Automatic generation of #constructor and #extends annotations
Automatically inserts goog.provide statement for each class declared
Python's like include namespace as alias support translated to goog.require and goog.scope
Drawbacks:
Constructor has to be the very first statement in the class
Cannot use short aliases for classes inside the class (i.e. class My.Long.Named.Car cannot be refered as Car in class definition as pure CoffeeScript allows)
User written JsDoc comments don't get merged with compiler generated ones
Missing provide equivalent for include
No support for type casting, this can be done only by inserting pure javascript code inside backticks "`"
Based on outdated CoffeeScript 1.0
Read more at http://bolinfest.com/coffee/
My CoffeeScript fork
Disclaimer: I am the author of this solution
This solution is inspired by the Bolinfest's work and extends it in these ways:
Constructor can be placed anywhere inside the class
Short aliases for classes work using goog.scope
User written JsDoc comments get merged with compiler generated, user written #constructor and #extends annotations are replaced by generated
Each namespace is provided or included mostly once, namespace, that is provided is never included. You can provide namespace by keyword provide
Support for typecasting using cast<typeToCastTo>(valueToBeCast) syntax
Based on CoffeeScript 1.6
Read more at https://github.com/hleumas/coffee-script/wiki
Steida's Coffee2Closure
Unlike the two solutions above, Steida's Coffee2Closure is postprocessor of javascript code generated by upstream nontweaked CoffeeScript. This approach has a one major advantage, that it will need no or only slight updates with continued development of CoffeeScript and still be actual. However, by the very nature of this approach, some of the features cannot be delivered. Currently it fixes only classes and bindings, loops, in operator and few other incompatibilities. It has no support for automatic annotation generation, type casting or custom keywords.
https://github.com/Steida/coffee2closure
I am using the MPJ-api for my current project. The two implementations I am using are MPJ-express and Fast-MPJ. However, since they both implement the same API, namely the MPJ-API, I cannot simultaneously support both implementations due to name-space collisions.
Is there any way to wrap two different libraries with the same package and class-names such that both can be supported at the same time in Java or Scala?
So far, the only way I can think of is to move the module into separate projects, but I am not sure this would be the way to go.
If your code use only a subset of MPI functions (like most of the MPI code I've reviewed), you can write an abstraction layer (traits or even Cake-Pattern) which defines the ops your are actually using. You can then implement a concrete adapter for each implementation.
This approach will also work with non-MPI communication layers (think Akka, JGroups, etc.)
As a bonus point, you could use the SLF4J approach: the correct implementation is chosen at runtime according to what's actually in the classpath.
I was a little surprised when I started using Lift how heavily it uses reflection (or appears to), it was a little unexpected in a statically-typed functional language. My experience with JSP was similar.
I'm pretty new to web development, so I don't really know how these tools work, but I'm wondering,
What aspects of web development encourage using reflection?
Are there any tools (in statically typed languages) that handle (1) referring to code from a template page (2) object-relational mapping, in a way that does not use reflection?
Please see lift source. It doesn't use reflection for most of the code that I have studied. Almost everything is statically typed. If you are referring to lift views they are processed as Xml nodes, that too is not reflection.
Specifically referring to the <lift:Foo.bar/> issue:
When <lift:Foo.bar/> is encountered in the code, Lift makes a few guesses, how the original name should have been (different naming conventions) and then calls java.lang.Class.forName to get the class. (Relevant code in LiftSession.scala and ClassHelpers.scala.) It will only find classes registered with addToPackages during boot.
Note that it is also possible (and common) to register classes and methods manually. Convention is still that all transformations must be of the form NodeSeq => NodeSeq because that is the only thing which makes sense for an untyped HTML/XHTML output.
So, what you have is Lift‘s internal registry of node transformations on one side, and on the other side the implicit registry of the module. Both types use a simple string lookup to execute a method. I guess it is arguable if one is more reflection based than the other.