docs(repository): describe HasMany relation #1500

b-admike · 2018-07-09T15:23:35Z

Documentation for has many relation. Includes sections on how to define and configure has many relation, and use its CRUD APIs in controller methods.

Connect to #1351

Checklist

npm test passes on your machine
New tests added or existing tests modified to cover all changes
Code conforms with the style guide
API Documentation in code was updated
Documentation in /docs/site was updated
Affected artifact templates in packages/cli were updated
Affected example projects in examples/* were updated

shimks

Looks 🔥
I think each relation should have their own page, similar to how we have relation docs spread out in the lb2/3 docs.
Don't forget the sidebar entries as well

shimks · 2018-07-09T15:31:33Z

docs/site/Relations.md

+relation definition, certain constraints need to be honoured by the target model
+repository, and thus, we produce a constrained version of it as a navigational
+property on the source repository. The first relation type we have available is
+the `has many` relation which operates by constraining the target repository by


We should probably just call has many HasMany like we do in lb3 documentation.

I also think that we should probably extract out HasMany into a 'relations list' where we show what relations lb4 supports. Something like this:

Supported relations: - [HasMany](HasMany-relations.md or something along that line)

shimks · 2018-07-09T15:35:51Z

docs/site/Relations.md

+constructor and optionally a custom foreign key to store the relation metadata.
+The decorator logic also designates the relation type and tries to infer the
+foreign key on the target model (or `keyTo` in the relation metadata) as a
+sensible default value which is used in LoopBack 3. It also calls


What is the sensible default value here?

actually why sensible? :) is it better to omit this word?

Sorry if I wasn't clear. I think there should be a concrete formula for how the foreign key is inferred (camelcased target model name + Id)

shimks · 2018-07-09T15:36:25Z

docs/site/Relations.md

+`property.array()` to ensure that the type of the property is inferred properly
+as an array of the target model instances. The decorated property name is used
+as the relation name and stored as part of the source model definition's
+relation metadata. The following example shows how to define a `hasMany`


Line break here please

shimks · 2018-07-09T15:37:31Z

docs/site/Relations.md

+
+```js
+{
+  type: 2; // denotes hasMany relation


we should clarify that this is an enum value

shimks · 2018-07-09T15:40:09Z

docs/site/Relations.md

+
+```ts
+{import} {Order} from '../models/order.model.ts';
+{import} {Customer} from '../models/customer.model.ts';


Nitpick: have the two imports above come from the same directory (../models)

shimks · 2018-07-09T15:53:27Z

docs/site/Relations.md

+  Customer,
+  typeof Customer.prototype.id
+> {
+  public orders: HasManyRepositoryFactory<Order, typeof Order.prototype.id>;


This should be `HasManyRepositoryFactory<Order, typeof Customer.prototype.id>

shimks · 2018-07-09T15:53:37Z

docs/site/Relations.md

+couple of steps involved to configure it and use it. On the source repository,
+the following are required:
+
+- Use [Dependency Injectition](Dependency-injection.md) to inject an instance of


Spelling error

shimks · 2018-07-09T15:54:46Z

docs/site/Relations.md

+content="/src/repositories/customer.repository.ts.ts" %}
+
+```ts
+{import} {Order} from '../models/order.model.ts';


Remove the brackets around import.
I think this is breaking the markdown rendering

shimks · 2018-07-09T15:57:54Z

docs/site/Relations.md

+
+Once the has many relation has been defined and configured, it can be accessed
+via controller methods to call the underlying constrained repository CRUD APIs
+and exposed in LoopBack's swagger UI once decorated with


I think exposed as a route is good enough here. Not really opposed to what you have here though

shimks · 2018-07-09T15:59:31Z

docs/site/Relations.md

+  @post('/customers/{id}/order')
+  async createCustomerOrders(
+    @param.path.number('id') customerId: number,
+    @requestBody() orderData: Partial<Order>,


The type needs to be Order here due to the limitation of requestBody. This should be tracked until #1443 is fixed

b-admike · 2018-07-09T17:32:18Z

@shimks @dhmlau Thank you for your feedback! I have applied them; PTAL

dhmlau

It's good to see we're using Customer/Order example which aligns with the demo scenario we want to do for GA. :)
A few things to consider below. We can leave it out of this PR and have a separate task to track it.

agree with @shimks to have separate pages for different relations. We can do that once we have more relation supported as well.
it would be good to have a diagram to show the relationship between Customer/Order model and Customer/Order repository.

dhmlau · 2018-07-09T17:43:10Z

docs/site/HasMany-relation.md

+summary:
+---
+
+## Defining a HasMany Relation


I think the logical separation of the sections makes perfect sense, but wondering if we can make the title/first sentence clearer to describe the purpose... to make it easier to read/understand.

IIUC,

Defining a HasMany Relation - it's defining the hasMany relation at the model level using @hasmany decorator.

Configuring a HasMany relation - configuring the relation at the repository level (something along the line). Does it control how the data is retrieved or how the payload look like?

Using HasMany constrained repository in a controller - it's about the usage in controller.

I am proposing to start with a short overview providing a high-level list of steps needed to add a relation to a LB4 app. For example:

To add a HasMany relation to your LoopBack application, you need to perform the following steps: 1. Add a property to your model to access related model instances. 2. Modify the source model repository class to provide access to a constrained target model repository 3. (...)

shimks · 2018-07-09T18:19:58Z

docs/site/sidebars/lb4_sidebar.yml

  - title: 'Decorators'
    url: Decorators.html
    output: 'web, pdf'
+    children:


Does this work as intended? Shouldn't it be under Relations?

Good catch. Fixed :)

shimks · 2018-07-09T18:24:37Z

docs/site/HasMany-relation.md

+
+## Defining a HasMany Relation
+
+The first relation type we have available is the `hasMany` relation which


We should probably reword this sentence so that we don't give precedence (ordering) to the relations we support

What Diana has said

b-admike · 2018-07-09T19:21:12Z

@shimks @dhmlau Feedback applied, thanks! PTAL :)

it would be good to have a diagram to show the relationship between Customer/Order model and Customer/Order repository.

Yeah I agree that this can come later or with a blog post :-).

jannyHou

@b-admike Great stuff! The document introduced how to define a relation + creates the crud repository + inject the repo in a controller in a well organized way.

Just a few comments. LGTM

jannyHou · 2018-07-10T02:49:03Z

docs/site/HasMany-relation.md

+
+{% include code-caption.html content="/src/models/customer.model.ts" %}
+
+```ts


Might be a quite subjective feeling, but I was willing to see the code example first when reading the document.
For example:

The definition of the hasMany relation is inferred by using the hasMany decorator. The decorator takes in the target model class constructor and optionally a custom foreign key to store the relation metadata.

Without seeing the code, I find it a little bit hard to imagine how this decorator would look like and not that easy to follow its further details like what it takes in :-p

jannyHou · 2018-07-10T02:49:27Z

docs/site/HasMany-relation.md

+  @post('/customers/{id}/order')
+  async createCustomerOrders(
+    @param.path.number('id') customerId: number,
+    @requestBody() orderData: Order, // FIXME(b-admike): should be Partial<Order> once https://github.com/strongloop/loopback-next/issues/1443 is fixed


nitpick: maybe remove the comment code?

+1 to remove or rework the comment.

BTW the linked issue has been closed in favour of #1179.

If we want to explain that orderData should use a different type in the future, then please add a "note" banner after the code snippet and explain the issue in more details. (I think it is a good idea to explain this problem to readers.)

bajtos

Nice start!

bajtos · 2018-07-10T12:27:59Z

docs/site/HasMany-relation.md

+summary:
+---
+
+## Defining a HasMany Relation


I am proposing to start with a short overview providing a high-level list of steps needed to add a relation to a LB4 app. For example:

To add a HasMany relation to your LoopBack application, you need to perform the following steps: 1. Add a property to your model to access related model instances. 2. Modify the source model repository class to provide access to a constrained target model repository 3. (...)

bajtos · 2018-07-10T12:29:01Z

docs/site/HasMany-relation.md

+permalink: /doc/en/lb4/HasMany-relation.html
+summary:
+---
+


Please start this documentation page with a short explanation what is HasMany relation. I think we can pretty much copy the "Overview" section from https://loopback.io/doc/en/lb3/HasMany-relations.html

✅
(this has been resolved by content added below the line 10)

bajtos · 2018-07-10T12:30:57Z

docs/site/HasMany-relation.md

+  @property({
+    type: 'string',
+  })
+  name: string;


name?: string;

Alternatively, mark the property as required:true

bajtos · 2018-07-10T12:31:35Z

docs/site/HasMany-relation.md

+  })
+  name: string;
+
+  @hasMany(Order) orders: Order[];


Ditto, I think orders should be an optional property - for example, the default CRUD repository methods like find or create are not setting this property.

bajtos · 2018-07-10T12:32:25Z

docs/site/HasMany-relation.md

+
+```js
+{
+  type: 2; // denotes hasMany relation (this is an enum value)


Hmm, this is not great - the code is more difficult to debug and even more difficult to write in JavaScript (in the future). We should switch to string-based enums, so that type can be hasMany.

If you prefer, then I am ok to leave this change out of DP3 as long as you create a new GH issue labelled as LB4 GA and p1.

Done. The change was easy enough :-).

bajtos · 2018-07-10T12:52:09Z

docs/site/Relations.md

+
+## Overview
+
+Model relation in LoopBack 3 is one of its powerful features which help users


Please consider adding more content from https://loopback.io/doc/en/lb3/Creating-model-relations.html

I thought the content there is still relevant so I've copied some stuff from the overview.

bajtos · 2018-07-10T12:53:03Z

packages/repository/test/acceptance/has-many-without-di.relation.acceptance.ts

-    public orders: HasManyRepositoryFactory<Order, typeof Order.prototype.id>;
+    public orders: HasManyRepositoryFactory<
+      Order,
+      typeof Customer.prototype.id


👍

Here you are using HasManyRepositoryFactory with correct types (source model, target id). Let's fix the documentation too. (See one of my earlier comments above.)

bajtos · 2018-07-10T12:54:33Z

docs/site/HasMany-relation.md

+```
+
+The property type metadata is also preserved as an array of type `Order` as part
+of the decoration. Another usage of the decorator with a custom foreign key name


The property type metadata is also preserved as an array of type Order as part of the decoration.

I have no idea what does this mean for me as a LB4 user. Please explain this in the context of LB4 apps, controllers or repositories and perhaps add a code snippet to better illustrate what you mean.

bajtos · 2018-07-10T12:57:13Z

docs/site/HasMany-relation.md

+}
+```
+
+The metadata generated for the above decoration is as follows:


IMO, the metadata format is an implementation details that most (if not all) LoopBack users should not need to understand in order to build and troubleshoot their applications. I am proposing to remove this section from the docs and perhaps move it to API docs and/or convert into code comments in the appropriate place.

I wrote this thinking that the docs might have a wider audience than our users or that users who are developers would like to know the info. But I agree, it doesn't really have a place here. I'll remove it for now and find an appropriate place for it as you have suggested.

bajtos · 2018-07-10T12:59:15Z

docs/site/HasMany-relation.md

+
+{% include code-caption.html
+content="src/controllers/customer-orders.controller.ts" %}
+


Please add a short paragraph explaining that:

in LB3, methods for accessing related models were part of the same source model class

in LB4, we recommend to create a new controller for each relation in order to keep the controller classes smaller. I.e. don't add order-related methods to CustomerController, but create a new CustomerOrdersController class for them.

dhmlau

LGTM in general. There are a few comments, you can pick the ones that are appropriate. Thanks.

dhmlau · 2018-07-11T14:15:03Z

docs/site/HasMany-relation.md

+
+## Defining a HasMany Relation
+
+To add a `HasMany` relation to your LoopBack application, you need to perform


it seems like the steps fit better in the overview, because this section is already about the first step. Just a suggestion

Good catch! That is where it should be :-).

dhmlau · 2018-07-11T14:17:26Z

docs/site/HasMany-relation.md

+
+Model relations in LoopBack 4 are defined by having a decorator on a designated
+relational property. This section describes how to define a `hasMany` relation
+at the model level using the `hasMany` decorator. The relation constrains the


Suggestion:
the hasMany decorator -> the @hasMany decorator

dhmlau · 2018-07-11T14:23:05Z

docs/site/HasMany-relation.md

+
+## Configuring a HasMany relation
+
+The configuration and resolution of a `HasMany` relation takes place at the


nitpick: we have been using hasMany instead of HasMany in the previous paragraph. it would be good to keep it consistent.

I agree; I'll stick with hasMany.

dhmlau · 2018-07-11T14:23:22Z

docs/site/HasMany-relation.md

+## Configuring a HasMany relation
+
+The configuration and resolution of a `HasMany` relation takes place at the
+repository level. Once `HasMany` relation is defined on the source model, then


same as above. HasMany -> hasMany

bajtos

Looks mostly good, see few minor comments below.

When cleaning up the history, please split the changes into multiple commits, so that documentation changes are not mixed with changes in the runtime APIs. This is important to allow our changelog generator to correctly capture all changes in the changelog.

Ideally, I think there should be following commits:

Change RelationType from numeric to string enums
Switch order of generic arguments of HasManyRepositoryFactory
Add docs for HasMany relation

bajtos · 2018-07-12T11:35:03Z

docs/site/HasMany-relation.md

+  `HasManyRepositoryFactory<targetModel, typeof sourceModel.prototype.id>` on
+  the source repository class.
+- call the `_createHasManyRepositoryFactoryFor` function in the constructor of
+  the source repository class with the relation name (decorated relation propert


typo: propert -> property

bajtos · 2018-07-12T11:37:13Z

docs/site/HasMany-relation.md

+  ) {}
+
+  @post('/customers/{id}/order')
+  async createCustomerOrders(


Perhaps createOrderOfCustomer would be a better name, considering that the first method argument is customerId?

If not, then at least change the name into singular because we are creating a single order: createCustomerOrder.

Another name to consider: createOrder or simply create - both the source and target model names are already captures in the controller name.

Thank you for those suggestions @bajtos. I like either createOrderOfCustomer or createOrder. Let's go with createOrder.

bajtos · 2018-07-12T11:38:05Z

packages/repository/src/decorators/relation.decorator.ts

+  embedsOne = 'embedsOne',
+  embedsMany = 'embedsMany',
+  referencesOne = 'referencesOne',
+  referencesMany = 'referencesMany',


Lovely 👍

b-admike · 2018-07-12T14:23:10Z

When cleaning up the history, please split the changes into multiple commits, so that documentation changes are not mixed with changes in the runtime APIs. This is important to allow our changelog generator to correctly capture all changes in the changelog.

Ideally, I think there should be following commits:

Change RelationType from numeric to string enums
Switch order of generic arguments of HasManyRepositoryFactory
Add docs for HasMany relation

Sounds good 💯

bajtos · 2018-07-12T14:23:17Z

docs/site/HasMany-relation.md

@@ -189,4 +189,18 @@ export class CustomerOrdersController {
 }
 ```

-<!--- TODO: Add details about `orderData` variable typing issue --->
+In LoopBack 3, methods for accessing related models were part of the source
+model class i.e. `customer.orders.find(...)`. We recommend to create new


In LB 3.x, the REST API for relations was exposed via static methods with the name following the pattern __{methodName}__{relationName}__, for example Customer.__find__orders.

Oh I was looking at https://loopback.io/doc/en/lb3/HasMany-relations.html#methods-added-to-the-model when I wrote that. But you're right, this is about REST APIs 👍

bajtos · 2018-07-12T14:24:15Z

docs/site/HasMany-relation.md

+for them.
+
+{% include note.html content="
+The type of `orderData` above will possibly change to `Partial<Order>` exclude


I think you are missing "to" before "exclude":

change to `Partial<Order>` to exclude

jannyHou

🎉

shimks

Good stuff
Can you ping Diana for help so that you can match your diagram with styling in hers (the one for Todo)?

shimks · 2018-07-12T14:28:15Z

docs/site/Relations.md

+of the model instances and query and filter the information based on the
+client’s needs.
+
+Model relation in LoopBack 3 is one of its powerful features which help users


shimks · 2018-07-12T14:29:05Z

docs/site/Relations.md

+each of the models, and add querying and filtering capabilities for the relation
+APIs after scaffolding their LoopBack applications. In LoopBack 4, with the
+introduction of [repositories](Repositories.md), we aim to simplify the approach
+to relations by creating constrained repositories. This means that, based on the


No comma here

shimks · 2018-07-12T14:29:29Z

docs/site/Relations.md

+introduction of [repositories](Repositories.md), we aim to simplify the approach
+to relations by creating constrained repositories. This means that, based on the
+relation definition, certain constraints need to be honoured by the target model
+repository, and thus, we produce a constrained version of it as a navigational


no comma: repository, and thus we produce ....

shimks · 2018-07-12T14:31:22Z

docs/site/Relations.md

+
+- [HasMany](HasMany-relation.md)
+
+The articles on each type of relation above will show you how to leverage the


I wonder if we should provide an example of what the controller route of a related model would look like here. I think it'd provide users with good idea of what relation involves in code

Well we provide all that information at the hasMany relation page, so wouldn't that be sufficient?

Sure, but I think that readers shouldn't be expected to find an example of relation in general being used in the pages dedicated to each of the relations.

That being said, probably not a big deal

shimks · 2018-07-12T14:31:58Z

docs/site/HasMany-relation.md

+key on the source model. This relation indicates that each instance of the
+declaring or source model has zero or more instances of the target model. For
+example, in an application with customers and orders, a customer can have many
+orders, as illustrated in the diagram below.


shimks · 2018-07-12T14:55:09Z

docs/site/HasMany-relation.md

+
+- `create` for creating a target model instance belonging to customer model
+  instance
+  ([API Docs](https://apidocs.strongloop.com/@loopback%2fdocs/repository.html#DefaultHasManyEntityCrudRepository.prototype.create))


I noticed that the apidocs for HasManyInterface is more descriptive. Should we replace the link with that anchor or nah

Good catch. Yes, will replace 👍

shimks · 2018-07-12T14:56:41Z

docs/site/HasMany-relation.md

+
+```ts
+import {post, param, requestBody} from '@loopback/rest';
+import {customerRepository} from '../repositories/customer.repository.ts';


nitpick: ../repositories

shimks · 2018-07-12T14:59:30Z

docs/site/HasMany-relation.md

+```
+
+In LoopBack 3, the REST APIs for relations were exposed using static methods
+with the name following the pattern `__{methodName}__{relationName}__`, for


wrap the for example ... in parenthesis instead of using a comma break.

shimks · 2018-07-12T14:59:36Z

docs/site/HasMany-relation.md

+
+In LoopBack 3, the REST APIs for relations were exposed using static methods
+with the name following the pattern `__{methodName}__{relationName}__`, for
+example `Customer.__find__orders`. We recommend to create a new controller for


Line break here please. The latter paragraph might be better as a note, but not a big deal

I don't think a line break is needed here since the first sentence is supposed to be an opener for the whole paragraph.

shimks · 2018-07-12T15:01:14Z

docs/site/HasMany-relation.md

+  Customer,
+  typeof Customer.prototype.id
+> {
+  public orders: HasManyRepositoryFactory<Order, typeof Customer.prototype.id>;


The generics here need to be switched around.

shimks · 2018-07-12T19:48:14Z

docs/site/HasMany-relation.md


 ![hasMany relation illustration](./imgs/hasMany-relation-example.png)

-The target model, **Order**, has a property, **customerId**, as the foreign key
-to reference the declaring model **Customer's** primary key **id**.
+The diagram shows target model **Order** has a property **customerId** as the


Missed this in the last review, remove the a form has a property

shimks · 2018-07-12T19:49:46Z

docs/site/HasMany-relation.md

-relational repositories and thus the controllers which use them. Therefore, as
-shown above, don't add order-related methods to `CustomerController`, but
-instead create a new `CustomerOrdersController` class for them.
+with the name following the pattern `__{methodName}__{relationName}__` (for e.g.


e.g. stand for for example (don't ask me why, probably something to do with latin). Right now this reads for for example

It is short for the Latin exempli gratia, “for the sake of example.”

👍

shimks · 2018-07-12T19:52:35Z

docs/site/Relations.md

+
+- [HasMany](HasMany-relation.md)
+
+The articles on each type of relation above will show you how to leverage the


Sure, but I think that readers shouldn't be expected to find an example of relation in general being used in the pages dedicated to each of the relations.

That being said, probably not a big deal

…ositoryFactory

b-admike · 2018-07-13T14:39:39Z

@shimks I've applied your feedback; LGTY now (we can revisit adding example to relation page later)?

b-admike requested review from bajtos and raymondfeng as code owners July 9, 2018 15:23

b-admike force-pushed the docs/relations branch from 153cc36 to 0bfbe33 Compare July 9, 2018 15:25

shimks reviewed Jul 9, 2018

View reviewed changes

b-admike force-pushed the docs/relations branch from 0bfbe33 to cd623a8 Compare July 9, 2018 17:30

dhmlau reviewed Jul 9, 2018

View reviewed changes

shimks reviewed Jul 9, 2018

View reviewed changes

jannyHou reviewed Jul 10, 2018

View reviewed changes

bajtos reviewed Jul 10, 2018

View reviewed changes

b-admike force-pushed the docs/relations branch from 8d800ae to a78de9a Compare July 10, 2018 20:58

dhmlau approved these changes Jul 11, 2018

View reviewed changes

b-admike force-pushed the docs/relations branch 4 times, most recently from aab3cbe to a9e258d Compare July 11, 2018 20:30

bajtos mentioned this pull request Jul 12, 2018

Add TodoList package/tutorial: Todo application with HasMany relation #1518

Merged

7 tasks

bajtos approved these changes Jul 12, 2018

View reviewed changes

bajtos changed the title ~~docs(repository): has many relation docs~~ docs(repository): describe HasMany relation Jul 12, 2018

bajtos reviewed Jul 12, 2018

View reviewed changes

jannyHou approved these changes Jul 12, 2018

View reviewed changes

b-admike force-pushed the docs/relations branch from 56082c8 to b64595e Compare July 12, 2018 14:57

shimks reviewed Jul 12, 2018

View reviewed changes

b-admike force-pushed the docs/relations branch 3 times, most recently from 06fa639 to 411d3a9 Compare July 12, 2018 19:40

shimks reviewed Jul 12, 2018

View reviewed changes

biniam added 3 commits July 13, 2018 10:34

refactor(repository): switch order of generic arguments of HasManyRep…

29bd7fb

…ositoryFactory

fix(repository): change RelationType from numeric to string enums

6816c0a

docs(repository): hasMany relation docs

aa81ff0

b-admike force-pushed the docs/relations branch from 411d3a9 to aa81ff0 Compare July 13, 2018 14:34

shimks approved these changes Jul 13, 2018

View reviewed changes

b-admike merged commit f3e3f3e into master Jul 13, 2018

b-admike deleted the docs/relations branch July 13, 2018 15:03

This comment has been minimized.

Sign in to view


		## Defining a HasMany Relation

		The first relation type we have available is the `hasMany` relation which


		{% include code-caption.html content="/src/models/customer.model.ts" %}

		```ts


		## Overview

		Model relation in LoopBack 3 is one of its powerful features which help users


		{% include code-caption.html
		content="src/controllers/customer-orders.controller.ts" %}


		## Defining a HasMany Relation

		To add a `HasMany` relation to your LoopBack application, you need to perform


		## Configuring a HasMany relation

		The configuration and resolution of a `HasMany` relation takes place at the


		- [HasMany](HasMany-relation.md)

		The articles on each type of relation above will show you how to leverage the

docs(repository): describe HasMany relation #1500

docs(repository): describe HasMany relation #1500

Conversation

b-admike commented Jul 9, 2018 • edited Loading

Checklist

shimks 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

b-admike commented Jul 9, 2018 • edited Loading

dhmlau 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

b-admike commented Jul 9, 2018 • edited Loading

jannyHou 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

bajtos 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

dhmlau 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

bajtos 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

b-admike commented Jul 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bajtos Jul 12, 2018 • edited Loading

Choose a reason for hiding this comment

jannyHou left a comment

Choose a reason for hiding this comment

shimks 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

b-admike commented Jul 9, 2018 •

edited

Loading

b-admike commented Jul 9, 2018 •

edited

Loading

b-admike commented Jul 9, 2018 •

edited

Loading

bajtos Jul 12, 2018 •

edited

Loading