Framework: Add viewport module (data module experiments, proof-of-concept) #5206

aduth · 2018-02-22T21:49:29Z

This pull request seeks to implement a new generic @wordpress/viewport module to replace and generalize the current isMobile state maintained in edit-post. There are many changes here, some of which tentatively proposed, which could be split out into smaller pull request, but included here as part of the larger story of demonstrating a full-featured proof-of-concept standalone data-exposing module.

Specifically, ideas explored here include:

Modular data stores: Responding to viewport changes either using bundled isViewportMatch higher-order component, or by state directly
- e.g. call select( 'core/viewport' ).isViewportMatch( 'medium' );
- Mentioned on a few occasions already, but I'd considered such an approach for withAPIData as well to allow for API selectors and generalized availability (related discussion)
A registerStore shorthand to simultaneously register reducer and zero or more of actions and selectors
- Examples:
  - subscribe( 'core/editor', 'getBlocks', ( blocks ) => /* blocks changed */ );
  - subscribe( 'core/viewport', [ 'isViewportMatch', 'huge' ], () => /* huge changed */ )
~~A "side effects" pattern via selector subscriptions (and reducer-level subscriptions)~~ (Edit: Deferred to future exploration, see Framework: Add viewport module (data module experiments, proof-of-concept) #5206 (comment) )
Conditional-render higher-order component pattern, based on Implemented HoC ifPropsVerify and IfPostTypeSupports. #4812 and specifically the ideas put forth by @jorgefilipecosta in Implemented HoC ifPropsVerify and IfPostTypeSupports. #4812 (comment) (Edit: Now as separate "with" and "if" higher-order components as of cc2fb9f)

There's a dramatic simplification of post editor with these changes, as it no longer needs to maintain state about viewport.

Testing instructions:

Verify that there's no regressions in viewport behavior.

Examples:

The "More" menu should only show "Fix Toolbar to Top" option in large viewports
The sidebar should dismiss itself when collapsing from large to small viewport

Remaining tasks:

Unit tests
Top-level viewport module documentation

youknowriad · 2018-02-22T22:02:15Z

data/index.js

+ *
+ * @return {Object} Registered store object.
+ */
+export function registerStore( reducerKey, options ) {


I like it 👍

Yes, much nicer. I think this should be the only public API available. We could turn registerReducer, registerActions and registerSelectors into the implementation detail.

Unless we want to allow other plugins to make modifications to not their own stores.

aduth · 2018-02-22T22:02:32Z

An example of where this could prove valuable outside of edit-post is in editor. Did you know we're currently rendering the mobile block toolbar on desktop displays?

https://github.com/WordPress/gutenberg/blob/master/editor/components/block-list/block-mobile-toolbar.js

Yes, it's hidden by CSS, but it still incurs wasteful and unnecessary DOM reconciliation.

youknowriad · 2018-02-22T22:02:59Z

data/index.js

 */
-export const subscribe = ( listener ) => {
-	listeners.push( listener );
+export const subscribe = ( ...args ) => {


I like it a bit less, but not a blocker :) I can see the advantage of factorizing this kind of logic we could need in several places.

The alternative being:

let lastBlocks; subscribe( () => { const blocks = select( 'core/editor' ).getBlocks(); if ( blocks !== lastBlocks ) { // ... Blocks are known to have changed. } lastBlocks = blocks; } );

Aside from being verbose and clumsy, there's another issue here: The selector is called on every single state change to every single registered store. For expensive queries (even memoized), this would be quite resource intensive.

https://github.com/WordPress/gutenberg/blob/4ea8dd0ac5d38788adad8b093738eb54fa32b8bd/edit-post/store/effects.js#L42-L48 :)

Right, but in your example the subscribe logic is run when core/viewport state changes, which is not so great.

Minor not a blocker just a thought: In redux subscribes always receives a listener and there is no "filtering" possibility. In my opinion, I think we should also do the same, subscribe always receives just a listener, so we are consistent with redux. I understand filtering a specific change will be very a common case, so to address we can use: compose( selectorListner(selector), reducerListner( reducer ), subscribe ). This makes clear that some code is always executed for each change, and our functions selectorListner and reducerListner are just helpers to filter out change. Other helpers can be created in the future.

@jorgefilipecosta This is interesting. At its most generic, it really only requires a "has value changed" higher-order function to encapsulate the behavior from the original alternative. Something like:

subscribe( ifChanged( () => ( select( 'core/viewport' ).isViewportMatch( '< medium' ) ) )( () => { const isSmall = isViewportMatch( '< medium' ); // Collapse sidebar when viewport shrinks. if ( isSmall ) { dispatch( 'core/edit-post' ).closeGeneralSidebar(); } } ) );

Then it becomes a question of: Do we expect this to be such a common pattern that it's still worth building conveniences into the API itself? The above snippet is generic, and not terribly verbose or clumsy, but still more verbose than the changes that had been proposed here. Generalism can be an ideal, but it shouldn't deter us from creating conveniences for common patterns.

It's a discussion worth having though:

What other subscribe helpers could we imagine?

What sorts of things would we expect people to use selector subscriptions for?

To the latter question, I'm finding that this could satisfy any need for a side effect pattern in the data module. In fact, taken to its extreme, we might be able to replace all of our own internal side effects with this approach, representing the side effects as a result of a change in state. Can all of the current and foreseen side effects be stated this way, or is access to the raw actions, even those not resulting in a change, necessary? It'd require some investigation, but I'm inclined to say that we could and should try to model side effects on changes in state. This might help remedy some of the disorganization that has resulted in the various effects.js files. At a higher-level, it might even be seen as the data equivalent of React's visual declarative UI, where "props" in this case are the selector result(s).

As a testament to the clumsiness of #5206 (comment), this example code snippet inadvertently introduces an infinite loop 😏 (Dispatch causes subscribe to re-invoke before lastBlocks is assigned)

Thank you for thoughts and analysing this, it is good that we will be able to discuss this specifc part outside of the scope of the rest of the changes 👍

youknowriad · 2018-02-22T22:04:16Z

edit-post/store/index.js

+subscribe( 'core/viewport', [ 'isViewportMatch', '< medium' ], ( isSmall ) => {
+	// Collapse sidebar when viewport shrinks.
+	if ( isSmall ) {
+		dispatch( 'core/edit-post' ).closeGeneralSidebar();


I believe this is a new behavior, how was this handled before? The separation between the mobile sidebar and the desktop sidebar?

It was previously effected in edit-post/store/reducer.js's handling of the UPDATE_MOBILE_STATE action triggered by enhanceWithBrowserSize.

youknowriad · 2018-02-22T22:04:46Z

lib/client-assets.php

+	wp_register_script(
+		'wp-viewport',
+		gutenberg_url( 'viewport/build/index.js' ),
+		array(),


missing element, data and components here ;)

youknowriad

Awesome work, didn't test yet but the code is great.

gziolo · 2018-02-23T12:54:00Z

edit-post/store/middlewares.js

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


Yes, it should be removed with #4777, but my comment was missed.

gziolo · 2018-02-23T12:56:18Z

components/higher-order/if-condition/index.js

+ *
+ * @return {Function} Higher-order component.
+ */
+const ifCondition = ( predicate, propName ) => ( WrappedComponent ) => {


Yes, this one is cool 👍

gziolo · 2018-02-23T13:00:33Z

data/index.js

+ *
+ * @return {Function} Higher-order function to call with ifTrueFn.
+ */
+const when = ( predicate ) => ( ifTrueFn ) => ( ...args ) => {


It seems like when and whenWith should be extracted to their own file so we could have only public APIs in this file. Can we also add simple unit tests for both functions?

Create our own FP utility library? 😄

I'm fine about pulling ramda and recompose in 😄

Since 84c64c8 was removed in rebase, this is no longer relevant.

gziolo · 2018-02-23T13:05:42Z

data/test/index.js

+		expect( oneCallback ).toHaveBeenCalled();
+		expect( twoCallback ).not.toHaveBeenCalled();
+
+		oneUnsubscribe();


Minor: when expect fails unsubscribe methods won't be executed. It shouldn't have impact on other tests though. One way to solve it is to put all unsubscribe methods in an array and iterate over it using afterEach.

let unsubscribes = []; afterEach( () => { unsubscribes.forEach( ( unsubscribe ) => unsubscribe() ); unsubscribes = []; } ); it( '...', () => { unsubscribes.push( subscribe( 'one', oneCallback ) ); } );

or something like this.

Yeah, that's true. At the same time though, if a test fails, all bets are off. The only issue is if it impacted future failures that caused needless debugging. I'll see about adding lifecycle.

Exactly, it might fail not related tests in the future. It’s a minor thing and really hard to implement in a clean way 🙁

Since 84c64c8 was removed in rebase, this is no longer relevant. That said, before dropping, I did find it was pretty simple to implement a helper subscribe wrapper:

const unsubscribes = []; afterEach( () => { let unsubscribe; while ( ( unsubscribe = unsubscribes.shift() ) ) { unsubscribe(); } } ); function subscribeWithUnsubscribe( ...args ) { unsubscribes.push( subscribe( ...args ) ); }

gziolo · 2018-02-23T13:11:13Z

viewport/README.md

+	);
+}
+
+MyComponent = ifViewportMatches( '< small', 'isMobile' )( MyComponent );


This one might be confusing because it behaves differently than when it contains only one param. Should we create 2nd HOC component instead? Example:

MyComponent = withViewportProps( { isMobile: '< small' } )( MyComponent );

This one might be confusing because it behaves differently than when it contains only one param. Should we create 2nd HOC component instead?

I'd totally agree from a consumer's perspective these make sense as two separate components. My only worry is that from the component author's perspective, it's a fair amount of work if we want all "if" HOC to also have a complementary "with".

I might imagine we could leverage some composition here though:

ifViewportMatches = compose( [ withViewportMatch( '< small' ), ifPropsMatch( { isViewportMatch: true }, { omitProps: true } ), ] );

That’s interesting idea to compose two HOCs where both of them might be useful by their own, too.

Split to separate higher-order components withViewportMatch and ifViewportMatches in fe100d4.

gziolo · 2018-02-23T13:19:20Z

viewport/store/selectors.js

+ * @return {boolean} Whether viewport matches query.
+ */
+export function isViewportMatch( state, query ) {
+	const key = [ '>=', ...query.split( ' ' ) ].slice( -2 ).join( ' ' );


Minor: I had to spend some time to understand what's happening here. It might be only me, so feel free to ignore. It might be more code to express it differently, but maybe it would pay off. Example:

const key = query.split( ' ' ).length === 1 ? `>= ${ query }` : query;

I think it will work with the existing tests.

Minor: I had to spend some time to understand what's happening here.

Yeah, it's one of my favorite "clever" codes that I still find myself leaning on. 😄 I might argue it's a valuable pattern that we can introduce developers to. For example, I've also found value in using it to format a date as MM-DD-YYYY (where the source value of MM and DD can be one or two digits):

[ d.getMonth() + 1, d.getDate() ].map( ( n ) => ( '0' + n ).slice( -2 ) ).concat( d.getFullYear() ).join( '-' ) // "02-23-2018"

Maybe some clarifying comments explaining the behavior?

const lastTwo = items => items.slice( -2 ); cons key = lastTwo( [ '>=', ...query.split( ' ' ) ] ).join( ' ' );

For me personally, this would help :)

For me personally, this would help :)

https://lodash.com/docs/4.17.5#takeRight 😄

Added an inline comment and used Lodash's _.takeRight in rebased 217021a.

gziolo · 2018-02-23T13:25:15Z

I like this proposal. 👍

jorgefilipecosta · 2018-02-23T15:19:52Z

components/higher-order/if-condition/index.js

+		return <WrappedComponent { ...props } />;
+	};
+
+	EnhancedComponent.displayName = getWrapperDisplayName( WrappedComponent, 'condition' );


Should it be getWrapperDisplayName( WrappedComponent, 'ifCondition' );?

We omit prefixes in other places, but we might change this if this is confusing.

We omit prefixes in other places, but we might change this if this is confusing.

I'm thinking particularly with #5206 (comment) in mind, we might want to do this, since we could have two higher-order components with similar names distinguished on prefix, e.g. withViewportMatch, ifViewportMatches.

Also to the point of #5206 (comment), I'm starting to think maybe we could use a new higher-order component utility in place of the current getWrapperDisplayName to allow for easier HOC composition.

Example:

export default createHigherOrderComponent( 'ifViewportMatches', ( query ) => compose( [ withViewportMatch( { isViewportMatch: query } ), ifCondition( ( props ) => props.isViewportMatch ), ] ) );

@aduth, this is actually a great idea even for the regular HOCs. See:

const ifCondition = ( predicate ) => ( WrappedComponent ) => { const EnhancedComponent = ( props ) => { if ( ! predicate( props ) ) { return null; } return <WrappedComponent { ...props } />; }; EnhancedComponent.displayName = getWrapperDisplayName( WrappedComponent, 'ifCondition' ); return EnhancedComponent; };

vs.

const ifCondition = createHigherOrderComponent( 'ifCondition', ( predicate ) => ( WrappedComponent ) => { return ( props ) => { if ( ! predicate( props ) ) { return null; } return <WrappedComponent { ...props } />; }; }, );

I'm voting to refactor all HOCs to use the helper you proposed and update all prefixes to match what has been discussed here.

Implementation wise it might be non-trivial task because some HOCs take additional params and require a higher-order function to be involved :)

Implementation wise it might be non-trivial task because some HOCs take additional params and require a higher-order function to be involved :)

Yeah, I was thinking about this too. One option is to test whether the argument passed is a class extending Component, but this would mean that all higher-order components would have to be implemented as the full-on class form. Maybe not a big deal to impose this?

jorgefilipecosta · 2018-02-23T15:50:12Z

viewport/index.js

+ *
+ * @type {Object}
+ */
+const BREAKPOINTS = {


can we do something similar to what gutenberg/edit-post/store/constants.js does? Use the scss variable loader '!!sass-variables-loader!../assets/stylesheets/_breakpoints.scss';

can we do something similar to what gutenberg/edit-post/store/constants.js does? Use the scss variable loader '!!sass-variables-loader!../assets/stylesheets/_breakpoints.scss';

My main issue with this is that the breakpoints are defined in an edit-post stylesheet. Ideally those common SCSS variables don't remain there. The main issue we solve with the variable loader is avoiding repetition, but one of the goals with viewport module is at least to consolidate all viewport-related logic. So hopefully at most we'd have at most two sets to maintain: one in SCSS and one in JS.

Yes it's trade that makes sense to make, and as it is just this cases, it is not hard to maintain 👍

jorgefilipecosta · 2018-02-23T16:27:47Z

Awesome work here 👍This seems to work well, in my smoke tests I did not find regressions.

aduth · 2018-02-26T15:58:47Z

Tracking reference to reducer / selector subscription implementation, as I'm planning to drop it in rebase (and potentially explore separately): 84c64c8

gziolo · 2018-02-27T07:28:36Z

edit-post/components/header/fixed-toolbar-toggle/index.js

-	{ storeKey: 'edit-post' }
-)( withInstanceId( FeatureToggle ) );
+	} ) ),
+	ifViewportMatches( 'medium' ),


Would it make any difference in case ifViewportMatches( 'medium' ) would be composed as the first item here? All HOCs would have to be applied when the source file loads, but it seems like withSelect and withDispatch wouldn't have to be rendered in case the viewport doesn't match. It might only make any difference on the initial render if I process the application flow properly.

Would it make any difference in case ifViewportMatches( 'medium' ) would be composed as the first item here?

I'll test it, but yes, this seems like it could potentially serve as a (small) optimization.

gziolo · 2018-02-27T07:29:41Z

edit-post/components/header/header-toolbar/index.js

+	withSelect( ( select ) => ( {
+		hasFixedToolbar: select( 'core/edit-post' ).isFeatureActive( 'fixedToolbar' ),
+	} ) ),
+	withViewportMatch( { isLargeViewport: 'medium' } ),


It looks really nice. Thanks for taking my feedback into account 👍

gziolo · 2018-02-27T07:30:32Z

edit-post/store/index.js

-const store = applyMiddlewares(
-	registerReducer( MODULE_KEY, withRehydratation( reducer, 'preferences', STORAGE_KEY ) )
-);
+const store = registerStore( 'core/edit-post', {


So much nicer 💯

gziolo · 2018-02-27T07:32:28Z

lib/client-assets.php

+	wp_register_script(
+		'wp-viewport',
+		gutenberg_url( 'viewport/build/index.js' ),
+		array( 'wp-element', 'wp-data', 'wp-components' ),


Just noting that it has too many dependencies to move it to @wordpress/packages.

gziolo · 2018-02-27T07:34:53Z

viewport/README.md

+	);
+}
+
+MyComponent = withViewportMatch( { isMobile: '< small' } )( MyComponent );


I'm still not sure whether we shoud pick the signature closer to what you proposed before:

MyComponent = withViewportMatch( 'isMobile', '< small' )( MyComponent );

or

MyComponent = withViewportMatch( { isMobile: '< small' } )( MyComponent );

The latter seems to be more flexible, but we don't have any use case in the code that validates we need that capability.

I'm still not sure whether we shoud pick the signature closer to what you proposed before:

In my initial attempt at splitting the components, I'd gone with the first of the two, but upon some reflection I think the object form is better:

More familiar in other usage of higher-order components which map to props as an object (e.g. withSelect)

Allows for multiple viewport props to be provided (handling multiple cases of viewport size)

Yes, probably is the best to keep it as it is.

gziolo · 2018-02-27T07:37:04Z

viewport/if-viewport-matches.js

+ */
+const ifViewportMatches = ( query ) => ( WrappedComponent ) => {
+	const EnhancedComponent = compose( [
+		withViewportMatch( {


This is amazing, how you composed 2 existing HOCs to create another one 🚀

gziolo · 2018-02-27T07:37:43Z

viewport/if-viewport-matches.js

+
+/**
+ * Higher-order component creator, creating a new component which renders if
+ * the viewport query is satisfied or with the given optional prop name.


or with the given optional prop name - this part is no longer applicable.

gziolo · 2018-02-27T07:54:47Z

viewport/index.js

+ *
+ * @type {Object<string,MediaQueryList>}
+ */
+const queries = reduce( BREAKPOINTS, ( result, width, name ) => {


Nit: setIsMatching might be declared after queries to signal that it depends on it.

Nit: setIsMatching might be declared after queries to signal that it depends on it.

Actually, this was tricky. I'd originally had it as you suggest, but the problem was that when adding the list.addListener( setIsMatching ) below, it would work in that setIsMatching was already declared via variable hoisting, but undefined at the time. addListener happily accepted the undefined value, but would never trigger the callback when it changed.

Got you. I missed that 👍

gziolo · 2018-02-27T07:55:52Z

viewport/store/selectors.js

+export function isViewportMatch( state, query ) {
+	// Pad to _at least_ two elements to take from the right, effectively
+	// defaulting the left-most value.
+	const key = takeRight( [ '>=', ...query.split( ' ' ) ], 2 ).join( ' ' );


gziolo · 2018-02-27T07:57:46Z

viewport/with-viewport-match.js

+ * @return {Function} Higher-order component.
+ */
+const withViewportMatch = ( queries ) => ( WrappedComponent ) => {
+	const EnhancedComponent = compose( [


We don't need compose in here.

gziolo · 2018-02-27T08:01:21Z

edit-post/components/header/fixed-toolbar-toggle/index.js

-		onMobile: isMobile( state ),
-	} ),
-	( dispatch, ownProps ) => ( {
+export default compose( [


See how compose is implemented in Ramda: http://ramdajs.com/docs/#compose. Lodash allows to pass an array, but in the FP world it is a function that takes any number of functions:

((y → z), (x → y), …, (o → p), ((a, b, …, n) → o)) → ((a, b, …, n) → z)

Lodash allows to pass an array, but in the FP world it is a function that takes any number of functions:

Yeah, I don't feel strongly one way or the other, but knowing how arguments works with Function#length and various V8 deoptimizations, I am (apathetically) cautious to avoid it for fear of encouraging its use.

Tangentially related: See classcat vs. classnames where the difference is passing as array vs. arguments respectively, with the former benefitting as such both in performance and bundle size.

Feel free to measure the impact in here and add Eslint rule so we could fly with one style 👍
Speaking myself, it’s also tempting to teach Babel to optimize our code, in cases like this. I’m fine with the surrounding array syntax but I’d love to see one style everywhere.

gziolo

Code-wise, I think this one is ready to be merged after some very minor issues are addressed. Great work on this one @aduth 💯

aduth added Framework Issues related to broader framework topics, especially as it relates to javascript [Feature] Extensibility The ability to extend blocks or the editing experience labels Feb 22, 2018

youknowriad reviewed Feb 22, 2018

View reviewed changes

jorgefilipecosta self-requested a review February 22, 2018 22:27

aduth force-pushed the add/if-viewport-size branch 2 times, most recently from 1d68420 to be72f5b Compare February 23, 2018 02:22

aduth mentioned this pull request Feb 23, 2018

MetaBoxes: Moving meta boxes out of the generic editor module #5175

Merged

gziolo reviewed Feb 23, 2018

View reviewed changes

edit-post/store/middlewares.js Outdated

@@ -1,44 +0,0 @@

/**

Copy link

Member

gziolo Feb 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it should be removed with #4777, but my comment was missed.

gziolo reviewed Feb 23, 2018

View reviewed changes

jorgefilipecosta reviewed Feb 23, 2018

View reviewed changes

aduth mentioned this pull request Feb 26, 2018

Visual Editor: Refactor VisualEditor to use data query #5083

Closed

aduth force-pushed the add/if-viewport-size branch 4 times, most recently from 316850e to cc2fb9f Compare February 26, 2018 16:18

aduth mentioned this pull request Feb 26, 2018

Data: Fix issue with in-stack unsubscribe #5266

Merged

gziolo reviewed Feb 27, 2018

View reviewed changes

gziolo approved these changes Feb 27, 2018

View reviewed changes

aduth added 3 commits February 27, 2018 11:52

Testing: Fix typo in post editor source lint rule

3205c56

Components: Add ifCondition higher-order component

48eeed9

Data: Add registerStore convenience registration

5cc4e87

aduth force-pushed the add/if-viewport-size branch from cc2fb9f to 3db32df Compare February 27, 2018 16:56

aduth added 2 commits February 27, 2018 12:00

Framework: Add viewport module

da2145f

Post Editor: Port editor to use viewport module

46ddc61

aduth force-pushed the add/if-viewport-size branch from e9af8be to 6e20425 Compare February 27, 2018 17:02

aduth added 2 commits February 27, 2018 12:03

Viewport: Split withViewportMatch from ifViewportMatches

adae3e2

Edit Post: Remove unused viewportType preference

798fd32

aduth force-pushed the add/if-viewport-size branch from 6e20425 to 798fd32 Compare February 27, 2018 17:03

aduth added this to the 2.3 milestone Feb 27, 2018

aduth merged commit 09f0f92 into master Feb 27, 2018

aduth deleted the add/if-viewport-size branch February 27, 2018 19:38

This was referenced Feb 28, 2018

Block List: Use ifViewportMatches to render BlockMobileToolbar as appropriate #5297

Merged

Block Toolbar: Do not hide the block toolbar on mobile #5349

Merged

Documentation: Rewrite Data docs as tutorial #5379

Merged

aduth mentioned this pull request Mar 21, 2018

Element: Provide createHigherOrderComponent helper #5728

Merged

Framework: Add viewport module (data module experiments, proof-of-concept) #5206

Framework: Add viewport module (data module experiments, proof-of-concept) #5206

Conversation

aduth commented Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth commented Feb 22, 2018

Choose a reason for hiding this comment

aduth Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

youknowriad Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth Feb 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

aduth Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad 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

gziolo Feb 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo Feb 23, 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

aduth Feb 23, 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

aduth Feb 23, 2018 • edited Loading

Choose a reason for hiding this comment

gziolo Feb 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth Feb 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo Feb 27, 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

jorgefilipecosta commented Feb 23, 2018

aduth commented Feb 26, 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

gziolo Feb 27, 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

aduth commented Feb 22, 2018 •

edited

Loading

aduth Feb 22, 2018 •

edited

Loading

youknowriad Feb 22, 2018 •

edited

Loading

aduth Feb 26, 2018 •

edited

Loading

aduth Feb 22, 2018 •

edited

Loading

gziolo Feb 23, 2018 •

edited

Loading

gziolo Feb 23, 2018 •

edited

Loading

aduth Feb 23, 2018 •

edited

Loading

aduth Feb 23, 2018 •

edited

Loading

gziolo Feb 23, 2018 •

edited

Loading

aduth Feb 26, 2018 •

edited

Loading

gziolo Feb 27, 2018 •

edited

Loading

gziolo Feb 27, 2018 •

edited

Loading