mirror of
https://github.com/Foundry376/Mailspring.git
synced 2024-11-14 13:44:41 +08:00
1e8fd46342
Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
130 lines
6.1 KiB
Markdown
130 lines
6.1 KiB
Markdown
# Contributing to Atom
|
|
|
|
:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
|
|
|
|
The following is a set of guidelines for contributing to Atom and its packages,
|
|
which are hosted in the [Atom Organization](https://github.com/atom) on GitHub.
|
|
If you're unsure which package is causing your problem or if you're having an
|
|
issue with Atom core, please open an issue on the [main atom repository](https://github.com/atom/atom/issues).
|
|
These are just guidelines, not rules, use your best judgement and feel free to
|
|
propose changes to this document in a pull request.
|
|
|
|
## Submitting Issues
|
|
|
|
* Check the [debugging guide](https://atom.io/docs/latest/debugging) for tips
|
|
on debugging. You might be able to find the cause of the problem and fix
|
|
things yourself.
|
|
* Include the version of Atom you are using and the OS.
|
|
* Include screenshots and animated GIFs whenever possible; they are immensely
|
|
helpful.
|
|
* Include the behavior you expected and other places you've seen that behavior
|
|
such as Emacs, vi, Xcode, etc.
|
|
* Check the dev tools (`alt-cmd-i`) for errors to include. If the dev tools
|
|
are open _before_ the error is triggered, a full stack trace for the error
|
|
will be logged. If you can reproduce the error, use this approach to get the
|
|
full stack trace and include it in the issue.
|
|
* On Mac, check Console.app for stack traces to include if reporting a crash.
|
|
* Perform a cursory search to see if a similar issue has already been submitted.
|
|
* Please setup a [profile picture](https://help.github.com/articles/how-do-i-set-up-my-profile-picture)
|
|
to make yourself recognizable and so we can all get to know each other better.
|
|
|
|
### Package Repositories
|
|
|
|
This is the repository for the core Atom editor only. Atom comes bundled with
|
|
many packages and themes that are stored in other repos under the
|
|
[Atom organization](https://github.com/atom) such as
|
|
[tabs](https://github.com/atom/tabs),
|
|
[find-and-replace](https://github.com/atom/find-and-replace),
|
|
[language-javascript](https://github.com/atom/language-javascript), and
|
|
[atom-light-ui](https://github.com/atom/atom-light-ui).
|
|
|
|
For more information on how to work with Atom's official packages, see
|
|
[Contributing to Atom Packages](https://atom.io/docs/latest/contributing-to-packages.html)
|
|
|
|
## Pull Requests
|
|
|
|
* Include screenshots and animated GIFs in your pull request whenever possible.
|
|
* Follow the [CoffeeScript](#coffeescript-styleguide),
|
|
[JavaScript](https://github.com/styleguide/javascript),
|
|
and [CSS](https://github.com/styleguide/css) styleguides.
|
|
* Include thoughtfully-worded, well-structured
|
|
[Jasmine](http://jasmine.github.io/) specs.
|
|
* Document new code based on the
|
|
[Documentation Styleguide](#documentation-styleguide)
|
|
* End files with a newline.
|
|
* Place requires in the following order:
|
|
* Built in Node Modules (such as `path`)
|
|
* Built in Atom and Atom Shell Modules (such as `atom`, `shell`)
|
|
* Local Modules (using relative paths)
|
|
* Place class properties in the following order:
|
|
* Class methods and properties (methods starting with a `@`)
|
|
* Instance methods and properties
|
|
* Avoid platform-dependent code:
|
|
* Use `require('atom').fs.getHomeDirectory()` to get the home directory.
|
|
* Use `path.join()` to concatenate filenames.
|
|
* Use `os.tmpdir()` rather than `/tmp` when you need to reference the
|
|
temporary directory.
|
|
* Using a plain `return` when returning explicitly at the end of a function.
|
|
* Not `return null`, `return undefined`, `null`, or `undefined`
|
|
|
|
## Git Commit Messages
|
|
|
|
* Use the present tense ("Add feature" not "Added feature")
|
|
* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
|
|
* Limit the first line to 72 characters or less
|
|
* Reference issues and pull requests liberally
|
|
* Consider starting the commit message with an applicable emoji:
|
|
* :art: `:art:` when improving the format/structure of the code
|
|
* :racehorse: `:racehorse:` when improving performance
|
|
* :non-potable_water: `:non-potable_water:` when plugging memory leaks
|
|
* :memo: `:memo:` when writing docs
|
|
* :penguin: `:penguin:` when fixing something on Linux
|
|
* :apple: `:apple:` when fixing something on Mac OS
|
|
* :checkered_flag: `:checkered_flag:` when fixing something on Windows
|
|
* :bug: `:bug:` when fixing a bug
|
|
* :fire: `:fire:` when removing code or files
|
|
* :green_heart: `:green_heart:` when fixing the CI build
|
|
* :white_check_mark: `:white_check_mark:` when adding tests
|
|
* :lock: `:lock:` when dealing with security
|
|
* :arrow_up: `:arrow_up:` when upgrading dependencies
|
|
* :arrow_down: `:arrow_down:` when downgrading dependencies
|
|
* :shirt: `:shirt:` when removing linter warnings
|
|
|
|
## CoffeeScript Styleguide
|
|
|
|
* Set parameter defaults without spaces around the equal sign
|
|
* `clear = (count=1) ->` instead of `clear = (count = 1) ->`
|
|
* Use parentheses if it improves code clarity.
|
|
* Prefer alphabetic keywords to symbolic keywords:
|
|
* `a is b` instead of `a == b`
|
|
* Avoid spaces inside the curly-braces of hash literals:
|
|
* `{a: 1, b: 2}` instead of `{ a: 1, b: 2 }`
|
|
* Include a single line of whitespace between methods.
|
|
* Capitalize initialisms and acronyms in names, except for the first word, which
|
|
should be lower-case:
|
|
* `getURI` instead of `getUri`
|
|
* `uriToOpen` instead of `URIToOpen`
|
|
|
|
## Documentation Styleguide
|
|
|
|
* Use [AtomDoc](https://github.com/atom/atomdoc).
|
|
* Use [Markdown](https://daringfireball.net/projects/markdown).
|
|
* Reference methods and classes in markdown with the custom `{}` notation:
|
|
* Reference classes with `{ClassName}`
|
|
* Reference instance methods with `{ClassName::methodName}`
|
|
* Reference class methods with `{ClassName.methodName}`
|
|
|
|
### Example
|
|
|
|
```coffee
|
|
# Public: Disable the package with the given name.
|
|
#
|
|
# * `name` The {String} name of the package to disable.
|
|
# * `options` (optional) The {Object} with disable options (default: {}):
|
|
# * `trackTime` A {Boolean}, `true` to track the amount of time taken.
|
|
# * `ignoreErrors` A {Boolean}, `true` to catch and ignore errors thrown.
|
|
# * `callback` The {Function} to call after the package has been disabled.
|
|
#
|
|
# Returns `undefined`.
|
|
disablePackage: (name, options, callback) ->
|
|
```
|