Reusable Blocks: Add reusable blocks UI #3378

noisysocks · 2017-11-08T00:00:52Z

Adds the UI necessary for reusable blocks. This includes:

PHP code that renders a reusable block in a published post or page
The component rendered in the visual editor
The sidebar UI used to attach and detach reusable blocks
The inserter UI used to insert reusable blocks to the post

Some of this was already reviewed in #2659.

lamosty · 2017-11-08T15:05:58Z

editor/effects.js

+		const { name, type, attributes } = getReusableBlock( getState(), id );
+		const content = serialize( createBlock( type, attributes ) );
+
+		new wp.api.models.ReusableBlocks( { id, name, content } ).save().then(


What is the name property? The WP REST API doesn't support a name attribute. Shouldn't it be title of the custom post type?

name is the name of the reusable block: https://github.com/WordPress/gutenberg/blob/master/lib/class-wp-rest-reusable-blocks-controller.php#L302-L307

I agree that naming that title is a better thing to call that, though. I'll put it on my list!

Ah, I see, thanks.

Your call. :)

karmatosed · 2017-11-08T21:14:12Z

I wanted to test this to give some feedback, however I saw this:

Is this a known issue or something I need to do to get it working?

lamosty · 2017-11-09T09:10:42Z

@karmatosed:

I wanted to test this to give some feedback, however I saw this:

After you checkout the branch, try deleting node_modules, then npm install and npm run build again. I had the same issue.

karmatosed · 2017-11-10T20:47:05Z

I'm cc'ing in @jasmussen as I think we need to iterate on the design here. Currently we have this:

This I am suggesting could be iterated by having some more friendly and informative language.

Here are some suggestions:

Overall, I think we need to think about the flow of this feature and how it could be discovered. I think where we have this is too hidden:

Could we add this perhaps in the menu? Note, I've not added the icon and maybe we also need a tooltip to explain what this is.

jasmussen · 2017-11-14T08:12:05Z

I think using the ellipsis menu for making reusable blocks has potential. I'm slightly concerned about putting more stuff in there as we're already looking at a few options there, with a bunch of transformations to come also. But it does feel like a good place for it.

karmatosed · 2017-11-14T22:32:44Z

@jasmussen I have that concern myself. The current implementation feels like hiding a good feature though. Maybe we need to try it? Do we have a best guess at how many things we are going to have if everything we want gets in today? I'm thinking of a visual stress test.

jasmussen · 2017-11-15T08:00:05Z

I think this may be one of those features whose full potential won't be realized until slightly later on, perhaps post phase-1, where we have more templating features and so on. Given this, perhaps we shouldn't hyper-optimize for the current UI, but instead leave room for us to learn about the feature and then find a better place. To put it differently, there seems to be agreement that it's a slick feature that deserves a better place, but perhaps it's a problem that's best solved in the future?

codecov · 2017-11-23T05:47:08Z

Codecov Report

Merging #3378 into master will decrease coverage by 0.23%.
The diff coverage is 14.81%.

@@            Coverage Diff             @@
##           master    #3378      +/-   ##
==========================================
- Coverage    37.7%   37.46%   -0.24%     
==========================================
  Files         279      281       +2     
  Lines        6737     6780      +43     
  Branches     1226     1230       +4     
==========================================
  Hits         2540     2540              
- Misses       3536     3575      +39     
- Partials      661      665       +4

Impacted Files	Coverage Δ
editor/components/block-settings-menu/index.js	`0% <ø> (ø)`	⬆️
editor/components/inserter/group.js	`55% <ø> (ø)`	⬆️
components/spinner/index.js	`0% <0%> (-50%)`	⬇️
editor/components/inserter/index.js	`0% <0%> (ø)`	⬆️
editor/components/block-list/block.js	`2.22% <0%> (-0.02%)`	⬇️
blocks/library/reusable-block/edit-panel/index.js	`0% <0%> (ø)`
...nents/block-settings-menu/reusable-block-toggle.js	`25% <25%> (ø)`
blocks/library/reusable-block/index.js	`8.82% <3.12%> (-57.85%)`	⬇️
editor/components/inserter/menu.js	`84.26% <62.5%> (-1.28%)`	⬇️
components/panel/row.js	`0% <0%> (-100%)`	⬇️
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 499b320...5f59ef1. Read the comment docs.

noisysocks · 2017-11-23T07:10:22Z

I rebased this PR and fixed some bugs that were introduced in the last rebase! 🙂

