Packages: Add notices package #9617

aduth · 2018-09-04T21:02:29Z

This pull request seeks to extract notices behaviors from the editor module to a new notices module, intended to serve largely the same purpose, but generalized to serve use-cases outside the editor. The API also largely remains the same, except with the addition of a new context option for specifying a simplified "area" value for notices grouping.

Planned to fork out into separate pull requests:

Already: Testing: Add lint rule for path on Lodash property functions #9615. Removed from changes here since no longer in active use after iterations.
Failing unit tests are because we don't load dependent stores within tests. When running tests within a directory, we should probably include its top-level index.js to ensure these dependencies have their expected stores defined. See related Packages: Make usage of core-data explicit #8911.
I copied onSubKey higher-order reducer creator from core-data. I'm starting to wonder if we might want to consider distributing these as some form of data/reducer utilities, akin to as @wordpress/compose is for higher-order components. Maybe a @wordpress/compose-data or @wordpress/compose-reducer.

Open question:

With introduction of "context", should we consider most of the notices as we have today as part of an "editor" context, or does the idea of a global context represent what we're showing today in the editor below the heading? It'd be my idea that what we have today serves the "global" usage, but it is screen-specific, and we might want to consider "properly global" notices (things like notifications center), where our notices aren't quite as global.
What should be included here so far as componentry? The "Notice" component seems generic enough that it's sensible to remain in @wordpress/components. With this module effectively serving as an orchestrator, it seems most all of the state-bound components should live within.

Future enhancements:

Our existing notices should ideally not include React elements, and rather represent content as a plain string. Most of our existing use of elements could be better served by a formal "actions" option (e.g. "View Post" on the save success) which is more future-compatible to notices design revisions.
I'm curious to explore whether the new context concept could be leveraged to eliminate most of what's served by the internal state of withNotices.

gziolo · 2018-09-05T09:30:58Z

packages/notices/package.json

@@ -0,0 +1,34 @@
+{
+	"name": "@wordpress/notices",
+	"version": "1.0.0",


1.0.0-beta.0 please :)

gziolo · 2018-09-05T09:31:41Z

packages/notices/package.json

