wq.app 1.1.2 brings a significant overhaul to the internal source structure, while (mostly) retaining full backwards compatibility. Specifically, wq.app is now organized as a monorepo containing several npm packages (see #1, #84, #66, and #109). The new packages are written as ES6 modules, but compiled back into AMD modules for compatibility with the existing wq.app PyPI package.
This release achieves the first goal in the 2019 roadmap for wq.app.
While wq.app 1.1.2 is intended to be fully backwards compatible with 1.1.1, there is one important exception: the use of
fetch() to handle AJAX requests. If you need to support older browsers without a built-in
fetch() (such as IE 11), you will need to include a polyfill before loading wq.app:
<script src="https://cdnjs.cloudflare.com/ajax/libs/fetch/3.0.0/fetch.min.js"></script> <script src="/js/lib/require.js" data-main="/js/myapp"></script>
In addition, if you are using a custom
ajax() plugin hook (added in 1.1.1), note that the arguments have changed slightly:
- For POST requests, the url is a
URLobject, and data is a
- For GET requests, the url a string, and data is an object containing URL parameters.
- If the request fails with a server error, the plugin should throw an
jsonattribute if the error is an object or a
textattribute otherwise. (See the default implementation for an example). Unlike
fetch()does not automatically throw in the case of 400 and 500 errors.
wq/autocomplete.js, wq/console.js, wq/json.js, and wq/progress.js are deprecated and have been removed from the source repository. For backwards compatibility, the Python package includes copies of these modules from 1.1.1.
- Ensure base URL is used when falling back to server rendering (#112 via @tubaman)
- Various outbox improvements (7f548bcb967dba1372f95632147947ed079c739b)