Confirmed users
396
edits
Labs/Jetpack/JEP/13: Difference between revisions
m
grammar fix: quiet > quite
m (grammar fix: quiet > quite) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 15: | Line 15: | ||
This JEP describes a method for enabling experimentation with experimental Jetpack features, or features that aren't stable/frozen. | This JEP describes a method for enabling experimentation with experimental Jetpack features, or features that aren't stable/frozen. | ||
There is a tension in Jetpack development between (a) moving quickly and being agile, and (b) creating solid APIs that are future proof. We need to have and be both. As a way to compromise, this JEP proposes adding an import mechanism that allows access to not- | There is a tension in Jetpack development between (a) moving quickly and being agile, and (b) creating solid APIs that are future proof. We need to have and be both. As a way to compromise, this JEP proposes adding an import mechanism that allows access to not-quite-yet-ready Jetpack features. | ||
One of the requirements for this import mechanism is that as few code changes are required for any particular Jetpack as a feature is moved from experimental to permanently in the core. | One of the requirements for this import mechanism is that as few code changes are required for any particular Jetpack as a feature is moved from experimental to permanently in the core. | ||
| Line 39: | Line 39: | ||
Where <code>stringMountPath</code> is a string that enumerates where, starting from the <code>jetpack</code> base, the feature will be mounted. To get a list of what mount paths are available, see the "Reading the Future" section below. Some examples of using <code>future.import</code> are as folows: | Where <code>stringMountPath</code> is a string that enumerates where, starting from the <code>jetpack</code> base, the feature will be mounted. To get a list of what mount paths are available, see the "Reading the Future" section below. Some examples of using <code>future.import</code> are as folows: | ||
<pre class="brush:js;> | <pre class="brush:js;toolbar:false;"> | ||
// jetpack.storage.sqlite is currently undefined. | // jetpack.storage.sqlite is currently undefined. | ||
jetpack.future.import("storage.sqlite"); | jetpack.future.import("storage.sqlite"); | ||
| Line 51: | Line 51: | ||
The nice thing about such syntax is that once storage.sqlite is formally | The nice thing about such syntax is that once storage.sqlite is formally | ||
accepted into the core, the author can just remove the | accepted into the core, the author can just remove the | ||
jetpack. | jetpack.future.import() call and their code will "just work" (barring any | ||
other changes that were made when the functionality was integrated into the | other changes that were made when the functionality was integrated into the | ||
core, of course). | core, of course). | ||
| Line 61: | Line 61: | ||
<pre class="brush:js;toolbar:false;">var list = jetpack.future.list()</pre> | <pre class="brush:js;toolbar:false;">var list = jetpack.future.list()</pre> | ||
It returns an array containing the set of potential <code> | It returns an array containing the set of potential <code>stringMountPath</code> as used in <code>jetpack.future.import()</code>. | ||