The 1.6-beta.7 release had a version conflict because of the webapp@1.3.17
constraint in server-render/package.js. I noticed the problem before
publishing the release, so we will just skip to 1.6-beta.8.
When the babel-compiler package is updated, it appears that sometimes the
ecmascript package must also be updated, since it registers the compiler
plugin that uses babel-compiler.
After verifying that you're using both babel-compiler@6.19.4 and
ecmascript@0.8.2, you should probably run `meteor reset` just to be sure
you aren't still using any cached source maps.
IE11 doesn't handle properly attempts to change methods of the
window.localStorage, attempts to do so will result in the complete break of the
localStorage system for the domain in which it is done - until the user clean
the browser/domain cache.
Therefore, in the web, we don't set Meteor._localStorage to be a reference to
window.localStorage . Instead, we set proxy methods.
This will allow package developers that will find a need to change the behavior
of Meteor._localStorage methods to do so without breaking the localStorage
system on IE11. (e.g. meteorhacks:fast-render)
IE11 (earlier IE versions weren't checked) doesn't handle attempts to replace
methods of window.localStorage with different functions properly. Such attempt
will result in the String of the function we try to set saved as the function,
destroying the ability to use this function.
I couldn't find a way to tell in advance whether an attempt to set
window.localStorage will result in correct function write or not (I
intentionally avoid browser version detection, which is considered a bad
practice). If such attempt will fail we won't have a way to restore the
original function.
The situation is even worse than that. If for exapmle we'll try to set
window.localStorage.setItem = function () {} the String value 'function () {}'
will be saved instead of the function - not only for the current session, but
as part of the localStorage (!) meaning that we'll have to ask users affected
by this bug to clear the cache to fix the situation.
The following won't work:
```javascript
Meteor._localStorage = window.localStorage // Just to make example clear.
originalSetItem = Meteor._localStorage.setItem
Meteor._localStorage.setItem = function () {}
Meteor._localStorage.setItem = originalSetItem
typeof Meteor._localStorage.setItem -> string
```
* boilerplate refactor wip
* rename files
* make switching between old/new easier
* refactor and modernize boilerplate-generator
* add cordova template code
* delete old boilerplate-generator
* small style fixes
* address comments
* address review comments again
* remove boilerplate generated-by comment
* delete spacebars templates
* add boilerplate-generator-tests
* bump boilerplate-generator version
* dummy commit
* Revert "dummy commit"
This reverts commit 54fe867690.
* update tests
* refactor parameter destructuring
* fix style
* modernize boilerplate generator a bit
* refactor boilerplate-generator
* fix web browser template
* refactor boilerplate-generator-tests
* rename files using hyphens
* Remove spaces after object-shorthand method names.
Per the comment in
https://github.com/meteor/meteor/pull/8820#discussion_r123635284
Previously, only the `constructor` method was addressed and this expands
on that.
* Add some space for legibility between conditionals.
Render callbacks can now inject HTML content into multiple different
elements, and may also append content to the <head> or <body> elements, on
both the client and the server.
This new API was inspired by trying to use the styled-components npm
package on the server, which involves not only rendering and injecting
static HTML somewhere in the <body>, but also appending the resulting
<style> tag(s) into the <head>:
import { onPageLoad } from "meteor/server-render";
import { renderToString } from "react-dom/server";
import { ServerStyleSheet } from "styled-components";
onPageLoad(sink => {
const sheet = new ServerStyleSheet();
const html = renderToString(sheet.collectStyles(
<App location={sink.request.url} />
));
sink.renderIntoElementById("app", html);
sink.appendToHead(sheet.getStyleTags());
});
Note that the server-render package now exports an onPageLoad function,
rather than the old renderIntoElementById function. The functionality of
renderIntoElementById is now exposed by the {Client,Server}Sink API.
I say the client-side version of this API is 'isomorphish' to the
server-side version, because ClientSink methods can accept DOM nodes in
addition to raw HTML strings, whereas DOM nodes don't really make sense on
the server.
Meteor 1.5.1 will pin version 1.4.x of the accounts-password package, so
Meteor 1.6 only needs to use a different (greater) minor version.
Related: 0ad123db5b
Based on this warning:
npm ERR! As of npm@5, the npm cache self-heals from corruption issues and
npm ERR! data extracted from the cache is guaranteed to be valid. If you
npm ERR! want to make sure everything is consistent, use 'npm cache
npm ERR! verify' instead.
npm ERR!
npm ERR! If you're sure you want to delete the entire cache, rerun this
npm ERR! command with --force.
