Skip to content

Instantly share code, notes, and snippets.

@smashwilson
Last active October 4, 2018 20:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save smashwilson/50a1ecfd3d8f5f3fb0dec78dfacd8fcf to your computer and use it in GitHub Desktop.
Save smashwilson/50a1ecfd3d8f5f3fb0dec78dfacd8fcf to your computer and use it in GitHub Desktop.
Rough map of the files changed within atom/github#1512

Map of the review

Package metadata

I've bumped up the minimum Atom version to 1.32 so we're sure to include the custom line-number gutter work I did in core. I'm also using underscore-plus for keystroke normalization and adding a package setting to toggle the gutter decorations.

  • package.json
  • package-lock.json

Models

Moved from their former home in lib/models to their own roomy subdirectory. The major change here from the existing model is that we no longer model hunk lines individually. Instead, the Patch owns a TextBuffer and changes are tracked with markers on that buffer.

  • lib/models/patch/file-patch.js
  • lib/models/patch/patch.js
  • lib/models/patch/file.js
  • lib/models/patch/hunk.js
  • lib/models/patch/region.js
  • lib/models/patch/builder.js

☝️ A parser that translates the objects from what-the-diff into assembled FilePatch models. Moved here from the Present repository state.

  • lib/models/patch/index.js

☝️ Re-exports the parser.

React components

  • lib/items/file-patch-item.js

☝️ Root component that implements Atom's "pane item" protocol.

  • lib/containers/file-patch-container.js

☝️ Handles the loading state while we're fetching the FilePatch from the repository.

  • lib/controllers/file-patch-controller.js

☝️ Action methods for things that you can do within the pane item.

  • lib/views/file-patch-view.js

☝️ Render most of the actual file patch UI, including the <AtomTextEditor> and all the marker layers, markers, and decorations. Wire 'em up to action methods passed in from the controller.

  • lib/views/file-patch-header-view.js

☝️ Render the banner at the very top of the pane that shows the filename and the file-wide controls.

  • lib/views/file-patch-meta-view.js

☝️ Render the box that appears if the patch changes any metadata about the file - that is, its executable bit or its status as a symlink. This is included within the FilePatchView's text editor as a block decoration.

  • lib/views/hunk-header-view.js

☝️ The control bar that's shown at the start of each hunk within the patch. These are also rendered as items within block decorations.

  • -lib/models/file-patch-selection.js

☝️ Deleted because the source of truth for selected patch rows is now the selection within the text editor itself.

Atom API bridge components

This is a family of bridge components that I've been using to manipulate resources within the Atom API in a React-y declarative way.

  • lib/atom/atom-text-editor.js

☝️ Big changes here. I've torn out the "half-managed" "sync it when the prop changes" shenanigans I'd put in there to begin with and replaced it with a wholly externally-managed TextBuffer instance that gets passed in. Managing updates to the diff editor was a nightmare otherwise.

  • lib/atom/decoration.js

☝️ Here I mostly added the ability to decorate either a MarkerLayer or a Marker, either provided explicitly or inherited through a React context.

  • lib/atom/gutter.js

☝️ Pretty similar to the other "manage a resource on an editor" components. This one adds a gutter to a text editor.

  • lib/atom/keystroke.js

☝️ Easily and flexibly show the keybinding currently bound to an Atom command. I'm using this to show the current keybinding on the "stage selections" button.

  • lib/atom/marker-layer.js
  • lib/atom/marker.js

☝️ Some changes to act as a React context providers of a "decorable" thing.

Atom package metadata

These are mostly selector updates to target the new markup structure. I was able to get rid of some of the navigation commands because they're handled by the editor now.

  • keymaps/git.cson
  • menus/git.cson

✨ @simurai design magic follows ✨

  • styles/atom-text-editor.less
  • styles/file-patch-view.less
  • styles/hunk-header-view.less

Callers

These are places that I modified to pass in new props that the FilePatchItem hierarchy is expecting.

  • lib/index.js
  • lib/github-package.js
  • lib/controllers/root-controller.js

Repository model

This is where the file patch parser in lib/models/patch/builder.js was refactored out of. I also changed getFilePatchForPath() to return a null FilePatch instance instead of null in non-present repositories, which cleaned up the container a bit.

  • lib/models/repository-states/present.js
  • lib/models/repository-states/state.js

Spiderwebbing changes section 🕸️

  • lib/git-shell-out-strategy.js

☝️ Tiny diagnostic change to dump stdin from git commands, too. Useful for tracking down broken patches.

  • lib/items/stub-item.js

☝️ I... don't remember this one. I think it had to do with getting stub items working properly with a reload? Or with the staging view?

  • lib/containers/git-tab-container.js

☝️ Probably just some ambient PropTypes fighting.

  • lib/controllers/commit-controller.js
  • lib/views/commit-view.js

☝️ These were changes to get the CommitView's text editor to also use an externally managed TextBuffer. The controller manages the TextBuffer, the view passes it to the editor.

  • lib/controllers/conflict-controller.js

☝️ Just tracking a prop rename on <Decoration> through here.

  • lib/views/staging-view.js

☝️ Some tweaking to make sure the right file is highlighted in the unstaged or staged files lists if you have a FilePatchItem activated in the workspace center. Also, generated FilePatchItem URIs consistently with the right utility methods.

  • .circleci/config.yml
  • test/runner.js

☝️ CI changes that I made to get Mocha to use the correct reporter on CircleCI; related to a stall out I was seeing on this PR.

  • lib/helpers.js
  • lib/prop-types.js

☝️ Some utility methods I needed apparently 🌠

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment