Fixing a few typos. Changing all instances of "thennable" to

"thenable". No functional changes.
This commit is contained in:
Sean Hussey 2015-12-17 15:16:55 -05:00
parent 49b97a5e56
commit c1912d2726
10 changed files with 30 additions and 30 deletions

View file

@ -477,7 +477,7 @@
### Bug Fixes:
- diff no longer touch the DOM when processing `style` attributes and event handlers
- returning a thennable to a resolution callback in `m.deferred().promise` now causes the promise to adopt its state
- returning a thenable to a resolution callback in `m.deferred().promise` now causes the promise to adopt its state
- diff now correctly clears subtree if null or undefined is passed as a node
---

View file

@ -62,7 +62,7 @@ var MyComponent = {
controller: function(data) {
return {
increment: function() {
//This is a simplication for the sake of the example.
//This is a simplification for the sake of the example.
//Typically, values are modified via model methods,
//rather than modified directly
model.count++
@ -590,7 +590,7 @@ where:
- **Component component**
A component is supposed to be an Object with two keys: `controller` and `view`. Each of these should point to a Javascript function. If a contoller is not specified, Mithril will automatically create an empty controller function.
A component is supposed to be an Object with two keys: `controller` and `view`. Each of these should point to a Javascript function. If a controller is not specified, Mithril will automatically create an empty controller function.
- **Object attributes**

View file

@ -152,7 +152,7 @@ The `m.startComputation` / `m.endComputation` pair is designed to be "stacked",
Therefore, using the computation methods is recommended in order to reduce the amount of intermediate redraws that would otherwise occur as multiple asynchronous services are resolved.
When computation methods are used dilligently and religiously, templates are never redrawn with incomplete data. However, it's important to always write conditional tests in templates to account for the possibility of nullables, because redraws may come to occur more aggressively than data is available (perhaps because a newly introduced 3rd party library calls `m.redraw`, or because you might want a more aggressive redraw policy to implement a specific feature down the road).
When computation methods are used diligently and religiously, templates are never redrawn with incomplete data. However, it's important to always write conditional tests in templates to account for the possibility of nullables, because redraws may come to occur more aggressively than data is available (perhaps because a newly introduced 3rd party library calls `m.redraw`, or because you might want a more aggressive redraw policy to implement a specific feature down the road).
Defending against nullables can typically be achieved via the `initialValue` option in [`m.request`](mithril.request.md) and basic null checks (e.g. `data ? m("div", data) : null`).

View file

@ -165,7 +165,7 @@ m.request({method: "GET", url: "/user/:id", data: {id: 1}})
.then(function(user) {
if (!user.isAdmin) throw new Error("Sorry, you don't have permissions")
})
.then(null, error) //handle the application error: bind to a getter-setter for diplaying it on the template
.then(null, error) //handle the application error: bind to a getter-setter for displaying it on the template
```
Note that the default promise exception handling semantics can be modified. See the next section.

View file

@ -26,7 +26,7 @@ The [`m.startComputation` / `m.endComputation` pair](mithril.computation.md) is
Therefore, using the computation methods is recommended in order to reduce the amount of intermediate redraws that would otherwise occur as multiple asynchronous services are resolved.
When computation methods are used dilligently and religiously, templates are never redrawn with incomplete data. However, it's important to always write conditional tests in templates to account for the possibility of nullables, because redraws may come to occur more aggressively than data is available (perhaps because a newly introduced 3rd party library calls `m.redraw`, or because you might want a more aggressive redraw policy to implement a specific feature down the road).
When computation methods are used diligently and religiously, templates are never redrawn with incomplete data. However, it's important to always write conditional tests in templates to account for the possibility of nullables, because redraws may come to occur more aggressively than data is available (perhaps because a newly introduced 3rd party library calls `m.redraw`, or because you might want a more aggressive redraw policy to implement a specific feature down the road).
Defending against nullables can typically be achieved via the `initialValue` option in [`m.request`](mithril.request.md) and basic null checks (e.g. `data ? m("div", data) : null`).

View file

@ -51,7 +51,7 @@ var users = m.request({method: "GET", url: "/user"});
Note that this getter-setter holds an *undefined* value until the AJAX request completes. Attempting to unwrap its value early will likely result in errors.
The returned getter-setter also implements the [promise](mithril.deferred.md) interface (also known as a *thennable*): this is the mechanism you should always use to queue operations to be performed on the data from the web service.
The returned getter-setter also implements the [promise](mithril.deferred.md) interface (also known as a *thenable*): this is the mechanism you should always use to queue operations to be performed on the data from the web service.
The simplest use case of this feature is to implement functional value assignment via `m.prop` (i.e. the same thing as above). You can bind a pre-existing getter-setter by passing it in as a parameter to a `.then` method:
@ -73,9 +73,9 @@ var doSomething = function() { /*...*/ }
m.request({method: "GET", url: "/user"}).then(users).then(doSomething)
```
While both basic assignment syntax and thennable syntax can be used to the same effect, typically it's recommended that you use the assignment syntax whenever possible, as it's easier to read.
While both basic assignment syntax and thenable syntax can be used to the same effect, typically it's recommended that you use the assignment syntax whenever possible, as it's easier to read.
The thennable mechanism is intended to be used in three ways:
The thenable mechanism is intended to be used in three ways:
- in the model layer: to process web service data in transformative ways (e.g. filtering a list based on a parameter that the web service doesn't support)
- in the controller layer: to bind redirection code upon a condition
@ -122,7 +122,7 @@ var controller = function() {
#### Binding errors
Mithril thennables take two functions as optional parameters: the first parameter is called if the web service request completes successfully. The second one is called if it completes with an error.
Mithril thenables take two functions as optional parameters: the first parameter is called if the web service request completes successfully. The second one is called if it completes with an error.
Error binding is meant to be done in the controller layer. Doing it in the model level is also possible, but generally leads to more code in order to connect all the dots.

View file

@ -108,7 +108,7 @@ In the example below, we bind an error getter-setter to our previous controller
//controller
var controller = function() {
this.error = m.prop("")
this.users = User.listEven().then(function(users) {
if (users.length == 0) m.route("/add");
}, this.error)
@ -121,7 +121,7 @@ If the controller doesn't already have a success callback to run after a request
//controller
var controller = function() {
this.error = m.prop("")
this.users = User.listEven().then(null, this.error)
}
```
@ -145,7 +145,7 @@ var users = m.request({method: "GET", url: "/user"})
//add one more user to the response
return users.concat({name: "Jane"})
})
function log(value) {
console.log(value)
return value