* Minify stream, add stream stuff to releases again
* Kill off a lot of tech debt, drop internal utilities from npm
1. Kill `module/`, internalize `bundler/`, privatize `test-utils/`
We've been telling people to move elsewhere from these for a while, and
it's about time we just pull the plug here and finally remove them.
- We officially removed the bundler from the public API in v2.0, and
that was the only one of these that was ever publicly documented.
Usage should be low enough by now it shouldn't break anyone- I'm not
seeing bundler bugs being reported anymore, either.
- The `module/` utility was so narrow and caveat-filled that I'm not
sure anyone really used it (even us core Mithril devs never really
used it), and we only had it documented in the repo folder it lived
in. I think only one bug was ever filed, and it's because it somehow
ended up completely non-functional without any of us realizing it.
- The test utilities were meant to be internal from day 1, but people
started using it despite us core developers constantly telling people
to look elsewhere and even the docs recommending specific alternatives
without mention of our internal mocks. (Now if people would RTFM,
that'd be nice...)
2. Add dedicated HTML test files to verify ospec and the promise
polyfill, and ensure the promise tests are in pure ES5.
These are made specially for those and should be much easier to just run
now.
3. Fix the benchmark script to use the real DOM in browsers and to not
require as many dependencies to create. Also, tweak them to be much
more effective and precise on what's being tested.
Previously, it was rendering to the HTML file itself, while now it's
rendering to the `body`. This means in browsers, it's triggering layout
and everything, benchmarking how well Mithril optimizes for style and
layout recalcs, too. It also puts some pressure on the hyperscript
parser attribute application, so that can be noticed as well.
* Update dependencies
Also, I normalized them to all be sentences for consistency, and I moved
the reentrancy check from `m.mount` to `m.render` to be a little more
helpful. The router change during mounting is inconsequential and only
to avoid the new modified error, and the change to the update loop is to
send the original error if an error occurred while initializing the
default route. (This is all around more useful anyways.)
And while I was at it, I fixed an obscure bug with sync redraws.
* Fix assertion descriptions
Move return statement to the end of define()
* ospec: Fix assertion definitions
* Fix typo in assertion
* Add test for descriptions being returned on fail
* Reference result instead of self in returned description method
* Fix style errors
* Actually return the check from `maybeSetContentEditable`
Lots of code paths relied on it being a boolean. When I created the
abstraction, I apparently forgot to make sure it returned the result.
* Don't forget to copy instance state over
* Update changelog [skip ci]
* Fix changelog issue [skip ci]
- Lot of people couldn't migrate to v1 and plan to reevaluate when v2 is
released.
- It's "npm" not "NPM". It doesn't stand for anything, and it never
has - it was initially chosen simply because it was easy to type.
It has a lot of unofficial backronyms with "Node Package Manager"
being one of the most common ones, but it's never officially stood
for anything as an acronym *or* initialism.
- Fixed a few errors in the change log, like non-breaking changes being
included in the "Breaking Changes" section and an inaccuracy in the
summary of a particular change.
- Fixed RawGit URLs to point to GitHack, which is a lighter proxy that
offloads caching to Cloudflare instead of also implementing it itself.
(It also just uses nginx for all the important server logic, so it
scales better.)
- Add a few more v0.2 references as appropriate
* Recast the router API to be a lot more intuitive.
Fixes#2387Fixes#2072
Fixes quite a few issues reported on Gitter.
For `m.route.Link`:
- More intuitive
- More accessible
- More ergonomic
- It can be disabled
- It can be cancelled
- It can be changed
- Oh, and you can use it isomorphically.
For `m.route.prefix`
- You can *read* it.
- You can write to it, of course.
- It's literally just setting a property.
For the router itself (and the rest of Mithril):
- You can now `require("mithril")` and all its submodules without a DOM
at all. There is a catch: you can't instantiate any routes, you can't
mount anything, and you can't invoke `m.render` in any capacity. You
can only use `m.route.Link`, `m.route.prefix`, hyperscript stuff, and
`mithril/stream`, and you can use `m.request` with `background: true`
if you use a global XHR polyfill. (You can't use `m.request` without
`background: true` except with a DOM to redraw with.) The goal here is
to try to get out of the way for simple testing and to defer the
inevitable `TypeError`s for the relevant DOM methods to runtime.
The factory requires no arguments, and in terms of globals, you can
just figure out based on what errors are thrown what globals to
define. Their values don't matter - they just need to be set to
*something*, even if it's just `null` or `undefined`, before Mithril
executes.
Had to make quite a few other changes throughout the docs and tests to
update them accordingly. Oh, and that massive router overhaul enabled me
to do all this.
Also, slip in a few drive-by fixes to the mocks so they're a little
easier to work with and can accept more URLs. This was required for a
few of the tests.
* Update changelog + numbers, add forgotten bundle option
* Add PR numbers to changelog [skip ci]
* Allow continuing to the next match by returning `false`.
* Update numbers again
* Drop `m.version`
It's caused way too much grief over the years, and I've finally decided
it's worth pitching. For those who need it, it's easy to get, especially
if you use it through Node or a build system. And for those who are just
loading it globally, you have to explicitly specify the version anyways,
so you'd be just as golden if you followed it up with a simple inline
script that does `m.version = "the version you loaded"`.
Oh, and also, you shouldn't be coding specifically for version numbers,
either - it's a known anti-pattern. Instead, you should prefer feature
detection and just do the right thing.
* Update changelog [skip ci]
* De-servicify router (mostly)
Still uses the redraw service, but it no longer has an intermediate
service of its own.
Also, did a *lot* of test deduplication in this. About 30-40% of the
router service tests were already tested on the main router API instance
itself.
Bundle size decreased from 9560 to 9548 bytes min+gzip.
* Merge `m.mount` + `m.redraw`, update router
Simplifies the router and redraw mechanism, and makes it much easier to
keep predictable.
Bundle size down to 9433 bytes min+gzip, docs updated accordingly.
* Make `mithril/render` just return the `m.render` function directly.
* Deservicify `m.render`, revise `m.route`
- You now have to use `mithril/render/render` directly if you want an
implicit redraw function. (This will likely be going away in v3.)
- Revise `m.route` to only `key` components
* Add `redraw` to `m.render`, deservicify requests
* Test error logging
* Update docs + changelog [skip ci]
- Remove appropriate route change subcriptions when a root is removed
via `m.mount(root, null)`.
- Don't pollute `onpopstate` and friends - use standard event listeners
instead.
- Simplify and streamline subscriptions, in preparation of adding a
`remove` parameter to `m.mount`.
- Change the redraw internals to redraw immediately, with ability to
cancel via returning a sentinel.
- Change `"bleeding-edge"` for `m.version` in `next` to instead just be
the latest `m.version`. (If you're using `next`, you should know what
you're in for.)
- Update tests to be aware of these changes. (Some were failing for
subtle reasons.)
- Drive-by: remove some uses of `string.charAt(n)` and use `string[n]`
instead.
* Fix#2434
* Treat holes as unkeyed, normalize boolean/null/undefined
This brings a lot better consistency with that API, even though it's
slightly breaking. (I had to update a bunch of tests to correspond with
it.)
* Fill in PR number [skip ci]
* Clarify pathname docs, follow spec with fragments
- Valid URLs must not contain a `#` within its fragment.
https://github.com/MithrilJS/mithril.js/issues/2445
- Our docs were a little confusing and misleading - `m.pathname` isn't
aware of URLs, just path names.
- Removed the relevant extension to `m.parseQueryString` required to
support the hash parsing extension. Now we just shave it off and
ignore it.
- Fix support for arbitrary prefixes, so prefixes like `?#` are
handled correctly.
- Add a bunch of tests to cover various areas of confusion and unusual
edge cases.
* Update with PR [skip ci]
* s/xhr/request/g
`m.xhr` was a relic of the rewrite days prior to the release of v1.0.0,
before it was renamed `m.request` to align with v0.2.x. This just strips
some of that legacy naming.
* Make this work with `async`/`await` correctly.
It looked like a V8 bug, but read the two big code comments and follow
their links. It's a bit more subtle than it looks, and V8's in the right
here.
* Update docs/request.md
* Bring some sanity to request parsing and error handling
- The browser can do JSON parsing itself. Let's defer to that where
possible. (A few IE hacks are required here, though.)
- Don't propagate any error that occurs before `deserialize`/`extract`.
- Allow sending raw array buffers/blobs/etc. to `deserialize`.
- Align behavior more closely with the XHR spec.
- Send the more useful parsed response to `deserialize`, not the less
useful string response.
Fixes#2360Fixes#1138Fixes#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.
Also, correct the change logs to be much more consistent between each
other and ensure the ospec and stream change logs are linked to from
Mithril's primary change log.
* Implement support for variadic arguments to `m.fragment`
While I was at it, I refactored the common logic out of `hyperscript`.
* Add a missed change from #2326
* Update docs + changelog [skip ci]
* Explain rationale for `hyperscriptVnode`'s calling convention
This way, it doesn't get erroneously "cleaned up" into something worse,
and so it's clearer how it'd be potentially optimized once ES5 support
is dropped.
* Remove `m.prop` + `m.withAttr`
- For many uses, `m.withAttr` is *more* verbose than just directly using
an event handler
- If you're using it with a bound callback, you're literally wasting a
single character in the human readable version (and you're *saving*
them in the minified output).
- It sometimes obscures your intent, if overused.
- Functions are easier to compress than `m.withAttr`, resulting in
slightly smaller bundles.
- `m.withAttr` is overused anyways.
- `m.prop` is basically useless without `m.withAttr`, and the API
doesn't have the same benefits it had with 0.2.x.
* Update changelog
I basically recast it to remove 99% of the duplication. They're
basically the same function mod how they fire their requests and append
query parameters.
* Fix docs bug, advise against reusing `vnode.attrs` itself [skip ci]
* Be consistent + correct with commas [skip ci]
* Be consistent with spacing [skip ci]
* Discard the unused parameters [skip ci]
* Kill an opinion, slim down the example [skip ci]
- I also fixed a bunch of related comments
- I had to polyfill `requestAnimationFrame` for Node
- Drive-by: run `eslint . --fix`
- Drive-by: update transpiling info in CONTRIBUTING.md
- Drive-by: we aren't the only ones going semicolon-free