+	],
+	"main": "build/index.js",
+	"dependencies": {
+		"@babel/runtime-corejs2": "7.0.0-beta.56",


Is should be replaced with:

"@babel/runtime": "^7.0.0",

since we are now using Babel 7 stable.

aduth · 2018-09-06T19:09:04Z

@gziolo @youknowriad I'm curious your opinion on:

I copied onSubKey higher-order reducer creator from core-data. I'm starting to wonder if we might want to consider distributing these as some form of data/reducer utilities, akin to as @wordpress/compose is for higher-order components. Maybe a @wordpress/compose-data or @wordpress/compose-reducer.

Another option I'm contemplating is repurposing @wordpress/compose to serve for any higher-order function composition, made evident by its compose import which would otherwise need to be duplicated redundantly into this new package if one were to be created. I'm not sure if it might cause some confusion however to have all these functions as part of the same package, partly for bloat and partly because it becomes unclear whether an import is to serve the purpose of creating a higher-order component or a higher-order reducer. Granted, there already is some confusion already in that some of what we export is technically a "higher-higher-order-function" (higher-order component creators).

aduth · 2018-09-06T20:21:18Z

I put together a rough concept for what I'd considered to be improvements to the test helpers to accommodate for the need to ensure stores for package are loaded (by ensuring all package src/index.js are imported for test). It had some negative cascading effects, so I opted instead for a more simplified approach here (basically import '../../' to trigger index imports).

For future reference, here's what I'd put together as the replacement for Jest's testRunner option:

const { dirname, resolve } = require( 'path' );
const DefaultRunner = require( 'jest-jasmine2' );
const pkgUp = require( 'pkg-up' );

function isPackageTestPath( rootDir, testPath ) {
	return testPath.startsWith( resolve( rootDir, 'packages' ) );
}

function getPackageEntryFile( testPath ) {
	const pkg = pkgUp.sync( testPath );
	if ( pkg ) {
		return resolve( dirname( pkg ), 'src/index.js' );
	}
}

module.exports = function( globalConfig, config, environment, runtime, testPath ) {
	const runner = DefaultRunner( globalConfig, config, environment, runtime, testPath );

	if ( isPackageTestPath( config.rootDir, testPath ) ) {
		const entry = getPackageEntryFile( testPath );
		if ( entry ) {
			runtime.requireModule( entry );
		}
	}

	return runner;
};

aduth · 2018-09-06T20:25:56Z

Updates:

Passing tests
Resolved conflicts
Use correct Babel dependencies

Remaining:

Document package
Transition deprecated usage (maybe)

aduth · 2018-10-12T17:56:28Z

This is now "complete" and could do for a proper review.

gziolo · 2018-10-22T13:40:07Z

I copied onSubKey higher-order reducer creator from core-data. I'm starting to wonder if we might want to consider distributing these as some form of data/reducer utilities, akin to as @wordpress/compose is for higher-order components. Maybe a @wordpress/compose-data or @wordpress/compose-reducer.

Another option I'm contemplating is repurposing @wordpress/compose to serve for any higher-order function composition, made evident by its compose import which would otherwise need to be duplicated redundantly into this new package if one were to be created. I'm not sure if it might cause some confusion however to have all these functions as part of the same package, partly for bloat and partly because it becomes unclear whether an import is to serve the purpose of creating a higher-order component or a higher-order reducer. Granted, there already is some confusion already in that some of what we export is technically a "higher-higher-order-function" (higher-order component creators).

I don't find it as a big problem that we duplicate 10 lines of code. We could land it as is. However if I would have to vote where to put this helper function, I think it makes more sense to make @wordpress/compose a general purpose component which offers all tools which help with composition. The only drawback I see is that this package depends on @wordpress/element.

I put together a rough concept for what I'd considered to be improvements to the test helpers to accommodate for the need to ensure stores for package are loaded (by ensuring all package src/index.js are imported for test). It had some negative cascading effects, so I opted instead for a more simplified approach here (basically import '../../' to trigger index imports).

It seems like a nice improvement to the current experience if you assume that those stores should be initialized. Personally, I think the ugliness of those imports raises the question whether our code doesn't depend too much on the internal state of stores. Maybe we should be more cautious when introducing such dependencies. Maybe we should rethink the way we mock and verify the usage of the data store. For instance, we could create mock helper utility which would allow us to easily operate on stores:

const noticesStore = mockStore( 'core/notices', {
    actions: {
        createSuccessNotice: jest.fn(),
    }
} );

expect( dispatch( 'core/notices' ).createSuccessNotice ).not.toHaveBeenCalled();

This way you wouldn't have to import @wordpress/notices package at all, it could operate on @wordpress/data directly.

Another question is how often we could offer a low-level pure function which operates on data fetched from the store which could be much easier unit tested.

gziolo · 2018-10-22T14:19:19Z

I added e9e8938 since token-list is used only in test.

gziolo

I think the only part left to review is all the changes in store effects. Otherwise it all looks good.

gziolo · 2018-10-22T15:33:15Z

packages/editor/src/store/actions.js

+
+	dispatch( 'core/notices' ).createNotice( status, content, options );
+
+	return { type: '__INERT__' };


I think I saw a different keyword in one of @youknowriad's PRs. Can we standardize it or it doesn't matter?

Realistically, it doesn't matter much, particularly for deprecations slated for removal, but I can plan to align for consistency's sake.

I don't see an instance of DO_NOTHING from his pull requests, so I'm going to assume it's either not been merged or no longer relevant. If it's not been merged, then... I win if I get mine in first 😛

gziolo · 2018-10-22T16:39:36Z

packages/editor/src/store/actions.js

-			status,
-			content,
-			isDismissible,
-			spokenMessage,


This code assumes that from now on spokenMessage is always equal to content - is it correct comparing to the previous behavior?

I believe so, in that previously we'd allow spokenMessage to be of type element, which is no longer supported (must be string).

Yeah right. It makes sense to consolidate now.

gziolo · 2018-10-22T16:46:59Z

packages/notices/src/store/selectors.js

+ *
+ * @type {Array}
+ */
+const DEFAULT_NOTICES = [];


Nit: Should we also move to constants.js file?

Maybe. I think the main value in constants.js are for variable constants used across files. This one is specific to selectors, however.

Nit: Should we also move to constants.js file?

I think I'd rather keep it here, per my previous comment.

gziolo · 2018-10-23T06:35:41Z

packages/notices/src/store/utils/on-sub-key.js

+ *
+ * @return {Function} Higher-order reducer.
+ */
+export const onSubKey = ( actionProperty ) => ( reducer ) => ( state = {}, action ) => {


My second thought is that it might be also a good idea to move it to data package next to other helpers like combineReducers as it has a very similar application. Eventually, we could extract those utilities to their own package. It's very unlikely that we will use it without reducers :)

I think I like that, especially if even the main fear would be bloat for a size-conscious module developer, it'd be easily omitted by tree shaking.

I think I like that, especially if even the main fear would be bloat for a size-conscious module developer, it'd be easily omitted by tree shaking.

Let's keep this to a follow-up pull request.

Agreed, this one is big enough 👍

gziolo · 2018-10-23T06:38:52Z

packages/notices/src/store/test/actions.js

+			} );
+		} );
+
+		it( 'should return action with context', () => {


Super nit: we can make this statement more explicit - ...action with *custom* context

Super nit: we can make this statement more explicit - ...action with *custom* context

Updated in rebased 009b8e916b3ae9fac32af65261713feab454097f.

gziolo · 2018-10-23T06:40:50Z

packages/notices/src/store/reducer.js

+		case 'CREATE_NOTICE':
+			// Avoid duplicates on ID.
+			return [
+				...reject( state, { id: action.notice.id } ),


Oh nice, I was using filter( not( ... ) ) - it's a nice shortcut and reads much better 👍

gziolo · 2018-10-23T06:43:04Z

packages/notices/src/store/actions.js

+ */
+import { DEFAULT_CONTEXT } from './constants';
+
+/**


I really like how you document code. Just wanted to emphasize it as I look at this PR 💯
How do you align @param definitions?

How do you align @param definitions?

I try to follow the guidelines in the Documentation Standard which in practice are to keep each fragment space-aligned (type, name, description) within each line-delimited grouping (param, return, etc).

I see, 80 characters per line is difficult to achieve but makes sense 👍

I forgot the 80 character thing was part of the standard. It's self-imposed elsewhere. It becomes ugly and tempting to bypass in cases like this, but I think it's a motivator to try to avoid complexity (e.g. in the naming of the type).

gziolo · 2018-10-23T06:45:28Z

packages/notices/src/store/actions.js

+ * @param {?Array<WPNoticeAction>} options.actions       User actions to be
+ *                                                       presented with notice.
+ */
+export function* createNotice( status = 'info', content, options = {} ) {


Do we have any docs about using generators with action creators? I would love to read it myself to better understand what is possible as of today. I feel like I'm missing some great capabilities by not knowing what options are provided out of the box.

Do we have any docs about using generators with action creators?

At the moment, I think they're best described by:

https://github.com/WordPress/gutenberg/tree/master/packages/data#controls

https://github.com/WordPress/gutenberg/tree/master/packages/redux-routine/

Thanks for sharing thos links, I will check them on Monday.

gziolo · 2018-10-23T06:48:16Z

packages/editor/src/store/test/effects.js

-				},
-				type: 'CREATE_NOTICE',
-			} ) );
+			expect( dataDispatch( 'core/notices' ).createSuccessNotice ).toHaveBeenCalled();


