Add support for Child Blocks #6753

noisysocks · 2018-05-15T07:48:12Z

Description

Closes #5540. I split this out from #6346 which was mostly experimental — head there for extra context!

Adds parent which lets you restrict a block so that it is only available as a nested block.

registerBlockType( 'acme/buy-button', {
	title: 'Buy Button',
	icon: 'cart',
	category: 'common',

	// Only allow in products:
	parent: [ 'acme/product' ],

	...
} );

How has this been tested?

I wrote a test plugin which uses the new API. I then made sure that Buy Button blocks only appear when inserted into a Product block.

A quick way to test this is to paste the contents of block.js into your browser console.

Screenshots

Types of changes

Block registration API changes:

Introduces parent which lets one specify which block types a block can be nested into.

Selector changes:

Adds canInsertBlockType which is the source of truth for whether a block can be inserted or nested.
Removes the allowedBlockTypes argument from getInserterItems. This can be determined from state, now.
Items returned by getInserterItems will include new utility and frecency attributes. utility indicates how useful we think inserting the block will be. This lets us show contextually useful blocks at the top of the Suggested tab.
Deprecates getSupportedBlockTypes. getInserterItems will remove any blocks that are not supported. Alternatively, canInsertBlockType can be called directly.
Deprecates getFrecentInserterItems. Instead, call getInserterItems and filter/sort by frecency.

Inserter changes:

Both inserter and inserter-with-shortcuts have been changed to use getInserterItems and its new functionality.

jorgefilipecosta · 2018-05-15T17:46:10Z

editor/store/selectors.js

+	( state, blockName, parentUID ) => [
+		state.blockListSettings[ parentUID ],
+		state.editor.present.blocksByUID[ parentUID ],
+		state.settings,


I think we may be more granular when passing our cache variables and use the selectors to compute the references e.g:[ getEditorSettings( state ).allowedBlockTypes, getBlockListSettings( state, parentUID )... ] this way if the state changes as long as selectors we depend on are updated we are safe :)

Good catch. I've updated the settings dependency to be more specific in a60dc23.

I'm not sure it's a good idea to call a selector from the second argument of createSelector. If we invalidated the cache based using getBlockListSettings( state, parentUID ) and then someone went ahead and changed getBlockListSettings to use createSelector then it would mean that our cache would never invalidate.

It looks like @aduth implemented a really good solution to this problem in the form of getDependants but we are not using version 3.0.0 of rememo yet.

I'll look into updating our version of rememo in a seperate PR so that we can clean this up.

jorgefilipecosta · 2018-05-15T17:49:06Z

editor/store/selectors.js

