- 27 Mar, 2017 6 commits
-
-
Sean Roberts authored
-
Robert Knight authored
Adding analytics to share functions
-
Sean Roberts authored
-
Sean Hammond authored
Split viewer.html template into one template per app type
-
Robert Knight authored
Branded sidebar
-
Sean Hammond authored
Convert `<excerpt>` to a component
-
- 24 Mar, 2017 17 commits
-
-
Sean Roberts authored
-
Sean Roberts authored
-
Robert Knight authored
Reorganize annotation sync tests
-
Sean Hammond authored
Rename all the tests to better reflect what they actually test. Mostly replacing broadcast local event bus publisher proxying with "calls function", plus a couple of other clarifications. Before: AnnotationSync channel event handlers the "deleteAnnotation" event ✓ broadcasts the "annotationDeleted" event over the local event bus ✓ calls back with a formatted annotation ✓ removes an existing entry from the cache before the event is triggered ✓ removes the annotation from the cache the "loadAnnotations" event ✓ publishes the "annotationsLoaded" event event handlers the "beforeAnnotationCreated" event ✓ proxies the event over the bridge ✓ returns early if the annotation has a tag After: AnnotationSync #constructor when "deleteAnnotation" is published ✓ calls emit("annotationDeleted") ✓ calls the 'deleteAnnotation' event's callback function ✓ deletes any existing annotation from its cache before calling emit ✓ deletes any existing annotation from its cache when "loadAnnotations" is published ✓ calls emit("annotationsLoaded") when "beforeAnnotationCreated" is emitted ✓ calls bridge.call() passing the event if the annotation has a $tag ✓ does not call bridge.call()
-
Sean Hammond authored
If the tests are grouped according to what class / method / function they're testing, then it's a lot easier to see what is being tested and what isn't, and it's easier to find the tests for `foo()` or to know where to put new tests for `foo()`. On the other hand when you names tests like `describe('channel event handlers',` `describe('event handlers',` `describe('the "loadAnnotations" event',`, `describe('the "deleteAnnotation" event',` etc then it can be a lot harder for a reader coming along later to understand how the tests are organized and how this organization relates to the code itself. Most of the examples on https://mochajs.org/ use this style of organizing tests: describe('Array', function() { describe('#indexOf()', function() { it(... ... }); describe('#concat()', function () { it(... ... }); describe('#slice()', function () { it(... ... }); describe('User', function() { describe('#save()', function() { it(... describe('Connection', function() { describe('#find()', function() { it(... This commit reorganizes the AnnotationSync tests along the same lines. I've also made use of Mocha's `context()` function to group tests **within a `describe()` for a method** by context. `context()` is just an alias for `describe()`, but it has different semantics. (This is also in line with how `context()` is used in the mochajs.org examples).
-
Robert Knight authored
In the stream and single annotation page it is not possible to select or focus an annotation since there is no associated page content, so these callback inputs can be left unset.
-
Robert Knight authored
The `annotation` component does not declare `isSidebar` or `isLastReply` in its bindings so these properties are unused.
-
Robert Knight authored
This is no longer needed since the entire UI is rendered client-side.
-
Robert Knight authored
In preparation for converting the controllers which provide the logic for the content area of the sidebar (below the top bar) into components, split up the viewer.html template into one template for each application type (sidebar, stream, single annotation page). This allows removing a number of conditionals from the components in each template.
-
Sean Hammond authored
Translate AnnotationSync tests to JavaScript
-
Sean Hammond authored
Tidy the CoffeeScript-generated annotation-sync-test.js into something more human readable.
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
Just export the `<excerpt>` component definition instead of both the definition (which includes the controller) and the controller itself.
-
Robert Knight authored
This module previously lived under `src/sidebar/directive` but it isn't a directive, only a helper class used by a directive.
-
Robert Knight authored
-
Robert Knight authored
-
- 23 Mar, 2017 10 commits
-
-
Sean Roberts authored
-
Sean Roberts authored
-
Sean Roberts authored
-
Sean Roberts authored
-
Sean Hammond authored
Convert `<group-list>` to a component
-
Sean Hammond authored
Just the minimal changes necessary to stop `make lint` from complaining, while still having `make test` pass. Some code can be deleted because (eslint informs us) it was unused.
-
Sean Hammond authored
`annotation-sync-test.js` is the unmodified output of `coffee -bc src/annotator/test/annotation-sync-test.coffee`.
-
Sean Roberts authored
Add a branding directive to bring custom branding to sidebar
-
Sean Roberts authored
-
Sheetal Umesh Kumar authored
Fix annotation ID not being passed to moderation banner correctly.
-
- 22 Mar, 2017 1 commit
-
-
Robert Knight authored
Add missing `vm.` prefix and test. This was missed when testing the PR because the banner was enabled by modifying the banner's controller instead of the app state.
-
- 21 Mar, 2017 1 commit
-
-
Robert Knight authored
* Implement <moderation-banner> component Implement the UI component for the moderation banner at the top of annotation cards, following the designs on [1]. [1] https://github.com/hypothesis/product-backlog/issues/183 * Add reducer and actions for managing moderation app state Add a module which defines the state and actions related to moderation status of annotations. * Display moderation banner at the top of annotation cards The moderation banner is currently only supported on top-level annotations. It will need to be adjusted and moved to a different component in order to support replies. * Support displaying moderation banner above replies. * Move the `<moderation-banner>` component to `<annotation-thread>` so that it can be displayed for replies as well as annotations. * Customize the styling of the banner when the annotation is a reply. * Add a simple test for display change when moderation banner is used on a reply * Add additional parameter documentation * Convert `<moderation-banner>` to a component As per hypothesis/client#292, all element directives are being converted to components. * Add tooltips to moderation banner buttons. The "Hide" and "Undo" labels for the button were potentially ambiguous. The final labels are still being discussed but improve the UI by adding tooltips and changing "Undo" to "Unhide". * Correct a reference to a button label in tests The label changed from "Undo" to "Unhide".
-
- 20 Mar, 2017 2 commits
-
-
-
Robert Knight authored
Just export the component definition rather than an object containing both the controller and the component definition as a property.
-
- 18 Mar, 2017 3 commits
-
-
Robert Knight authored
-
Robert Knight authored
-
Robert Knight authored
-