VNDB fork of mithril.js
The previous definition of MithrilRoutes was generic over <T extends
MithrilController>, with the MithrilRoutes containing a collection of
MithrilComponent<T>.
However, this presents problems with TypeScript's type inference in many common
situations. For example, consider this usage of m.route():
```
m.route(document.body, "/a", {
"/a": ComponentA,
"/b": ComponentB,
})
```
Both `ComponentA` and `ComponentB` implement `MithrilComponent<T extends
MithrilController>`, with each component having a different concrete controller
type (`ControllerA` and `ControllerB`).
However, unless ControllerA's type is a subset of ControllerB's type (or
vice-versa), TypeScript will be unable to infer the type of the MitrilRoutes<T>
returned by m.route(). To get this to compile, a third type which *is* a
subset of both ControllerA and ControllerB would need to be explicity provided:
```
// Both ControllerA and ControllerB implement MithrilController
m.route<MithrilController>(document.body, "/a", {
"/a": ComponentA,
"/b": ComponentB,
})
```
This commit makes MithrilRoute non-generic, and instead of containing
MithrilComponent<T extends MithrilRoute>, it contains
MithrilComponent<MithrilController>, which will match all valid
MithrilComponents.
The motivation for this change is twofold:
1. In the case where m.route() does not compile due to type-inference failure,
the resulting syntax error from Typescript is very unhelpful because m.route()
has a number of overloads. Leaving this as is will result in confusion for
downstream users.
2. An assumption that vanishingly little utility is provided by defining
`MithrilRoutes<T extends MithrilController>` over a type more specific than
MithrilController. At most, it could be used to assert that all of your routed
Components meet a more specialized interface, but that same type check could be
accomplished without having to augment MithrilRoutes with that information.
|
||
|---|---|---|
| deploy | ||
| docs | ||
| tests | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .npmignore | ||
| .travis.yml | ||
| dragdrop.html | ||
| Gruntfile.js | ||
| guide.html | ||
| LICENSE | ||
| mithril.closure-compiler-externs.js | ||
| mithril.d.ts | ||
| mithril.js | ||
| mithril.min.js | ||
| mithril.min.js.map | ||
| modulator-test.html | ||
| mvc.html | ||
| onerror.html | ||
| package.json | ||
| README.md | ||
Mithril
A Javascript Framework for Building Brilliant Applications
See the website for documentation
There's also a blog and a mailing list
What is Mithril?
Mithril is a client-side MVC framework - a tool to organize code in a way that is easy to think about and to maintain.
Light-weight
- Only 7kb gzipped, no dependencies
- Small API, small learning curve
Robust
- Safe-by-default templates
- Hierarchical MVC via components
Fast
- Virtual DOM diffing and compilable templates
- Intelligent auto-redrawing system
Sample code
//namespace
var app = {};
//model
app.PageList = function() {
return m.request({method: "GET", url: "pages.json"});
};
//controller
app.controller = function() {
var pages = app.PageList();
return {
pages: pages,
rotate: function() {
pages().push(pages().shift());
}
}
};
//view
app.view = function(ctrl) {
return [
ctrl.pages().map(function(page) {
return m("a", {href: page.url}, page.title);
}),
m("button", {onclick: ctrl.rotate}, "Rotate links")
];
};
//initialize
m.mount(document.getElementById("example"), app);
