vndb/mithril-vndb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

change docs wip

Browse source
This commit is contained in:
Leo Horie 2015-04-03 10:32:20 -04:00
parent f85e3a675c
commit bffc5d2eec
4 changed files with 8 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/auto-redrawing.md
View file

@ -4,7 +4,7 @@ Mithril is designed around the principle that data always flows from the model t
In addition, Mithril attempts to intelligently redraw only when it is appropriate in an application lifecycle. Most frameworks redraw aggressively and err on the side of redrawing too many times because, as it turns out, determining the best time to do a redraw is quite complicated if we want to be as efficient as possible.
Mithril employs a variety of mechanisms to decide the best time and the best strategy to redraw. By default, Mithril is configured to auto-redraw from scratch after module controllers are initialized, and it is configured to diff after event handlers are triggered. In addition, it's possible for non-Mithril asynchronous callbacks to trigger auto-redrawing by calling `m.startComputation` and `m.endComputation` in appropriate places (see below). Any code that is between a `m.startComputation` and its respective `m.endComputation` call is said to live in the *context* of its respective pair of function calls.
Mithril employs a variety of mechanisms to decide the best time and the best strategy to redraw. By default, Mithril is configured to auto-redraw from scratch after component controllers are initialized, and it is configured to diff after event handlers are triggered. In addition, it's possible for non-Mithril asynchronous callbacks to trigger auto-redrawing by calling `m.startComputation` and `m.endComputation` in appropriate places (see below). Any code that is between a `m.startComputation` and its respective `m.endComputation` call is said to live in the *context* of its respective pair of function calls.
It's possible to defer a redraw by calling `m.request` or by manually nesting [`m.startComputation` and `m.endComputation`](mithril.computation.md) contexts. The way the redrawing engine defers redrawing is by keeping an internal counter that is incremented by `m.startComputation` and decremented by `m.endComputation`. Once that counter reaches zero, Mithril redraws. By strategically placing calls to this pair of functions, it is possible to stack asynchronous data services in any number of ways within a context without the need to pass state variables around the entire application. The end result is that you can call `m.request` and other integrated data services seamlessly, and Mithril will wait for all of the asynchronous operations to complete before attempting to redraw.

2
docs/comparison.md
View file

@ -118,8 +118,6 @@ Knockout is a library focused on data binding. It is not an MVC framework in the
A Knockout view model is an amalgamation of model and controller layers in a single class. In contrast, Mithril separates the two layers more distinctly.
Generally speaking, Knockout applications tend to be more tightly coupled than Mithril since Knockout doesn't provide an equivalent to Mithril's modules and components.
As with Angular, Knockout templates are written in HTML, and therefore have the same pros and cons as Angular templates.
### Vue

10
docs/getting-started.md
View file

@ -33,15 +33,15 @@ Yes, this is valid HTML 5! According to the specs, the `<html>`, `<head>` and `<
### Model
In Mithril, an application typically lives in a namespace and contains modules. Modules are merely structures that represent a viewable "page" or a part of a page. In addition, an application can be organizationally divided into three major layers: Model, Controller and View.
In Mithril, an application typically lives in a namespace and contains components. Components are merely structures that represent a viewable "page" or a part of a page. In addition, an application can be organizationally divided into three major layers: Model, Controller and View.
For simplicity, our application will have only one module, and we're going to use it as the namespace for our application.
For simplicity, our application will have only one component, and we're going to use it as the namespace for our application.
In Mithril, a *module* is an object that contains two functions: `controller` and `view`.
In Mithril, a *component* is an object that contains two functions: `controller` and `view`.
```
//an empty Mithril module
var myModule = {
//an empty Mithril component
var myComponent = {
controller: function() {},
view: function() {}
}

3
docs/layout/api.html
View file

@ -26,7 +26,8 @@
<h3 id="core">Core</h3>
<ul>
<li><a href="mithril.html" title="A utility to create virtual elements">m</a></li>
<li><a href="mithril.module.html" title="Initializes a controller/view pair">m.module</a></li>
<li><a href="mithril.component.html" title="Creates a component">m.component</a></li>
<li><a href="mithril.mount.html" title="Renders a component">m.mount</a></li>
<li><a href="mithril.prop.html" title="A getter-setter utility">m.prop</a></li>
<li><a href="mithril.withAttr.html" title="A event handler factory utility">m.withAttr</a></li>
</ul>