Since block-inspector/advanced-controls.js was removed in #3472, I had to re-implement how the 'Convert to Reusable Block' control is added to the sidebar. It now uses a hook (hooks/reusable-blocks.js) which is very similar to how hooks/custom-class-name.js works. This does the job, but it feels a little hacky to me since it involves connect()ing the InspectorControls.

The E2E tests are failing. A git bisect tells me that something in 295e025 is causing them to break, but I can't for the life of me figure out what it is. My best guess is that Cypress doesn't like it when we use Slot.Fill? 😕

karmatosed · 2017-11-23T16:33:58Z

@jasmussen I still think it needs to move from where it is currently, I am ok if that for now is the ellipsis.

noisysocks · 2017-11-27T00:37:57Z

Thanks for the 👀 @karmatosed! I'll move the controls into the ⋯ menu 🙂

noisysocks · 2017-11-27T00:41:04Z

A git bisect tells me that something in 295e025 is causing them to break, but I can't for the life of me figure out what it is. My best guess is that Cypress doesn't like it when we use Slot.Fill? 😕

For posterity: turns out this was because <Editable> was being mounted twice as a result of the BlockEdit filter returning a deeply nested array rather than a flat array. 9472e0e was the fix. Thanks @youknowriad for the big hint in figuring this one out!

noisysocks · 2017-11-27T02:15:32Z

I moved the button into the block settings menu. @jasmussen—are you able to whip up an icon for this?

jasmussen · 2017-11-27T07:53:02Z

Nice work.

While the icon definitely could use some love, I think for now let's go with this dashicon https://developer.wordpress.org/resource/dashicons/#controls-repeat

Reusable blocks is an important interface that I expect we'll hone and polish many times in the future, but for now let's get the ball rolling!

noisysocks · 2017-11-27T23:51:24Z

Icon changed!

youknowriad · 2017-11-28T09:22:58Z

blocks/inspector-controls/button-control/index.js