-	if ( ! allowedBlockTypes || ! blockType ) {
-		return null;
-	}
+export const canInsertBlockType = createSelector(


Given that the name of the selector is canInsertBlockTyle I think the selector may also need to take into consideration locking. If a CPT sets a template lock we may not be able to insert a block because of that.

Fair enough! Added in c3a171a.

mtias · 2018-05-16T11:02:18Z

Great work here. I think we could refine the inserter UI further but we should wait for the results of the design explorations.

Thinking more about the API footprint, I think we should go with parent as the name, and split post type support to postType.

A few reasons for the first:

The main point of this addition is to set a relationship between blocks. The term "allowed" is too specific to the insertion mechanism, which is just one aspect of the child-parent relationship.
"Allowed" makes more sense as an instance specific prop for InnerBlocks but less so for a configuration aspect that's part of the block type definition.

For the second, even if I think there's merit in combining, there's enough distinction on post types to go the cautious route — easier to add support later within parent than to remove it.

brandonpayton · 2018-05-16T13:29:04Z

editor/components/inserter-with-shortcuts/index.js

+	 *
+	 * @see selectors.getInserterItems()
+	 */
+	return orderBy( items, [ 'utility', 'frecency' ], [ 'desc', 'desc' ] );


There are multiple components sorting inserter items by utility and frecency, and I'd like to provide the same sort in the block completer (#6067) for a consistent insertion experience. Is there a good place we could share this knowledge rather than duplicating?

How do you feel about making it so that getInserterItems sorts by default? InserterMenu would have to disable this though so that we don't double sort.

I think that would mask our intention for the inserters to use the same default sort and introduce complexity by requiring a way to disable default sort. What do you think of exporting a default sort function from editor/components/inserter and having other inserter modules explicitly import it? Then the code would say what we mean which is "Other insertion-related components use the same default sort as the primary insertion menu".

I made getInserterItems always sort the items in e9fbe66. It turns out that my claim that we'd have to make InserterMenu disable this was flat out wrong. Having the selector sort the items makes sense to me because:

It's basically always what you want to do

It's more performant to sort the items within createSelector where the results are cached

brandonpayton · 2018-05-16T13:47:22Z

editor/store/selectors.js

-				return count / 4;
-		}
-	};
+	deprecated( 'getFrecentInserterItems', {


It would be great to be able to note that one must use getInserterItems and then sort by frecency to replace getFrecentInserterItems. I may make a PR for supporting an optional hint message to deprecated.

Yeah it's a little frustrating right now that you can't use English words in alternative because of how we concatenate and then internationalise the console message.

For now I've just added your suggested hint to deprecated.md in 1efb6e5.

Thanks! If you're interested, we just added support for an optional hint message in 3fd06df.

brandonpayton · 2018-05-16T13:50:02Z

docs/reference/deprecated.md

@@ -4,6 +4,9 @@ Gutenberg's deprecation policy is intended to support backwards-compatibility fo

 - All components in `wp.blocks.*` are removed. Please use `wp.editor.*` instead.
 - `wp.blocks.withEditorSettings` is removed. Please use the data module to access the editor settings `wp.data.select( "core/editor" ).getEditorSettings()`.
+- `getInserterItems`: The `allowedBlockTypes` argument was removed and the `parentUID` argument was added.
+- `getFrecentInserterItems` selector removed. Please use `getInserterItems` instead.
+- `getSupportedBlocks` selector removed. Please use `canInsertBlockType` instead.


It's great to see this simplification and to be able to avoid the dance of calling getSupportedBlocks( parentUID ) to have something to pass to getInserterItems. 🙇

noisysocks · 2018-05-17T01:28:08Z

Thinking more about the API footprint, I think we should go with parent as the name, and split post type support to postType.

👍 renamed it to parent in b46ec6b. We'll add post type restricting in a later PR.

tofumatt · 2018-05-17T03:38:58Z

FYI I'm out until May 28 so feel free to remove me from review if it's blocking stuff.

noisysocks · 2018-05-21T01:35:47Z

How are we feeling about this? Would like to get it merged soon so that it has time to bake before 3.0.

mtias · 2018-05-21T11:56:11Z

Let's get this in shortly after doing the minor release fixes.

jorgefilipecosta · 2018-05-23T14:37:07Z

editor/store/selectors.js

+ *                                            the number of inserts that have occurred.
+ */
+function getInsertUsage( state, id ) {
+	return state.preferences.insertUsage[ id ] || { time: undefined, count: 0 };


Minor: Should we add a DEFAULT_INSERT_USAGE object equal to { time: undefined, count: 0 };? We are creating a new object each time the id is not found. If later we use this as a prop we will cause rerenders.

I'll just avoid this fanciness altogether and return null if the insert is missing 🙂 b2f8cc1

jorgefilipecosta · 2018-05-23T15:02:54Z

editor/store/selectors.js

+				return count;
+			}
+
+			const duration = Date.now() - time;


We are using Date.now() but at the same time caching the selector which means "now" is not that relevant and it does not need to be now. "Now" in this case is the last time the relevant state changed. I think instead of Date.now() we can use the biggest time from all the blocks. But I'm just noting it in case later we decide to refactor the code to make sure our selectors don't rely on any external info besides the state itself. This is not something new, so I think we can keep the current approach.

I think it's fine since "Now" in this case is the last time the relevant state changed is exactly what we want.

Using the greatest time from all of the blocks is a good idea for a pure alternative, but I don't think it's worth the performance penalty we'd get from iterating through every block.

I think it's fine since "Now" in this case is the last time the relevant state changed is exactly what we want.

This would have made for a good inline code comment to the next person who maintains this selector.

👌 added in aec5bc1

gziolo · 2018-05-23T14:04:50Z

editor/store/test/selectors.js

@@ -1463,6 +1484,8 @@ describe( 'selectors', () => {
 				},
 				innerBlocks: [],
 			} );
+
+			unregisterBlockType( 'core/meta-block' );


This should be moved to the afterAll / afterEach method.

core/meta-block is only used in one it().

gziolo · 2018-05-23T14:05:52Z

editor/store/test/selectors.js

@@ -119,7 +138,9 @@ describe( 'selectors', () => {
 	} );

 	afterAll( () => {
-		unregisterBlockType( 'core/test-block' );
+		unregisterBlockType( 'core/test-block-a' );


Should we also unregister core/block?

Oops, fixed in 4f9352e 👍

gziolo · 2018-05-23T14:19:36Z

editor/store/selectors.js

+ * @property {boolean}  isDisabled        Whether or not the user should be prevented from inserting
+ *                                        this item.
+ * @property {number}   utility           How useful we think this item is, between 0 and 3.
+ * @property {number}   frecency          Hueristic that combines recency and frecency.


Should be rather:

Hueristic that combines recency and freqency

🤦‍♂️ 99ca557

gziolo · 2018-05-23T14:27:14Z

editor/store/selectors.js

-	if ( ! supportedNestedBlocks ) {
-		return false;
-	}
+export function getSupportedBlocks( state, uid ) {


What about globallyEnabledBlockTypes param? It is still included in JSDoc but not used in the code.

getSupportedBlocks has to accept globallyEnabledBlockTypes to be backwards compatible. I removed it from the signature to avoid an unused variable linter warning. I've made this more explicit by just disabling the linter warning in d42964f 👍

gziolo · 2018-05-23T14:30:52Z

docs/reference/deprecated.md

@@ -7,6 +7,9 @@ Gutenberg's deprecation policy is intended to support backwards-compatibility fo
 - All DOM utils in `wp.utils.*` are removed. Please use `wp.dom.*` instead.
 - `isPrivate: true` has been removed from the Block API. Please use `supports.inserter: false` instead.
 - `wp.utils.isExtraSmall` function removed. Please use `wp.viewport.*` instead.
+ - `getInserterItems`: the `allowedBlockTypes` argument was removed and the `parentUID` argument was added.


It will be scheduled for deprecation with 3.2.0 release.

👍 changed in 4eb77c8

gziolo · 2018-05-23T14:48:41Z

editor/store/selectors.js

-	if ( ! referencedBlock ) {
-		return null;
-	}
+		if ( ! isBlockAllowedInParent ) {


Eslint says you can do:

return isBlockAllowedInParent;

Eslint says you can do:

return isBlockAllowedInParent;

This was never addressed.

I'd go further and say the isBlockAllowedInParent variable is unnecessary. We could just return at the point where it is assigned above. I don't even think an argument of it being an explaining variable is valid, since its meaning is implied as being the return value of the function (i.e. encapsulated already in the function naming).

👌 changed in bbe03fe

gziolo · 2018-05-23T14:50:04Z

editor/store/selectors.js

-function fillWithCommonBlocks( inserts ) {
-	// Filter out any inserts that are associated with a block type that isn't registered
-	const items = inserts.filter( ( insert ) => getBlockType( insert.name ) );
+			if ( ! canInsertBlockType( state, blockType.name, parentUID ) ) {


Apparently, Eslint doesn't like your explicit return statements with boolean values :)

Where are you seeing these? When I run npm run lint there's no warnings 😕

(Also, I like the explicitness…)

I disagree here, as it seems to imply we expect the result of canInsertBlockType to be anything other than a boolean.

If we do expect it to be a boolean, why not just return it as-is?

If we don't expect it to be a boolean, is a "can" prefix a good choice of naming?

👌 changed in fac2869

gziolo · 2018-05-23T15:03:16Z

editor/store/test/selectors.js

 				{
-					id: 'core/block/123',
+					id: 'core/test-block-b',


When looking only at this test it is unclear why Block B is listed before Block A. utility value inherited from the common category does the trick. Maybe Block B should be removed from this test and included in new test which tests only order of the items based on utility and frecency?

👍 changed in 470d32e

gziolo · 2018-05-23T15:08:17Z

editor/store/test/selectors.js

-			] );
+			const items = getInserterItems( state );
+			const testBlockBItem = items.find( ( item ) => item.id === 'core/test-block-b' );
+			expect( testBlockBItem.utility ).toBe( 1 );


Should we use constant MEDIUM instead of value 1 to better match with the description of the test?

👍 added some constants in 6efa3af

gziolo · 2018-05-23T15:11:24Z

editor/store/test/selectors.js

+			};
+			const items = getInserterItems( state );
+			const sharedBlock2Item = items.find( ( item ) => item.id === 'core/test-block-b' );
+			expect( sharedBlock2Item.utility ).toBe( 2 );


Value 2 is hard to follow in here, the description says high.

👍 added some constants in 6efa3af

gziolo · 2018-05-23T15:17:05Z

This PR needs rebase, also description is out of the date after allowedParentBlocks was renamed to parent :)

jorgefilipecosta · 2018-05-25T11:02:43Z

editor/components/inserter/index.js

 		} = select( 'core/editor' );
-		const { allowedBlockTypes, templateLock } = getEditorSettings();
+		const { templateLock } = getEditorSettings();


Minor: We can now remove the usage of template lock as getInserterItems if there is a lock getInserterItems will return no items.

Fixed in 4f6e662 👌

jorgefilipecosta · 2018-05-25T11:07:54Z

editor/components/inserter/menu.js

-			items: getInserterItems( supportedBlocks ),
-			frecentItems: getFrecentInserterItems( supportedBlocks ),
-		};
-	} ),
 	withDispatch( ( dispatch ) => ( {
 		fetchSharedBlocks: dispatch( 'core/editor' ).fetchSharedBlocks,


Minor: It is a little strange that we are dispatching a fetch action here but we are not selecting anything in this component. To make this relationship more clear maybe the items: getInserterItems( rootUid ) should continue to be done here and not passed as prop.

I'll leave this for now because we're looking into replacing this action with a resolver which would address this.

I'll leave this for now because we're looking into replacing this action with a resolver which would address this.

Where is this tracked?

jorgefilipecosta · 2018-05-25T11:11:51Z

editor/store/selectors.js

+					return count * 4;
+				case duration < ( 24 * 3600 ):
+					return count * 2;
+				case duration < ( 7 * 24 * 3600 ):


minor: Maybe we can create constants at the top e.g: SECONDS_IN_A_WEEK = 7 * SECONDS_IN_A_DAY.

Fixed in 7e215a0 👌

jorgefilipecosta

Manually testing this PR, it looks good to me, I left some non-blocker code improvements.
We will continue to iterate on this, e.g., apply restrictions on autocomplete and transforms, add locking to nesting, etc. So during the next steps, if we find a possible improvement, we can do it in the follow-up PRs.
I think we can merge now, so we have more time to test before the release.
Good work @noisysocks!

Block registration API changes: - Introduces `parent` which lets one specify which block types a block can be nested into. Selector changes: - Adds `canInsertBlockType` which is the source of truth for whether a block can be inserted or nested. - Removes the `allowedBlockTypes` argument from `getInserterItems`. This can be determined from state, now. - Items returned by `getInserterItems` will include new `utility` and `frecency` attributes. `utility` indicates how useful we think inserting the block will be. This lets us show contextually useful blocks at the top of the Suggested tab. - Deprecates `getSupportedBlockTypes`. `getInserterItems` will remove any blocks that are not supported. Alternatively, `canInsertBlockType` can be called directly. - Deprecates `getFrecentInserterItems`. Instead, call `getInserterItems` and filter/sort by `frecency`. Inserter changes: - Both `inserter` and `inserter-with-shortcuts` have been changed to use `getInserterItems` and its new functionality.

getInserterItems() will check whether or not the template is locked, so we don't need to do it twice.

Make calculateFrecency() more readable by using SECONDS_PER_* constants instead of magic numbers.

noisysocks · 2018-05-28T01:40:09Z

Thanks all! 🎉❤️

aduth · 2018-05-29T19:53:18Z

docs/block-api.md

+
+* **Type:** `Array`
+
+Blocks can be inserted into other blocks as nested content. Sometimes it is useful to restrict a block so that it is only available as a nested block. For example, you might want to allow an 'Add to Cart' block to only be available within a 'Product' block.


Blocks can be inserted into other blocks as nested content

By the current wording, there's an implication that I could insert a block into e.g. an image block, which is not true. This is to say: Not all blocks support nested content.

👌 changed in 920d7cc

aduth · 2018-05-29T20:01:58Z

editor/components/inserter/menu.js

-			items: getInserterItems( supportedBlocks ),
-			frecentItems: getFrecentInserterItems( supportedBlocks ),
-		};
-	} ),
 	withDispatch( ( dispatch ) => ( {
 		fetchSharedBlocks: dispatch( 'core/editor' ).fetchSharedBlocks,


I'll leave this for now because we're looking into replacing this action with a resolver which would address this.

Where is this tracked?

aduth · 2018-05-29T20:04:21Z

editor/store/selectors.js

+ * Each item object contains what's necessary to display a button in the
+ * inserter and handle its selection.
+ *
+ * The 'utility' property indicates how useful we think an item will be to the


Can you explain the difference between utility as defined here and priority as defined by @wordpress/hooks and the block type transforms property?

Not sure that I understand your question, sorry. Would you prefer that I rename utility → priority? I named it utility because it's a measure of how useful an inserter item is, but I'm not tied to the name.

Not sure that I understand your question, sorry. Would you prefer that I rename utility → priority? I named it utility because it's a measure of how useful an inserter item is, but I'm not tied to the name.

I'm curious more in hopes of minimizing the number of concepts which exist, where an existing pattern already exists to serve a need. As I read further, I see that these are used as specific multipliers, so while similar to priority, not quite the same.

Which is to say: Nothing should need to be changed here.

At some point we might want to consolidate those two properties: utility and frecency into one property called score. This is how some search engines work. The score could be calculated using weighted sum model to translate how things are sorted at the moment.

aduth · 2018-05-29T20:08:05Z

editor/store/selectors.js

-	if ( ! referencedBlock ) {
-		return null;
-	}
+		if ( ! isBlockAllowedInParent ) {


Eslint says you can do:

return isBlockAllowedInParent;

This was never addressed.

I'd go further and say the isBlockAllowedInParent variable is unnecessary. We could just return at the point where it is assigned above. I don't even think an argument of it being an explaining variable is valid, since its meaning is implied as being the return value of the function (i.e. encapsulated already in the function naming).

aduth · 2018-05-29T20:09:57Z

editor/store/selectors.js

+	( state, blockName, parentUID ) => [
+		state.blockListSettings[ parentUID ],
+		state.editor.present.blocksByUID[ parentUID ],
+		state.settings.allowedBlockTypes,


Aside: This pierces the abstraction of getEditorSettings in use by the selector. Not an easy problem to solve, though.

aduth · 2018-05-29T20:23:00Z

editor/store/selectors.js

+				return count;
+			}
+
+			const duration = Date.now() - time;


I think it's fine since "Now" in this case is the last time the relevant state changed is exactly what we want.

This would have made for a good inline code comment to the next person who maintains this selector.

aduth · 2018-05-29T20:25:56Z

editor/store/selectors.js

-function fillWithCommonBlocks( inserts ) {
-	// Filter out any inserts that are associated with a block type that isn't registered
-	const items = inserts.filter( ( insert ) => getBlockType( insert.name ) );
+			if ( ! canInsertBlockType( state, blockType.name, parentUID ) ) {


I disagree here, as it seems to imply we expect the result of canInsertBlockType to be anything other than a boolean.

If we do expect it to be a boolean, why not just return it as-is?

If we don't expect it to be a boolean, is a "can" prefix a good choice of naming?

aduth · 2018-05-29T20:28:15Z

editor/store/selectors.js

+
+			let isDisabled = false;
+			if ( blockType.useOnce ) {
+				isDisabled = getBlocks( state ).some( ( block ) => block.name === blockType.name );


FYI: Lodash's _.some has a nice convenience for this pattern in its object predicates:

isDisabled = some( getBlocks( state ), { name: blockType.name } );

https://lodash.com/docs/4.17.10#some

👌 changed in ed0b4f1

aduth · 2018-05-29T20:31:13Z

editor/store/selectors.js

+
+			const duration = Date.now() - time;
+			switch ( true ) {
+				case duration < SECONDS_PER_HOUR:


Date.now returns a value measured in milliseconds. Is it correct that these constants are measured in seconds?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now

Great catch! Fixed in c3dd54b

aduth · 2018-05-29T20:33:04Z

editor/store/selectors.js

@@ -1597,24 +1720,18 @@ export function getBlockListSettings( state, uid ) {
 *
 * @return {string[]|boolean} Blocks that can be nested inside the block with the specified uid, or true/false to enable/disable all types.
 */
+// Disable reason: We have to accept `globallyEnabledBlockTypes` so as to be backwards compatible


I don't understand. Can you explain what will break if globallyEnabledBlockTypes were removed as an argument here?

Nothing will break, but it masks the fact that this method accepts globallyEnabledBlockTypes as its third argument and must continue to do until it is removed in 3.2.

For example, say that we remove the argument. Now, imagine that a developer wants to add a new sortBy argument in version 3.0. They would likely change the signature to look like this:

function getSupportedBlocks( state, uid, sortBy = 'asc' )

The developer assumes that this is a non-breaking change, since they are just adding a new optional argument. But this is incorrect, since it will break any pre-3.0 code that makes calls such as wp.data.select( 'core/editor' ).getSupportedBlocks( 'abc123', [ 'core/paragraph' ] ).

Sounds reasonable. My question was mostly for...

Ensuring we don't keep dead code around (the reason the rule exists in the first place)

Clarifying wording, since it implies that it is necessary for some reason, though it is not used ("We have to accept...")

tomasruud · 2018-06-08T09:59:46Z

Are there any plans on making it possible to fetch nested block contents from a dynamic block?

aduth · 2018-06-19T20:39:37Z

@tomasruud The implementation of do_blocks (front-end block processing) is currently incapable of supporting nesting within dynamic blocks, since it does not consider tag balancing for dynamic block markers.


		* Type: `Array`

		Blocks can be inserted into other blocks as nested content. Sometimes it is useful to restrict a block so that it is only available as a nested block. For example, you might want to allow an 'Add to Cart' block to only be available within a 'Product' block.

Add support for Child Blocks #6753

Add support for Child Blocks #6753

Conversation

noisysocks commented May 15, 2018 • edited Loading

Description

How has this been tested?

Screenshots

Types of changes

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 May 16, 2018

brandonpayton May 16, 2018 • edited Loading

Choose a reason for hiding this comment

noisysocks May 17, 2018 • edited Loading

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

noisysocks commented May 17, 2018 • edited Loading

tofumatt commented May 17, 2018

noisysocks commented May 21, 2018

mtias commented May 21, 2018

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

aduth May 29, 2018 • edited Loading

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

gziolo commented May 23, 2018

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

jorgefilipecosta left a comment

Choose a reason for hiding this comment

noisysocks commented May 28, 2018

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

aduth May 29, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noisysocks commented May 15, 2018 •

edited

Loading

brandonpayton May 16, 2018 •

edited

Loading

noisysocks May 17, 2018 •

edited

Loading

noisysocks commented May 17, 2018 •

edited

Loading

aduth May 29, 2018 •

edited

Loading

aduth May 29, 2018 •

edited

Loading