Is there any reason why we can assert using more detailed check similar to what was previousle and what I see later in the file, e.g.:

expect( dataDispatch( 'core/notices' ).createErrorNotice ).toHaveBeenCalledWith( 'Publishing failed', { id: SAVE_POST_NOTICE_ID } );

Is there any reason why we can assert using more detailed check similar to what was previousle and what I see later in the file, e.g.:

expect( dataDispatch( 'core/notices' ).createErrorNotice ).toHaveBeenCalledWith( 'Publishing failed', { id: SAVE_POST_NOTICE_ID } );

Updated in rebased c5985282b2a2b977fb10ddb37eb8a797fa13e566.

gziolo · 2018-10-23T06:49:27Z

packages/editor/src/store/effects/test/reusable-blocks.js

@@ -37,6 +36,7 @@ import {
 	fetchReusableBlocks as fetchReusableBlocksAction,
 } from '../../actions';
 import reducer from '../../reducer';
+import '../../..';


Can we add a comment why we import this thing? It can be copy and paste from what we had before.

Can we add a comment why we import this thing? It can be copy and paste from what we had before.

Updated in rebased 009b8e916b3ae9fac32af65261713feab454097f.

gziolo · 2018-10-23T06:52:12Z

packages/editor/src/store/effects/reusable-blocks.js