@@ -0,0 +1,23 @@
+/**


This component is not used anymore, right?

You're right! I've removed it.

youknowriad · 2017-11-28T09:28:23Z

editor/components/inserter/group.js

@@ -48,7 +48,7 @@ export default class InserterGroup extends Component {
 				role="menuitem"
 				key={ block.name }
 				className="editor-inserter__block"
-				onClick={ selectBlock( block.name ) }
+				onClick={ selectBlock( block.name, block.attributes ) }


Maybe we should just pass the block object as an argument here instead of two arguments.

👌 fixed in 8ced4510795d9e428a2f6d1c2bbb4e2f744da23b.

youknowriad · 2017-11-28T09:33:31Z

editor/components/inserter/menu.js

 		return () => {
-			this.props.onSelect( name );
+			this.props.onSelect( name, attributes );


Thinking more about this "attributes" argument. Regular blocks already have an attributes property but instead of containing attributes values, it contains attributes definition. I assume this will be called with the attributes definitions for these regular blocks which is not what's expected I guess.

It may not produce bugs at the moment but I think we should fix this ambiguity somehow.

👌 fixed in 8ced4510795d9e428a2f6d1c2bbb4e2f744da23b.

mtias · 2017-11-30T15:35:02Z

Looking good. A couple things.

I can search for "reusable block" and insert a broken block:

My saved block doesn't show up if I search for its name.

Let's add another tab to the inserter called "Saved" instead of putting saved blocks as a category of "blocks":

mtias · 2017-11-30T15:39:05Z

Another point is that the block inspector for the reusable block should let me delete the block from the records (with a warning that it'll stop working if it was used somewhere):

mtias · 2017-11-30T16:12:52Z

Also for later: creation of global blocks should be handled with proper capabilities (an author would not get access to create reusable blocks, but an editor would, etc). And let this be filterable if someone wants to allow anyone to create reusable blocks.

mtias · 2017-11-30T16:14:13Z

blocks/library/reusable-block/index.php

+}
+
+register_block_type( 'core/reusable-block', array(
+	'attributes'      => array(


Some odd spaces here.

The linter requires that the arrow on line 37 aligns with the arrow on line 43.

mtias · 2017-11-30T16:18:07Z

blocks/library/reusable-block/index.php

+	return gutenberg_render_block( $block );
+}
+
+register_block_type( 'core/reusable-block', array(


All the other terms we can more easily change, like internal variables, actions, and functions. But this we'll have to support once we announce.

I am not super comfortable with the name. A couple ideas:

core/global-block

core/saved-block -> to match the inserter tab.

or maybe this is an exception and is saved like global-block without the core suffix. Not to keen on an exception here, but it might warrant it (also of note, we have core-embed as a namespace.

For reference, the CPT is now called wp-block.

cc @aduth @youknowriad @mcsf @pento for naming thoughts

I'm not a native speaker, so if reusable-block is clearest I'm fine with sticking with it, just want to make sure we are ok with it.

Thinking a bit more, it seems the most clear and consistent with the wp-block post type is to call this core/block which maps to wp:block and wp:core/block. Thoughts?

My only hesitation with global block is that global is a fairly technical term and that using it in the UI might limit how approachable this feature is to a wider audience.

For technical usages though, I'm happy with using a more precise term. core/block matching up with wp-block is very appealing.

Note that if we change this then we ought to change the /gutenberg/v1/reusable-blocks endpoint too, which would be a (fairly insignificant) breaking change.

Saved block might speak to users more. Further, though I'm not a huge fan, there are precedents out there to justify custom blocks. Note that I can see reusable blocks working, if visual context and copy correctly introduce the concept.

Playing devil's advocate, saved and custom blocks may sound confusing ("Aren't I already making my own block when I add a "Paragraph" and type something in? Isn't it custom? Isn't it being saved?"). Those terms stress a different aspect from reusable, with reusable arguably stressing the user-facing value. (Mind you, a similar case can be made against reusable: "This Paragraph, or this Author block, aren't they reusable?")

I'm going to go ahead and rename the block identifier to core/block so that we can move ahead with this PR. This makes sense to me since, just as  inserts an image,  inserts a wp_block.

Let's move the discussion about the name of the overall feature to a seperate issue. For what it's worth, I asked my wife (a regular WordPress user) what she thought and she said that custom block makes the most sense 🙂

mtias · 2017-11-30T16:21:33Z

editor/components/block-settings-menu/reusable-block-toggle.js

+			icon="controls-repeat"
+			onClick={ isReusableBlock ? convertToStatic : convertToReusable }
+		>
+			{ isReusableBlock ? __( 'Detach from Reusable Block' ) : __( 'Make into a Reusable Block' ) }


Would "Convert to Reusable Block" or "Convert to Global Block" be more concise?

Changed in 619d81f51afbd3bf0fd5a407e2a82a993b7a7051.

mtias · 2017-11-30T16:23:49Z

lib/blocks.php

+/**
+ * Renders a single block into a HTML string.
+ *
+ * @since 1.3.0


This needs to be updated.

Fixed in b8f96e9b5e7c905d37ba7e392083de1a249cc8a1.

mtias · 2017-11-30T16:24:14Z

lib/client-assets.php

@@ -790,7 +790,7 @@ function gutenberg_editor_scripts_and_styles( $hook ) {
 	$script  = '( function() {';
 	$script .= sprintf( 'var editorSettings = %s;', wp_json_encode( $editor_settings ) );
 	$script .= <<<JS
-		window._wpLoadGutenbergEditor = Promise.all( [ wp.api.init(), wp.api.init( { versionString: 'gutenberg/v1' } ) ] ).then( function() {
+		window._wpLoadGutenbergEditor = Promise.all( [ wp.api.init(), wp.api.init( { versionString: 'gutenberg/v1/' } ) ] ).then( function() {


curious, what's the reason for this change?

None of the Backbone methods work without the trailing slash, but we didn't catch that while testing #3377 since the unit tests mock the API call and no UI existed for any of this.

Do you think this is still useful with #3778

Yes, since we're not using withAPIData.

noisysocks · 2017-12-03T23:24:11Z

blocks/library/reusable-block/index.js

+		const generatedClassName = hasBlockSupport( blockType, 'className', true ) ?
+			getBlockDefaultClassname( reusableBlock.type ) :
+			null;
+		const className = classnames( generatedClassName, reusableBlockAttributes.className );


Clever! Thanks so much @youknowriad 🙏

aduth

Most comments aren't critical. This works great and is very cool to use and see 👍

aduth · 2017-12-05T13:39:14Z

blocks/library/block/edit-panel/index.js

+					key="save"
+					isPrimary
+					isLarge
+					isIndicatingProgress={ isSaving }


This prop does not exist on the Button component, and since Button passes through unrecognized props to the underlying DOM node, it results in a warning while editing:

Warning: React does not recognize the isIndicatingProgress prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase isindicatingprogress instead. If you accidentally passed it from a parent component, remove it from the DOM element.

Should this be the isBusy prop added in #3682?

Good catch. It definitely should be isBusy. Fixed in a820d1cc43dddd97d44e6e756707dfc6ab56c80b.

aduth · 2017-12-05T13:43:47Z

blocks/library/block/edit-panel/index.js

+					{ __( 'Detach' ) }
+				</Button>,
+			] }
+			{ ( isEditing || isSaving ) && [


Should the editing variation be visible while the name is being saved? In my testing, it flips back to the static text immediately upon hitting Save.

Good catch—that's a bug that must have slipped in during a merge. Fixed in a820d1cc43dddd97d44e6e756707dfc6ab56c80b.

aduth · 2017-12-05T13:47:04Z

blocks/library/block/index.js

+	}
+}
+
+const ConnectedReusableBlockEdit = connect(


I don't have any ideas at the moment and it may have already been mentioned, but we need to work to find a solution where the block can access state without the implicit dependency on editor, either:

Blocks module having its own separate state

Merging more of [the non-post-editor-specific-] editor and blocks

Obvious too by the fact that we have equivalent action creators for what we're dispatching here, but unable (unwilling) to import them directly from editor.

Agreed, and I also have no ideas on how to address this right now.

Merging more of [the non-post-editor-specific-] editor and blocks

Could you elaborate on this? I'm not quite caught up on my history here. Did we abandon the effort to merge the two modules (#2795)?

Just an idea: Does it make more sense for this block to be defined in the editor module instead?

I also even wonder if the blocks module should hold only the blocks API and define all the blocks in the editor module

Just an idea: Does it make more sense for this block to be defined in the editor module instead?

I think there's a lot of merit to that idea.

I also even wonder if the blocks module should hold only the blocks API and define all the blocks in the editor module

That one I'm not too convinced of right now. I mean, I could picture using editor/library, but the current situation of having the library sit next to the API makes sense to me, as the core blocks are the canonical blocks: in that sense, they highly complement the API (both code and docs) by providing numerous well tested use cases.

aduth · 2017-12-05T13:54:47Z

blocks/library/block/index.js

+	category: 'reusable-blocks',
+	isPrivate: true,
+
+	attributes: {


I don't think you should need to define this on the client, since it should be bootstrapped from the server definition.

See #2529

I'm hesitant to do this because removing the client-side definition means our test fixtures aren't able to test parsing a .

aduth · 2017-12-05T13:55:25Z

components/spinner/index.js


-export default () => spinner;
+function Spinner( { className } ) {


You're not / no longer taking advantage of these enhancements? Should we omit them respecting our good friend YAGNI?

👍 I've removed these changes.

aduth · 2017-12-05T13:58:19Z

editor/components/block-list/block.js

@@ -350,11 +350,13 @@ class BlockListBlock extends Component {
 		const { isHovered, isSelected, isMultiSelected, isFirstMultiSelected, focus } = this.props;
 		const showUI = isSelected && ( ! this.props.isTyping || ( focus && focus.collapsed === false ) );
 		const { error } = this.state;
+		const isReusableBlock = blockType.name === 'core/block';


Elsewhere we've limited our awareness to specific block types via abstraction, e.g. getDefaultBlockName, getUnknownTypeHandlerName. Should we need to consider that here? Maybe not the case we'd ever expect it to change.

Couldn't hurt! I moved this logic out to isReusableBlock in 95a28a37adea3afeb44fb2b9c068c9e1fc61fb31.

aduth · 2017-12-05T13:59:55Z

editor/components/block-settings-menu/reusable-block-toggle.js

+import { convertBlockToStatic, convertBlockToReusable } from '../../actions';
+
+export function ReusableBlockToggle( { block, convertToStatic, convertToReusable } ) {
+	const isReusableBlock = block.name === 'core/block';


Thinking purely from the presentational / container distinction, I might expect this variable to be passed as the prop, determined in a selector or mapStateToProps, particularly since we're not otherwise using the block prop.

👍 I've moved it in 95a28a37adea3afeb44fb2b9c068c9e1fc61fb31.

aduth · 2017-12-05T14:01:53Z

editor/components/inserter/menu.js

@@ -71,6 +71,10 @@ export class InserterMenu extends Component {
 		this.switchTab = this.switchTab.bind( this );
 	}

+	componentDidMount() {
+		this.props.fetchReusableBlocks();


Noting that this can become quite noisy for AJAX requests: Every time the user opens an inserter.

Personally I'm okay with this, since it ensures that the data is kept fresh, but worth keeping in mind.

For now I think this is OK. If it's a problem then we can limit it to fetch once when the inserter is opened for the first time.

mtias · 2017-12-07T13:28:30Z

@noisysocks Before we go ahead with exposing this at wide. Can you remind me why we are not using the ID provided by WP for the post object in wp_block like public 'ID' => int 2359 instead of the generated ref? It makes a lot more sense for me to see it as  which is an internally consistent concept of WordPress.

Adds the UI which displays when a reusable block is asked for its `edit` component. This includes a panel which includes UI that indicates whether a reusable block is loading and lets a user change the name of the block.

Adds the necessary PHP code for rendering a reusable block as HTML on the blog's front-end.

Changes BlockListBlock to display selected reusable blocks with a dashed outline.

Add a block settings menu control which allows users to convert a regular block to a reusable block and convert a reusable block to a regular block.

Fix reusable blocks not loading by looking at the correct path in the state tree (state.reusableBlocks.data) and by adding a trailing slash to the /gutenberg/v1/ API versionString.

Patches the Inserter to display all reusable blocks in a seperate group, and to insert a reusable block when one is clicked.

Distinguish between initialAttributes which are passed into createBlock and attributes which define which attributes a block type supports.

Make the Inserter search both static blocks and reusable blocks.

Moves reusbale blocks from the Blocks tab to a new Saved tab in the Inserter.

This way, just as  inserts an image,  inserts a wp_block.

Ensure that the Save button indicates that the block is being saved.

Move block.name === 'core/block' logic to a new isReusableBlock function.

…id instead

mcsf

Per Slack, this looks great. The recent change to server-issued IDs is quite welcome.

mtias · 2017-12-08T17:34:14Z

Great work here everyone and specially @noisysocks. This is a great feature.

noisysocks · 2017-12-11T02:36:59Z

Also for later: creation of global blocks should be handled with proper capabilities (an author would not get access to create reusable blocks, but an editor would, etc). And let this be filterable if someone wants to allow anyone to create reusable blocks.

@mtias — could you please elaborate on this so that I can create an issue? Right now, any user with the edit_posts capability (authors, contributors and editors) can view and edit Reusable Blocks. Are you suggesting that we limit editing and creating Reusable Blocks to just editors?

mtias · 2017-12-11T12:17:21Z

Are you suggesting that we limit editing and creating Reusable Blocks to just editors? Right now, any user with the edit_posts capability (authors, contributors and editors) can view and edit Reusable Blocks.

We need to let authors insert them, but probably not edit them by default. Not sure if we should let authors create them, or only editors. Furthermore, this is something that should probably be filterable and part of general capabilities so people can map. Example: edit_blocks, insert_blocks, delete_blocks. Something more broad to think about. cc @pento

ghost · 2017-12-11T21:45:57Z

@mtias ... something more broad.

There indeed needs to be a complete capabilities- and author-concept for reusable blocks.

A current users with a role below "editor" should only be able to see/create/edit/delete his/her own reusable blocks.

Users with/above "editor" role should be able to see/create/edit/delete any reusable block and also edit its author.

The concept should also provide a way to configure the visibility of reusable blocks for each user and/or post_type, not sure if via capability or filter.

Example for no visibility limit requirement: Simple one-user blog.

Example for visibility limit requirement: Multi author website with 15-20 authors and everybody creates a few reusable blocks which would then be visible for everybody, the gui would be a mess in no time...

lamosty reviewed Nov 8, 2017

View reviewed changes

mtias added [Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks Needs Design Feedback Needs general design feedback. labels Nov 8, 2017

noisysocks changed the title ~~Add reusable blocks UI~~ Reusable Blocks: Add reusable blocks UI Nov 22, 2017

youknowriad reviewed Nov 28, 2017

View reviewed changes

mtias reviewed Nov 30, 2017

View reviewed changes

aduth mentioned this pull request Dec 2, 2017

State: Deduplicate notices by distinct ID #3764

Merged

noisysocks commented Dec 3, 2017

View reviewed changes

aduth reviewed Dec 5, 2017

View reviewed changes

noisysocks and others added 16 commits December 8, 2017 12:08

Add UI for editing a reusable block

142c15a

Adds the UI which displays when a reusable block is asked for its `edit` component. This includes a panel which includes UI that indicates whether a reusable block is loading and lets a user change the name of the block.

Allow a reusable block to be rendered as HTML

2ec264c

Adds the necessary PHP code for rendering a reusable block as HTML on the blog's front-end.

Present reusable blocks with a dashed outline

94df1aa

Changes BlockListBlock to display selected reusable blocks with a dashed outline.

Add UI for converting blocks to/from a reusable block

918042b

Add a block settings menu control which allows users to convert a regular block to a reusable block and convert a reusable block to a regular block.

Fix reusable blocks not loading

0246ecc

Fix reusable blocks not loading by looking at the correct path in the state tree (state.reusableBlocks.data) and by adding a trailing slash to the /gutenberg/v1/ API versionString.

Add UI for inserting a reusable block

01908a0

Patches the Inserter to display all reusable blocks in a seperate group, and to insert a reusable block when one is clicked.

Resolve ambiguity around onSelect( attributes )

e5c33e5

Distinguish between initialAttributes which are passed into createBlock and attributes which define which attributes a block type supports.

Change copy of 'Convert to Reusable Block'

c774d55

Mark gutenberg_render_block as being available @SInCE 1.9.0

0c9473c

Fix inability to search for reusable blocks

f504864

Make the Inserter search both static blocks and reusable blocks.

Display reusable blocks in a seperate Inserter tab

b6d7b36

Moves reusbale blocks from the Blocks tab to a new Saved tab in the Inserter.

Reusable Blocks: Fix reusable blocks classname

0f47630

Rename core/reusable-block to core/block

490da26

This way, just as  inserts an image,  inserts a wp_block.

Fix Reusable Block saving state

7b57c44

Ensure that the Save button indicates that the block is being saved.

DRY up block.name === 'core/block' logic

55b9e1c

Move block.name === 'core/block' logic to a new isReusableBlock function.

Reusable Blocks: Avoiding using a generated uid and rely on the post_…

cdefd75

…id instead

mcsf approved these changes Dec 8, 2017

View reviewed changes

youknowriad merged commit e437939 into WordPress:master Dec 8, 2017

noisysocks deleted the add/reusable-blocks-ui branch December 11, 2017 02:36

aduth mentioned this pull request Dec 11, 2017

Turning a static block into a dynamic reusable block #1516

Closed

ghost mentioned this pull request Dec 12, 2017

Reusable blocks security #3936

Closed

noisysocks mentioned this pull request Dec 13, 2017

Move Reusable Block definition from blocks module to editor module #3967

Closed

aduth added the [Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) label Dec 19, 2017

noisysocks mentioned this pull request Jul 12, 2018

Rename shared blocks to global blocks and increase understanding of the feature #7887

Closed


		export default () => spinner;
		function Spinner( { className } ) {

Reusable Blocks: Add reusable blocks UI #3378

Reusable Blocks: Add reusable blocks UI #3378

Conversation

noisysocks commented Nov 8, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karmatosed commented Nov 8, 2017

lamosty commented Nov 9, 2017

karmatosed commented Nov 10, 2017 • edited

jasmussen commented Nov 14, 2017

karmatosed commented Nov 14, 2017

jasmussen commented Nov 15, 2017

codecov bot commented Nov 23, 2017 • edited

Codecov Report

noisysocks commented Nov 23, 2017 • edited

karmatosed commented Nov 23, 2017

noisysocks commented Nov 27, 2017

noisysocks commented Nov 27, 2017

noisysocks commented Nov 27, 2017

jasmussen commented Nov 27, 2017

noisysocks commented Nov 27, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mtias commented Nov 30, 2017

mtias commented Nov 30, 2017 • edited

mtias commented Nov 30, 2017

Choose a reason for hiding this comment

noisysocks Nov 30, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noisysocks Nov 30, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noisysocks Dec 5, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noisysocks Nov 30, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noisysocks Dec 4, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mtias commented Dec 7, 2017

mcsf left a comment

Choose a reason for hiding this comment

mtias commented Dec 8, 2017

noisysocks commented Dec 11, 2017

mtias commented Dec 11, 2017

ghost commented Dec 11, 2017

noisysocks commented Nov 8, 2017 •

edited

karmatosed commented Nov 10, 2017 •

edited

codecov bot commented Nov 23, 2017 •

edited

noisysocks commented Nov 23, 2017 •

edited

mtias commented Nov 30, 2017 •

edited

noisysocks Nov 30, 2017 •

edited

noisysocks Nov 30, 2017 •

edited

noisysocks Dec 5, 2017 •

edited

noisysocks Nov 30, 2017 •

edited

noisysocks Dec 4, 2017 •

edited