I want to do similar to scalajs-bootstrap for my own css. But as per my knowledge it doesn't perform partial dom update like Binding.scala does. I know we can use Binding.scala and scalatags together base on this but partial dom will not happen. Is there any solution?
Related
How does Binding.scala compare to the concept described here?
Apart from the design descriptions one might compare their implementations of TodoMVC:
Binding.scala
Scala.Rx + ScalaTags
Edit: By now I compared them to scalajs-react. I think react has a better performance, since e.g. for lists it updates only changed elements of the lists in the DOM, not the whole list.
Binding.scala's examples contain Scala XML tags as a language to code DOM fragments. Can scalatags be used instead?
Binding.scala internally generates very sophisticated ScalaTags code. On the other hand, manually written naive ScalaTags code recreates entire DOM whenever the data changes.
Milad Khajavi created an example demonstrating the problem of the manually written ScalaTags code: https://gitter.im/ThoughtWorksInc/Binding.scala?at=581b6367eed0c3125f30d57b
ScalaTags is very convenient for simple application. However, since they are plain function calls that do not have any ability to partially update, ScalaTags is not a good choice for a complex interactive application if you need fine-grained update on DOM.
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.
Which one is better, in terms of performance , to use : by.css or by.xpath or by.id.
I have a really lengthy xpath :
by.xpath('//*#id="logindiv"]/div[3]/div/div[1]/div/nav/div/div[1]/form/div/div/button')
which can be used with other selectors like by.css or by.id.
But it is not very clear which one is better.
Protractor uses selenium-webdriver underneath for element lookup/interaction etc, so this is not protractor specific question, but rather selenium-webdriver specific.
CSS selectors perform far better than Xpath and it is well documented in Selenium community. Here are some reasons,
Xpath engines are different in each browser, hence make them inconsistent.
Last time I checked, IE does not have a native xpath engine, therefore selenium-webdriver injects its own xpath engine for compatibility of its API. Hence we lose the advantage of using native browser features that selenium-webdriver inherently promotes.
Xpath tend to become complex like your example and hence make hard to read/maintain in my opinion.
However there are some situations where, you need to use xpath, for example, searching for a parent element or searching element by its text (I wouldn't recommend the later).
You can read blog from Simon(creator of selenium-webdriver) here . He also recommends CSS over Xpath.
So I would recommend you use id, name etc for faster lookup. If thats not available use css and finally use xpath if none other suite your situation.
I have about 6 forms to design with UIBinder that look almost the same, the difference is two or three fields. I was thinking about building one form with all the possible fields and hide or show fields depending on the case.
What do you think about this method?
It can work well. You can define a BaseForm class with UiBinder that implements HasWidgets, and then define SpecificForm1.ui.xml with something like
<custom:BaseForm>
<g:TextBox ui:field="componentSpecificToThisForm" />
<g:Button>A button!</g:button>
</custom:BaseForm>
and SpecificForm2.ui.xml with something like
<custom:BaseForm>
<g:Label>Something totally different</g:Label>
<g:Button>A button!</g:button>
</custom:BaseForm>
it works great!
I've tried something similar, and building one form where I hid/show the appropriate fields was the most simple solution. Another idea would be create a factory, which then builds your form according to your needs.
So, you basically create the components your form is composed of, and the factory wires them together via constructor dependency injection. Worked very well for me, and also has the added benefit that it is very easy to extend your form.
(I'll add an example later).