Declarative User Interfaces

React’s language

With React's new language of outcomes, which browsers now understand, we can build declarative user interfaces (like we used to do with pure HTML), but now we can work with data as well.

For our products example, we just command the browser to display a list of products; we don’t even worry about how many products are actually on that list.

Our command to the browser is: this: dDisplay this list of products as an unordered list; for every product, display its name, then display its price.

After that, we’re done. When the data we have for the list of products changes, we don’t need to do anything to our UI to get it updated with the new data. Our command to the browser does not need to be changed.

In other words, if we have transitions on the data, we don't have to worry about the user interface—we just manage the new state of our data.

Data transitions include operations like the following:

• One product was removed from the catalog.
• Three more products were added to the catalog.
• A product name has changed.
• Five products' prices have changed.
• The order of the products in the catalog has changed.

Of course, we have to change our views if the structure of our data changes. For example, when we add a Boolean flag to every product to track whether the product is available in stock or not, and we want to display the out-of-stock products in greay., Tthis would be a structure transition, not just a data transition., but oOnce we account for the new structure for the first time though, updating that new flag becomes just a data transition that we don't have to worry about in the UI.

This mental model about modeling the final state is much easier to understand and work with, especially when our views have lots of data transitions.

For example, consider the view that tells you how many of your friends are online. The view state will be just one single number of how many of friends are currently online. This view does not care that a moment ago, three friends came online, then one of them disconnected, then two more joined. It just knows that at this current moment, four friends are online.

To JSX or not to JSX

Writing HTML in JavaScript gives us a lot of power and advantages over using templates and display logic. But working with HTML directly has great advantages, whi cthat we would sacrifice in this case. HTML is familiar and concise, and if you work with designers, they would certainly hate to work with our JavaScript-created elements.

JSX is the optional compromise. It is a simple HTML-like JavaScript syntax extension used to create React elements. You can think of JSX as an enhancement of JavaScript to allow for syntax that looks like HTML. We can use it in the return statement of a component’s render function.

JSX is labeled “HTML-like” because it can’t be exactly HTML. Some element attributes have to be used the way the DOM API defines them; class and for are both examples of this. To use them in React, we use className and htmlFor instead.

The following Eexample : is Aan email input field interface.

Code Listing 10: JSX

It’s important to understand that JSX is completely optional, and not required to use React. We can write React in plain JavaScript; we don’t need the JSX extension.

JSX is actually not shipped with React at all; we will need third-party tools to make our project work with JSX. The Facebook-recommended tool is Babel.

Writing components render functions in JSX instead of pure JavaScript has the advantage of being concise and familiar, and that’s especially true for designers. Balanced opening and closing tags are much easier to read and parse with the human eye than JavaScript functions and object literals.