@@ -16,15 +16,17 @@ import {
 	cloneBlock,
 } from '@wordpress/blocks';
 import { __ } from '@wordpress/i18n';
+// TODO: Ideally this would be the only dispatch in scope. This requires either


I finally get the idea. It's not perfect but let's move on and refactor later.

@aduth @youknowriad how do you see the future or effects? Should we invest more time in improving them to make them capable of working with multiple stores?

If we keep effects, I think we should probably opt for using dispatch and select APIs directly, in place of the second store argument. This requires refactoring to respect current registry context, which was raised recently in the context of selectors and controls as well.

Whether we want to keep effects: I go back and forth. I think many of what we have as effects currently would be better served by controls, though I don't know for certainty if there isn't a valid use-case for effects. One that I might have argued for previously as a valid "side effect" would have been the speak behaviors, but even as proposed here I've implemented that as a yielded control.

I personally really like how speak is implemented. It’s very easy to follow when you omit all the fancy syntax that it requires 😅 I asked that because if we bet on controls then we don’t have to worry about using global dispatch hrre. It’s just optical change when we pass it as argument rather than store.

gziolo · 2018-10-23T06:54:12Z

packages/editor/src/store/effects/reusable-blocks.js

@@ -131,13 +133,14 @@ export const saveReusableBlocks = async ( action, store ) => {
 			id,
 		} );
 		const message = isTemporary ? __( 'Block created.' ) : __( 'Block updated.' );
