Mailspring/internal_packages/composer-templates
Ben Gotow 7452705c31 refactor(composer): Make session, draft available everywhere
Summary:
Up until now, we've been requiring that every plugin control in the composer take the draftClientId, retreive the session, listen to it, build state from the draft, etc. This is a huge pain and is hard to explain to newcomers becaus it frankly makes no sense.

In 0.3.45 we made it so that the ComposerView always has a non-null draft and session. (It isn't rendered until they're available). In this diff, I just pass those through to all the plugins and remove all the session retrieval cruft.

Almost none of the buttons have state of their own, which I think is appropriate.

They do render on every keystroke, but they were already running code (to recompute their state) on each keystroke and profiling suggests this has no impact.

Prepare for immutable

In preparation for Immutable models, make the draft store proxy returns a !== draft if any changes have been made. This means you can safely know that a draft has changed if `props.draft !== nextProps.draft`

Test Plan: Run tests

Reviewers: juan, evan

Reviewed By: juan, evan

Differential Revision: https://phab.nylas.com/D2902
2016-04-19 16:05:15 -07:00
..
assets feat(composer): new composer footer and icon design 2016-02-23 13:42:10 -08:00
lib refactor(composer): Make session, draft available everywhere 2016-04-19 16:05:15 -07:00
spec fix(imports): switch to Electron's require('electron') (#1907) 2016-04-12 18:09:13 -07:00
stylesheets 🎨(preferences): Adjust textbox styles for signatures and templates 2016-04-07 14:12:35 -07:00
icon.png 💄(icon): A delightful seafoam green icon 2016-02-23 10:35:08 -08:00
package.json rename(templates): Use "Quick Replies" name in plugins screen 2016-01-07 15:23:54 -08:00
README.md fix(examples): examples => packages, move away from installing them 2016-01-07 14:56:34 -08:00
screenshot.png fix(examples): examples => packages, move away from installing them 2016-01-07 14:56:34 -08:00

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

  1. Download and run N1

  2. 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 runs apm install on the command line to fetch dependencies listed in the package's package.json