forked from ember-fastboot/fastboot
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Extend FastBoot.config to read other provided config as well.
Update rsvp to the latest version 🚀
Update mocha to the latest version 🚀
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
Allow body attributes
…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.
Save users from trolling
…which does not support destructuring and let
add API for response chunks
…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
Drop Node 8 support.
Update various dependencies to latest versions.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.