5561462568
Summary: Now all plugins get passed a `cloudState` object to their `activate` method. The `cloudState` object is an instance of `CloudState` and acts like a key-value store backed by the yet-to-be-implemented Metadata service. It has a `get`, `getAll`, and `observe` method. The `observe` method returns a new `Rx.Observable` for the given key. It has a `set`, and `unset` method that doesn't actually mutate state, but rather dispatches new `Task`s to Create, Update, and Delete `Metadata` objects. The whole object is backed by `Metadata` objects. Since these are standard Database Objects that will appear on the delta sync streaming API, any updates from the server will automatically propagate down to listening views via the `Rx.Observable`s. Additionally, there is a new `N1-Send-Later` stub plugin that demonstrates how to use the `cloudState`. There are few other minor refactors included in this diff: **Generic CUD Tasks**: There is now a generic `CreateModelTask`, `UpdateModelTask`, and `DestroyModelTask`. These can either be used as-is or trivially overridden to easily update simple objects. Hopefully all of the boilerplate rollback, error handling, and undo logic won't have to be re-duplicated on every task. There are also tests for these tasks. We use them to perform mutating actions on `Metadata` objects. **New `boundProps` for `InjectedComponents`**: When making the `N1-Send_later` plugin, I realized that the injected component needed to get the `cloudState` somehow. Traditionally components would require Stores and load data that way, but these are setup at `require`-time. Now that `cloudState` only is available on `activate` we needed a way to get the data to the components. There's now the concept of `boundProps` which will be props added to the Component when it gets injected. This required changing the return signature of `findComponentMatching`, which got renamed to `findComponentDataMatching`. **Failing on Promise Rejects**: Turns out that if a Promise rejected due to an error or `Promise.reject` we were ignoring it and letting tests pass. Now, tests will Fail if any unhandled promise rejects. This uncovered a variety of errors throughout the test suite that had to be fixed. The most significant one was during the `theme-manager` tests when all packages (and their stores with async DB requests) was loaded. Long after the `theme-manager` specs finished, those DB requests were (somtimes) silently failing. **Globally stub `DatabaseStore._query`**: All tests shouldn't actually make queries on the database. Furthremore, the `inTransaction` block doesn't resolve at all unless `_query` is stubbed. Instead of manually remembering to do this in every test that touches the DB, it's now mocked in `spec_helper`. This broke a handful of tests that needed to be manually fixed. **ESLint Fixes**: Some minor fixes to the linter config to prevent yelling about minor ES6 things and ensuring we have the correct parser. Test Plan: new tests Reviewers: drew, bengotow, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D2419 |
||
|---|---|---|
| .. | ||
| assets | ||
| lib | ||
| spec | ||
| stylesheets | ||
| icon.png | ||
| package.json | ||
| README.md | ||
| screenshot.png | ||
Composer Templates
Create templates you can use to pre-fill the N1 composer - never type the same email again! Templates live in the ~/.nylas/templates directory on your computer. Each template is an HTML file - the name of the file is the name of the template, and it's contents are the default message body.
If you include HTML <code> tags in your template, you can create
regions that you can jump between and fill easily.
Give <code> tags the var class to mark them as template regions. Add
the empty class to make them dark yellow. When you send your message, <code>
tags are always stripped so the recipient never sees any highlighting.
This example is a good starting point for plugins that want to extend the composer experience.
Install this plugin
-
Download and run N1
-
From the menu, select
Developer > Install a Plugin Manually...The dialog will default to this examples directory. Just choose the package to install it!When you install packages, they're moved to
~/.nylas/packages, and N1 runsapm installon the command line to fetch dependencies listed in the package'spackage.json