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

Consistent naming of Mithril.js

Browse source
This commit is contained in:
Stephan Hoyer 2022-02-18 09:08:10 +01:00
parent 7b1fda5b66
commit 885b3f9442
48 changed files with 269 additions and 269 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/autoredraw.md
View file

@ -4,15 +4,15 @@ The Mithril.js auto-redraw system re-renders your app after some functions compl
# The auto-redraw system
Mithril implements a virtual DOM diffing system for fast rendering, and in addition, it offers various mechanisms to gain granular control over the rendering of an application.
Mithril.js implements a virtual DOM diffing system for fast rendering, and in addition, it offers various mechanisms to gain granular control over the rendering of an application.
When used idiomatically, Mithril employs an auto-redraw system that synchronizes the DOM whenever changes are made in the data layer. The auto-redraw system becomes enabled when you call `m.mount` or `m.route` (but it stays disabled if your app is bootstrapped solely via `m.render` calls).
When used idiomatically, Mithril.js employs an auto-redraw system that synchronizes the DOM whenever changes are made in the data layer. The auto-redraw system becomes enabled when you call `m.mount` or `m.route` (but it stays disabled if your app is bootstrapped solely via `m.render` calls).
The auto-redraw system simply consists of triggering a re-render function behind the scenes after certain functions complete.
### After event handlers
Mithril automatically redraws after DOM event handlers that are defined in a Mithril view:
Mithril.js automatically redraws after DOM event handlers that are defined in a Mithril.js view:
```javascript
var MyComponent = {
@ -48,7 +48,7 @@ m.mount(document.body, MyComponent)
### After m.request
Mithril automatically redraws after [`m.request`](request.md) completes:
Mithril.js automatically redraws after [`m.request`](request.md) completes:
```javascript
m.request("/api/v1/users").then(function() {
@ -67,7 +67,7 @@ m.request("/api/v1/users", {background: true}).then(function() {
### After route changes
Mithril automatically redraws after [`m.route.set()`](route.md#mrouteset) calls and after route changes via links using [`m.route.Link`](route.md#mroutelink).
Mithril.js automatically redraws after [`m.route.set()`](route.md#mrouteset) calls and after route changes via links using [`m.route.Link`](route.md#mroutelink).
```javascript
var RoutedComponent = {
@ -91,11 +91,11 @@ m.route(document.body, "/", {
---
### When Mithril does not redraw
### When Mithril.js does not redraw
Mithril does not redraw after `setTimeout`, `setInterval`, `requestAnimationFrame`, raw `Promise` resolutions and 3rd party library event handlers (e.g. Socket.io callbacks). In those cases, you must manually call [`m.redraw()`](redraw.md).
Mithril.js does not redraw after `setTimeout`, `setInterval`, `requestAnimationFrame`, raw `Promise` resolutions and 3rd party library event handlers (e.g. Socket.io callbacks). In those cases, you must manually call [`m.redraw()`](redraw.md).
Mithril also does not redraw after lifecycle methods. Parts of the UI may be redrawn after an `oninit` handler, but other parts of the UI may already have been redrawn when a given `oninit` handler fires. Handlers like `oncreate` and `onupdate` fire after the UI has been redrawn.
Mithril.js also does not redraw after lifecycle methods. Parts of the UI may be redrawn after an `oninit` handler, but other parts of the UI may already have been redrawn when a given `oninit` handler fires. Handlers like `oncreate` and `onupdate` fire after the UI has been redrawn.
If you need to explicitly trigger a redraw within a lifecycle method, you should call `m.redraw()`, which will trigger an asynchronous redraw.
@ -115,7 +115,7 @@ function StableComponent() {
}
```
Mithril does not auto-redraw vnode trees that are rendered via `m.render`. This means redraws do not occur after event changes and `m.request` calls for templates that were rendered via `m.render`. Thus, if your architecture requires manual control over when rendering occurs (as can sometimes be the case when using libraries like Redux), you should use `m.render` instead of `m.mount`.
Mithril.js does not auto-redraw vnode trees that are rendered via `m.render`. This means redraws do not occur after event changes and `m.request` calls for templates that were rendered via `m.render`. Thus, if your architecture requires manual control over when rendering occurs (as can sometimes be the case when using libraries like Redux), you should use `m.render` instead of `m.mount`.
Remember that `m.render` expects a vnode tree, and `m.mount` expects a component:
@ -127,4 +127,4 @@ m.render(document.body, m(MyComponent))
m.mount(document.body, MyComponent)
```
Mithril may also avoid auto-redrawing if the frequency of requested redraws is higher than one animation frame (typically around 16ms). This means, for example, that when using fast-firing events like `onresize` or `onscroll`, Mithril will automatically throttle the number of redraws to avoid lag.
Mithril.js may also avoid auto-redrawing if the frequency of requested redraws is higher than one animation frame (typically around 16ms). This means, for example, that when using fast-firing events like `onresize` or `onscroll`, Mithril.js will automatically throttle the number of redraws to avoid lag.