Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

update fastboot #1

Merged
merged 146 commits into from
Feb 20, 2020
Merged

update fastboot #1

merged 146 commits into from
Feb 20, 2020

Conversation

devotox
Copy link
Owner

@devotox devotox commented Feb 20, 2020

No description provided.

kratiahuja and others added 30 commits September 16, 2017 18:46
Extend FastBoot.config to read other provided config as well.
The SimpleDOM document that gets created during fastboot rendering has a body tag, and it's possible to set attributes on it. For example, assuming `getDOM` from [ember-wormhole](https://github.com/yapplabs/ember-wormhole/blob/6992bb2a9fced9183cdb426a931722fb1fefba8a/addon/utils/dom.js#L45-L63):

```js
Component.extend({
  init() {
    this._super(..arguments);
    getDOM(this).body.setAttribute('data-foo', 'hello')
  }
})
```

But this doesn't actually cause any output in fastboot, because the user's own `<body>` tag from index.html is always used instead.

This PR allows attributes set on the simpledom body to be copied into the output.

Given that the user's `index.html` is treated as a string and handled with string substitution, I'm forced to do a Regexp-based replaced that is less elegant than we would be able to do if we parsed the `index.html` file. But that seems like a pretty big change that would need more thought. So I think the string substitute is good enough here.

add test
…trolling

If a user mistakenly uses `Ember.get(headers, headerName)` it will work now, but will
warn the user to use `header.get(headerName)` instead.
…which does not support destructuring and let
…2.17.0

Update ember-source to the latest version 🚀
Add markers before and after the body to be able to remove rootless apps
…t requests.

This shows that mutating the prototype of an object used in multiple
requests, leaks that mutation.
Refactor to use a single sandboxed context per visit request.
See RELEASE.md for details.
Add automated release setup.
We were using it primarily to test that our
`FastBootHeaders.prototype.unknownProperty` method functioned
properly. This refactors things to use a simulated `Ember.get` to allow
the same test scenario to succeeed, but avoid having to depend on Ember
itself.

Note: this does not remove any "real" testing of various Ember versions,
most of our tests are using fixtures with a fully compiled ember-cli
applications.
Remove ember-source from devDependencies.
This changes the system from providing default set of shared (and
therefore mutable) global properties to using a builder function to
generate the set of globals to be used _per visit_.

The `buildSandboxGlobals` function will receive the default set of
globals that FastBoot creates (currently this is `najax` and
`FastBoot`), and whatever the `buildSandboxGlobals` function returns is
what will ultimately be used. If `buildSandboxGlobals` is not provided,
a default implementation is used (it is essentially `defaultGlobals =>
defaultGlobals;`).

For example, to specify a custom global property named `AwesomeThing` to
be accessed within the sandboxed context:

```js
let fastboot = new FastBoot({
  distPath: 'some/path/here',
  buildSandboxGlobals(globals) {
    return Object.assign({}, globals, {
      AwesomeThing: 'Taco Cat'
    });
  }
});
```

If `sandboxGlobals` is passed (and `buildSandboxGlobals` is not) issue a
deprecation and automatically create a `buildSandboxGlobals` of the
following:

```js
globals => Object.assign({}, globals, options.sandboxGlobals);
```
Refactor sandboxGlobals -> buildSandboxGlobals
* Recent versions of ember-data (3.12+) will automatically use
  `ember-fetch` (or global `fetch`) if present, and does not need
  special logic around `najax`
* New applications (as of ember-cli@3.13.0) include `ember-fetch` by
  default, and do **not** include jQuery by default. Considering that
  `najax` is a `jQuery.ajax` emulation API, I think this library should
  avoid exposing it.
* `najax` (as a dependency of this library) is difficult for the host
  application to control (e.g. get their own version), and would be
  better if they provided it themselves (via `buildSandboxGlobals` API)
* Providing backwards compatibility is **very** easy (add `najax:
  require('najax')` via `buildSandboxGlobals`)
* It seems better to "follow a spec" (suggesting `fetch` usage)

For applications that still need `najax` (for example, if they are using
an older ember-data version), they can do (example uses new
`buildSandboxGlobals` API):

```js
const najax = require('najax');

let fastboot = new FastBoot({
  distPath: 'some/path/to/dist',
  buildSandboxGlobals(globals) {
    return Object.assign({}, globals, {
      najax,
    });
  }
});
```
Remove najax from default set of sandbox globals.
An earlier refactor (to avoid floating the passed in `promise`)
introduced invalid syntax (`Promise.all(firstThing, secondThing)`), this
fixes the issue and adds tests ensuring we don't regress.
Fix invalid syntax with deferRendering.
This PR does a few things:

Firstly, it allows the end consumer to decide
if they want a sandbox per visit or to share a single sandbox over all
visits.

Second, it changes the default of `buildSandboxPerVisit` back to
`false` therefore sharing a single sandbox for many `visit` invocations.
Expose option to allow a new sandbox per visit
Update various dependencies to latest versions.
@devotox devotox merged commit caa89a4 into devotox:master Feb 20, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.