-		dispatch( createSuccessNotice( message, { id: REUSABLE_BLOCK_NOTICE_ID } ) );
+		dataDispatch( 'core/notices' ).createSuccessNotice( message, {


It makes me wonder if we should refactor effects to take data as param rather than store. This would align closer to what we have in other parts of the applications, in particular, withSelect and withDispatch.

It makes me wonder if we should refactor effects to take data as param rather than store.

By date, would you mean the current registry? I guess that would work as a solution for https://github.com/WordPress/gutenberg/pull/9617/files#r228623495, but as noted in that comment, we'll need a similar solution for selectors and controls as well.

Yes, this is what I thought.

gziolo · 2018-10-23T06:56:42Z

packages/editor/src/store/effects/posts.js

-		dispatch( removeNotice( SAVE_POST_NOTICE_ID ) );
-		dispatch( removeNotice( AUTOSAVE_POST_NOTICE_ID ) );
+		dataDispatch( 'core/notices' ).removeNotice( SAVE_POST_NOTICE_ID );
+		dataDispatch( 'core/notices' ).removeNotice( 'autosave-exists' );


Why do we stop using this AUTOSAVE_POST_NOTICE_ID constant? Are there any blockers? Can't we use the trick with SAVE_POST_NOTICE_ID?

I kinda feel these constants are a waste of our resources, in the same way we don't bother with action type constants. I'll see about at least making things consistent, even if that means reintroducing the constant.

Why do we stop using this AUTOSAVE_POST_NOTICE_ID constant? Are there any blockers? Can't we use the trick with SAVE_POST_NOTICE_ID?

Looking at this more, I don't really like the idea of importing store constants into the EditorProvider component. And in general, I don't really like how we've implemented this notion of notices which should be dismissed on the next save. Rather than hard-coding their removal, it seems like it might be better to have some separate state tracking IDs of notices which should be removed on the next save. This way the EditorProvider could add to the state at the same time it's creating its notice, keeping the ID colocated.

Thoughts? Maybe better to defer to a follow-up pull request, keeping this one as-is?

It looks like we need to do decide on the future effects first. Then we can think about constants. As noted in another comment we probably shouldn’t use them at all in this context.

I’m on mobile so I can’t check the last part of your comment. It sounds like a good idea. We can discuss in the future. Let’s get this in first 😃

gziolo · 2018-10-23T07:01:04Z

There are local uncommitted changes after one or both of 'npm install' or 'npm run docs:build'!

Your own Travis check bites :)

I'm not sure why though. It doesn't change anything locally.

gziolo · 2018-10-23T07:20:06Z

To answer more of your questions:

With introduction of "context", should we consider most of the notices as we have today as part of an "editor" context, or does the idea of a global context represent what we're showing today in the editor below the heading? It'd be my idea that what we have today serves the "global" usage, but it is screen-specific, and we might want to consider "properly global" notices (things like notifications center), where our notices aren't quite as global.

That's an interesting question. I would keep global for some time and see how it evolves. As far as I understand the place we render them is going to contain notices that as of today are considered global.

Our existing notices should ideally not include React elements, and rather represent content as a plain string. Most of our existing use of elements could be better served by a formal "actions" option (e.g. "View Post" on the save success) which is more future-compatible to notices design revisions.

Yes, that would be great as it would make it possible to persist those notices if we ever have to.

What should be included here so far as componentry? The "Notice" component seems generic enough that it's sensible to remain in @wordpress/components. With this module effectively serving as an orchestrator, it seems most all of the state-bound components should live within.

The only bits that could be converted into a component exposed in @wordpress/notices packages would be something similar to EditorNotices from @wordpress/editor package:

function EditorNotices( props ) {
	return (
		<NoticeList { ...props }>
			<TemplateValidationNotice />
		</NoticeList>
	);
}

export default compose( [
	withSelect( ( select ) => ( {
		notices: select( 'core/notices' ).getNotices(),
	} ) ),
	withDispatch( ( dispatch ) => ( {
		onRemove: dispatch( 'core/notices' ).removeNotice,
	} ) ),
] )( EditorNotices );

It would have to take context as one of the props, so this code could be rewritten as:

function EditorNotices() {
    return (
        <Notices>
            <TemplateValidationNotice />
        </Notices>
    );
}

The only challenge would be to pass the context to onRemove but it can be easily implemented by proxing dispatch method.

gziolo · 2018-10-23T07:42:26Z

It works as expected with all the changes introduced. I can see all notices that were rendered before and I can use all links. I will give it 👍 as soon as Travis is happy and my questions are answered.

youknowriad · 2018-10-23T09:23:45Z

Just a quick note that we should notify the people working on Core integration because this impacts the scripts registration...

gziolo · 2018-10-23T10:16:16Z

lib/client-assets.php

 			'wp-rich-text',
+			'wp-url',


@atimmer @omarreiss @pento - pinging you, so you aware that this is coming up soon and we will have to update Core, too.

Just a quick note that we should notify the people working on Core integration because this impacts the scripts registration...

@youknowriad good call, done 😄

There's also a new script to register...

Thanks for the notification, putting it on my list for when I update the packages based on Gutenberg 4.2.

aduth · 2018-10-26T18:32:49Z

packages/editor/src/store/test/effects.js

-			expect( dispatch ).toHaveBeenCalledWith( expect.objectContaining( {
-				notice: {
-					content: <p>Post published.{ ' ' }<a>View post</a></p>, // eslint-disable-line jsx-a11y/anchor-is-valid
-					id: 'SAVE_POST_NOTICE_ID',


To my point about value of constants, we don't even use them consistently as constants.

Yes, let’s not use them at all then 😃

aduth · 2018-10-26T18:44:24Z

Thanks so much for the detailed review of this behemoth @gziolo .

I've pushed a rebased branch with conflicts resolved, feedback addressed, and commits squashed (with attribution preserved).

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>

Makes spokenMessage redundant by ensuring content is to be only assigned as plain string Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>

gziolo

Thanks for addressing my feedback and your in-depth answers. Let’s 🚢 it as soon as Travis is happy about the lock file.

aduth · 2018-10-29T12:57:32Z

Created two issues to track follow-up work:

Data: Consolidate onSubKey (and other helpers) to data module #11201 Data: Consolidate onSubKey (and other helpers) to data module
Editor: Eliminate or refactor store notices constants #11202 Editor: Eliminate or refactor store notices constants

aduth added npm Packages Related to npm packages [Status] In Progress Tracking issues with work in progress labels Sep 4, 2018

gziolo reviewed Sep 5, 2018

View reviewed changes

aduth force-pushed the add/notices-module branch from 3b1f547 to eb9a43e Compare September 6, 2018 20:25

aduth mentioned this pull request Sep 13, 2018

Capture admin notices and summarize them in editor #5590

Closed

3 tasks

gziolo mentioned this pull request Oct 12, 2018

Help notice displayed on Privacy Policy page missing in Gutenberg #10448

Closed

aduth force-pushed the add/notices-module branch 3 times, most recently from 21e0376 to 839c4ba Compare October 12, 2018 17:02

aduth removed the [Status] In Progress Tracking issues with work in progress label Oct 12, 2018

gziolo modified the milestones: 4.1, 4.2 Oct 12, 2018

aduth force-pushed the add/notices-module branch from 839c4ba to be2108e Compare October 22, 2018 13:00

gziolo reviewed Oct 22, 2018

View reviewed changes

gziolo reviewed Oct 23, 2018

View reviewed changes

aduth commented Oct 26, 2018

View reviewed changes

aduth force-pushed the add/notices-module branch from 3d4c7ee to 8e13dc1 Compare October 26, 2018 18:40

aduth force-pushed the add/notices-module branch from 8e13dc1 to c598528 Compare October 26, 2018 18:42

aduth and others added 2 commits October 26, 2018 16:00

Packages: Add notices package

cad4c05

Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>

Notices: Add actions support

08a18a4

Makes spokenMessage redundant by ensuring content is to be only assigned as plain string Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl>

aduth force-pushed the add/notices-module branch from 6a61bf3 to bedb328 Compare October 26, 2018 20:00

Editor: Port deprecated notices action to module usage

bd1f614

aduth force-pushed the add/notices-module branch from bedb328 to bd1f614 Compare October 26, 2018 21:32

gziolo approved these changes Oct 26, 2018

View reviewed changes

youknowriad merged commit 80f625c into master Oct 27, 2018

youknowriad deleted the add/notices-module branch October 27, 2018 09:32

This was referenced Oct 29, 2018

Data: Consolidate onSubKey (and other helpers) to data module #11201

Open

Editor: Eliminate or refactor store notices constants #11202

Open

JasonHoffmann mentioned this pull request Nov 15, 2018

Issue with Notices in Gutenberg 10up/distributor#252

Closed

aduth mentioned this pull request Nov 19, 2018

All notices should use a spokenMessage #9425

Closed

This was referenced Feb 6, 2019

Make the withNotices notices announced by assistive technologies #9443

Closed

Remove wp.data plugin support #12004

Closed


		dispatch( 'core/notices' ).createNotice( status, content, options );

		return { type: '__INERT__' };

Packages: Add notices package #9617

Packages: Add notices package #9617

Conversation

aduth commented Sep 4, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth commented Sep 6, 2018

aduth commented Sep 6, 2018

aduth commented Sep 6, 2018

aduth commented Oct 12, 2018

gziolo commented Oct 22, 2018 • edited Loading

gziolo commented Oct 22, 2018 • edited Loading

gziolo 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

gziolo Oct 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo Oct 26, 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

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 Oct 26, 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

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 Oct 23, 2018 • edited Loading

gziolo commented Oct 23, 2018 • edited Loading

gziolo commented Oct 23, 2018

youknowriad commented Oct 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

aduth commented Oct 26, 2018

gziolo left a comment

Choose a reason for hiding this comment

aduth commented Oct 29, 2018

aduth commented Sep 4, 2018 •

edited

Loading

gziolo commented Oct 22, 2018 •

edited

Loading

gziolo commented Oct 22, 2018 •

edited

Loading

gziolo Oct 22, 2018 •

edited

Loading

gziolo Oct 26, 2018 •

edited

Loading

gziolo Oct 26, 2018 •

edited

Loading

gziolo commented Oct 23, 2018 •

edited

Loading

gziolo commented Oct 23, 2018 •

edited

Loading