VNDB fork of mithril.js
58f1c74394
Fixes #2360 Fixes #1138 Fixes #1788 a little less hackishly Probably fixes a few other issues I'm not aware of. This more or less goes with @lhorie's comment here, just with a minor name change from `query` to `params`: https://github.com/MithrilJS/mithril.js/issues/1138#issuecomment-231363395 Specifically, here's what this patch entails: - I changed `data` and `useBody` to `params` and `body` in `m.request`. Migration is trivial: just use `params` or `body` depending on which you intend to send. Most servers do actually care where the data goes, so you can generally pretty easily translate this accordingly. If you *really* need the old behavior, pass the old value in `params` and if `method === "GET"` or `method === "TRACE"`, also in `body`. - I opened up all methods to have request bodies. - I fixed `m.parseQueryString` to prefer later values over earlier values and to ensure that objects and arrays are persisted across both hash and query param parsing. That method also accepts an existing key/value map to append to, to simplify deduplication. - I normalized path interpolation to be identical between routes and requests. - I no longer include interpolated values in query strings. If you need to duplicate values again, rename the interpolation to be a distinct property and pass the value you want to duplicate as it. - I converted `m.route` to use pre-compiled routes instead of its existing system of dynamic runtime checking. This shouldn't have a major effect on performance short-term, but it'll ease the migration to built-in userland components and make it a little easier to reconcile. It'll also come handy for large numbers of routes. - I added support for matching routes like `"/:file.:ext"` or `"/:lang-:region"`, giving each defined semantics. - I added support for matching against routes with static query strings, such as `"/edit?type=image": { ... }`. - I'm throwing a few new informative errors. - And I've updated the docs accordingly. I also made a few drive-by edits: - I fixed a bug in the `Stream.HALT` warning where it warned all but the first usage when the intent was to warn only on first use. - Some of the tests were erroneously using `Stream.HALT` when they should've been using `Stream.SKIP`. I've fixed the tests to only test that `Stream.HALT === Stream.SKIP` and that it only warns on first use. - The `m.request` and `m.jsonp` docs signatures were improved to more clearly explain how `m.request(url, options?)` and `m.jsonp(url, options?)` translate to `m.request(options)` and `m.jsonp(options)` respectively. ----- There is some justification to these changes: - In general, it matters surprisingly more than you would expect how things translate to HTTP requests. So the comment there suggesting a thing that papers over the difference has led to plenty of confusion in both Gitter and in GitHub issues. - A lot of servers expect a GET with a body and no parameters, and leaving `m.request` open to working with that makes it much more flexible. - Sometimes, servers expect a POST with query parameters *instead* of a JSON object. I've seen this quite a bit, even with more popular REST APIs like Stack Overflow's. - I've encountered a few servers that expect both parameters and a body, each with distinct semantic meaning, so the separation makes it much easier to translate into a request. - Most of the time, path segments are treated individually, and URL-escaping the contents is much less error-prone. It also avoids being potentially lossy, and when the variable in question isn't trusted, escaping the path segment enables you to pass it through the URL and not risk being redirected to unexpected locations, avoiding some risks of vulnerabilities and client side crashes. If you really don't care how the template and parameters translate to an eventual URL, just pass the same object for the `params` and `body` and use `:param...` for each segment. Either way, the more explicit nature should help a lot in making the intent clearer, whether you care or not. |
||
|---|---|---|
| .github | ||
| api | ||
| bundler | ||
| docs | ||
| examples | ||
| module | ||
| ospec | ||
| pathname | ||
| performance | ||
| promise | ||
| querystring | ||
| render | ||
| request | ||
| router | ||
| stream | ||
| test-utils | ||
| tests | ||
| .deploy.enc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .npmignore | ||
| .travis.yml | ||
| browser.js | ||
| hyperscript.js | ||
| index.js | ||
| LICENSE | ||
| mithril.js | ||
| mithril.min.js | ||
| mount.js | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| redraw.js | ||
| render.js | ||
| request.js | ||
| route.js | ||
| stream.js | ||
mithril.js 
What is Mithril?
A modern client-side Javascript framework for building Single Page Applications. It's small (8.88 KB gzipped), fast and provides routing and XHR utilities out of the box.
Mithril is used by companies like Vimeo and Nike, and open source platforms like Lichess 👍.
Mithril supports IE11, Firefox ESR, and the last two versions of Firefox, Edge, Safari, and Chrome. No polyfills required. 👌
Installation
CDN
<script src="https://unpkg.com/mithril@next/mithril.js"></script>
<!-- or -->
<script src="https://cdn.jsdelivr.net/npm/mithril@next/mithril.js"></script>
npm
# For the most recent stable version
$ npm install mithril --save
# For the most recent unstable version
$ npm install mithril@next --save
The "Getting started" guide is a good place to start learning how to use mithril.
Documentation
Documentation lives on mithril.js.org.
You may be interested in the API Docs, a Simple Application, or perhaps some Examples.
Getting Help
Mithril has an active & welcoming community on Gitter, or feel free to ask questions on Stack Overflow using the mithril.js tag.
Contributing
There's a Contributing FAQ on the mithril site that hopefully helps, but if not definitely hop into the Gitter Room and ask away!
Thanks for reading!
🎁