Support providing examples for custom types #73

nikicc · 2022-02-07T17:21:05Z

Fixes #72.

codecov · 2022-02-07T17:24:00Z

Codecov Report

Merging #73 (10fdc74) into master (ad0868d) will decrease coverage by 0.18%.
The diff coverage is 60.00%.

❗ Current head 10fdc74 differs from pull request most recent head 815e4ae. Consider uploading reports for the commit 815e4ae to get more accurate results

@@            Coverage Diff             @@
##           master      #73      +/-   ##
==========================================
- Coverage   95.19%   95.01%   -0.19%     
==========================================
  Files           7        7              
  Lines         957      962       +5     
==========================================
+ Hits          911      914       +3     
- Misses         30       32       +2     
  Partials       16       16

Impacted Files	Coverage Δ
openapi/types.go	`100.00% <ø> (ø)`
openapi/generator.go	`94.00% <60.00%> (-0.27%)`	⬇️

Continue to review full report at Codecov.

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

wI2L · 2022-02-07T17:24:00Z

openapi/generator.go

@@ -1235,6 +1235,10 @@ func fieldNameFromTag(sf reflect.StructField, tagName string) string {
 	return name
 }

+type OpenAPIExample interface {


Just thought that this interface might be expanded in the future for others features. Perhaps we should take that opportunity to rename it CustomType, or something else (if you have a better idead, please share) and aggregate all methods within it.

Also, exported type needs a comment.

Agreed; CustomType seems more general and easier to use for other stuff later if needed.

Added a comment & renamed to CustomType

wI2L · 2022-02-07T17:27:23Z

openapi/generator.go

@@ -1276,6 +1280,13 @@ func parseExampleValue(t reflect.Type, value string) (interface{}, error) {
 		return strconv.ParseFloat(value, t.Bits())
 	case reflect.Ptr:
 		return parseExampleValue(t.Elem(), value)
+	case reflect.Struct:
+		// we only support structs that implement OpenAPIExample interface
+		casted, ok := reflect.New(t).Interface().(OpenAPIExample)


wI2L · 2022-02-07T17:28:17Z

README.md

+To be able to provide examples for structs, they must implement the following interface:
+```go
+type OpenAPIExample interface {
+	ParseExample(v string) interface{}


The method should be able to return an error.

Good point. Added an error now.

wI2L · 2022-02-07T17:28:54Z

openapi/generator.go

+		// we only support structs that implement OpenAPIExample interface
+		casted, ok := reflect.New(t).Interface().(OpenAPIExample)
+		if ok {
+			return casted.ParseExample(value), nil


return i.ParseExample(value)
We should return the error returned by the implem.

wI2L · 2022-02-07T17:30:22Z

openapi/generator.go

+		if ok {
+			return casted.ParseExample(value), nil
+		}
+		return nil, fmt.Errorf("  structs (type %s) that do not implement OpenAPIExample are not supported", t.String())


I suggest: "type %s doesn not implement {interface name}"

wI2L · 2022-02-07T17:31:47Z

openapi/generator_test.go

@@ -733,6 +734,13 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type CustomUnit struct {


Could you add a test for a known case, such as your time.Time ?

Happy to. Added.

wI2L · 2022-02-07T17:32:43Z

openapi/generator_test.go

@@ -733,6 +734,13 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type CustomUnit struct {


Doesn't need to be exported: s/CustomUnit/customUnit

Changed for both the existing type and the one I just aded for time.Time.

wI2L · 2022-02-07T17:34:06Z

Thanks for the PR.
I added a few comments to ammend some parts of the implementation proposal that I wrote in the issue after thinking about it properly.

nikicc

@wI2L pushed the fixes. Ready for another pass 👀

nikicc · 2022-02-07T17:37:34Z

README.md

+To be able to provide examples for structs, they must implement the following interface:
+```go
+type OpenAPIExample interface {
+	ParseExample(v string) interface{}


Good point. Added an error now.

nikicc · 2022-02-07T17:39:47Z

openapi/generator.go

@@ -1235,6 +1235,10 @@ func fieldNameFromTag(sf reflect.StructField, tagName string) string {
 	return name
 }

+type OpenAPIExample interface {


Agreed; CustomType seems more general and easier to use for other stuff later if needed.

Added a comment & renamed to CustomType

nikicc · 2022-02-07T17:42:45Z

openapi/generator.go

@@ -1276,6 +1280,13 @@ func parseExampleValue(t reflect.Type, value string) (interface{}, error) {
 		return strconv.ParseFloat(value, t.Bits())
 	case reflect.Ptr:
 		return parseExampleValue(t.Elem(), value)
+	case reflect.Struct:
+		// we only support structs that implement OpenAPIExample interface
+		casted, ok := reflect.New(t).Interface().(OpenAPIExample)


nikicc · 2022-02-07T17:43:19Z

openapi/generator.go

+		// we only support structs that implement OpenAPIExample interface
+		casted, ok := reflect.New(t).Interface().(OpenAPIExample)
+		if ok {
+			return casted.ParseExample(value), nil


nikicc · 2022-02-07T17:43:58Z

openapi/generator.go

+		if ok {
+			return casted.ParseExample(value), nil
+		}
+		return nil, fmt.Errorf("  structs (type %s) that do not implement OpenAPIExample are not supported", t.String())


nikicc · 2022-02-07T17:50:44Z

openapi/generator_test.go

@@ -733,6 +734,13 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type CustomUnit struct {


Happy to. Added.

nikicc · 2022-02-07T17:51:38Z

openapi/generator_test.go

@@ -733,6 +734,13 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type CustomUnit struct {


Changed for both the existing type and the one I just aded for time.Time.

wI2L · 2022-02-08T14:59:17Z

openapi/generator.go

-type OpenAPIExample interface {
-	ParseExample(v string) interface{}
+// CustomType describes the interface of custom types that can be used in JSON responses.
+type CustomType interface {


Could you move it to fizz/openapi/types.go, with the other types-related interfaces?

Actually, I think I'm reconsidering my proposal to name that interface CustomType.
We already have two interfaces Type and DataType that are implemented by custom types.

Ideally, this should be one single interface CustomType. Perhaps for a v1.0.

In the meantime, I think we should keep a seperate interface, Exampler (the name sucks a bit, but we usually end interface name with "er". If you have a better name in mind, don't hesitate).

Moved to fizz/openapi/types.go.

In the meantime, I think we should keep a seperate interface, Exampler (the name sucks a bit, but we usually end interface name with "er".

Renamed to Exampler.

Ideally, this should be one single interface CustomType. Perhaps for a v1.0.

One argument for keeping these separate interfaces separate might be that it's easier to fulfil the interfaces if they are separate (e.g. if I only want to provide examples, currently I only need to implement the ParseExample method, while with one bigger interface I'd need to implement all the methods).

Yes, you have a valid point.

wI2L · 2022-02-08T15:04:07Z

openapi/generator_test.go

+	if err != nil {
+		return nil, err
+	}
+	return t1.Format("2006-01-02T15:04:05"), nil


I think, for the sake of the example, the return should be t1, and the type should implement a String() and/or MarshalJson methods. The goal is to return the concrete type, and leave the marshaling to the implementation.

Hmm, not sure. If we refactor, then we would need something like this:

type customTime struct { time.Time } func (c customTime) String() string { return c.Format("2006-01-02T15:04:05") } func (c customTime) ParseExample(v string) (interface{}, error) { t1, err := time.Parse(time.RFC3339, v) if err != nil { return nil, err } return customTime{t1}, nil }

but then we can't test is as nicely in TestGenerator_parseExampleValue as the returned value is an object, not a string representation formatted in the the format we like. WDYT?

Yes, that's what I thought of in term of implem.
The marshaling/string representation of the custom type can be tested by comparing the output spec, and if we want to add a test of the type-specific ParseExample method, we just need to ensure that the returned value has the proper type.

Refactored now.

wI2L · 2022-02-08T15:05:03Z

openapi/generator_test.go

 			"15",
 			"15 USD",
 		},
 		{
-			"mapping pointers to custom structs",
-			reflect.PtrTo(reflect.TypeOf(CustomUnit{})),
+			"mapping pointers to customUnit",


s/pointers/pointer

wI2L · 2022-02-08T15:05:08Z

openapi/generator_test.go

+			"2022-02-07T18:00:00",
+		},
+		{
+			"mapping pointers to customTime",


s/pointers/pointer

wI2L · 2022-02-08T15:05:22Z

openapi/generator_test.go

@@ -882,17 +892,29 @@ func TestGenerator_parseExampleValue(t *testing.T) {
 			true,
 		},
 		{
-			"mapping custom structs",
-			reflect.TypeOf(CustomUnit{}),
+			"mapping customUnit",


s/mapping/mapping to

wI2L · 2022-02-08T15:05:30Z

openapi/generator_test.go

 			"20.00",
 			"20.00 USD",
 		},
+		{
+			"mapping customTime",


s/mapping/mapping to

wI2L · 2022-02-08T15:16:31Z

README.md

@@ -231,8 +231,8 @@ You can use additional tags. Some will be interpreted by *tonic*, others will be
 ### Providing Examples for Structs


Let's move it under the https://github.com/wI2L/fizz#openapi-specification section, wwhile keeping an anchor link from the "Additional tags" table.

nikicc

@wI2L pushed some more fixes. Let me know what you think.

I think I addressed everything, but the test about the example for time. I think in the current format it's easier to tests so might be in favour of keeping what we have.

nikicc · 2022-02-08T16:12:02Z

README.md

@@ -231,8 +231,8 @@ You can use additional tags. Some will be interpreted by *tonic*, others will be
 ### Providing Examples for Structs


nikicc · 2022-02-08T16:13:45Z

openapi/generator.go

-type OpenAPIExample interface {
-	ParseExample(v string) interface{}
+// CustomType describes the interface of custom types that can be used in JSON responses.
+type CustomType interface {


Moved to fizz/openapi/types.go.

nikicc · 2022-02-08T16:14:29Z

openapi/generator.go

-type OpenAPIExample interface {
-	ParseExample(v string) interface{}
+// CustomType describes the interface of custom types that can be used in JSON responses.
+type CustomType interface {


In the meantime, I think we should keep a seperate interface, Exampler (the name sucks a bit, but we usually end interface name with "er".

Renamed to Exampler.

nikicc · 2022-02-08T16:22:30Z

openapi/generator.go

-type OpenAPIExample interface {
-	ParseExample(v string) interface{}
+// CustomType describes the interface of custom types that can be used in JSON responses.
+type CustomType interface {


Ideally, this should be one single interface CustomType. Perhaps for a v1.0.

One argument for keeping these separate interfaces separate might be that it's easier to fulfil the interfaces if they are separate (e.g. if I only want to provide examples, currently I only need to implement the ParseExample method, while with one bigger interface I'd need to implement all the methods).

nikicc · 2022-02-08T16:25:08Z

openapi/generator_test.go

@@ -882,17 +892,29 @@ func TestGenerator_parseExampleValue(t *testing.T) {
 			true,
 		},
 		{
-			"mapping custom structs",
-			reflect.TypeOf(CustomUnit{}),
+			"mapping customUnit",


nikicc · 2022-02-08T16:25:26Z

openapi/generator_test.go

 			"15",
 			"15 USD",
 		},
 		{
-			"mapping pointers to custom structs",
-			reflect.PtrTo(reflect.TypeOf(CustomUnit{})),
+			"mapping pointers to customUnit",


nikicc · 2022-02-08T16:25:44Z

openapi/generator_test.go

 			"20.00",
 			"20.00 USD",
 		},
+		{
+			"mapping customTime",


nikicc · 2022-02-08T16:25:56Z

openapi/generator_test.go

+			"2022-02-07T18:00:00",
+		},
+		{
+			"mapping pointers to customTime",


nikicc · 2022-02-08T17:30:17Z

openapi/generator_test.go

+	if err != nil {
+		return nil, err
+	}
+	return t1.Format("2006-01-02T15:04:05"), nil


Hmm, not sure. If we refactor, then we would need something like this:

type customTime struct { time.Time } func (c customTime) String() string { return c.Format("2006-01-02T15:04:05") } func (c customTime) ParseExample(v string) (interface{}, error) { t1, err := time.Parse(time.RFC3339, v) if err != nil { return nil, err } return customTime{t1}, nil }

but then we can't test is as nicely in TestGenerator_parseExampleValue as the returned value is an object, not a string representation formatted in the the format we like. WDYT?

nikicc

@wI2L pushed the updated version of a test. WDYT?

wI2L · 2022-02-10T11:35:42Z

openapi/generator_test.go

@@ -741,14 +741,20 @@ func (c customUnit) ParseExample(v string) (interface{}, error) {
 	return fmt.Sprintf("%s USD", v), nil
 }

-type customTime time.Time
+type customTime struct {


This can stay as type customTime time.Time, casting it to customTime with customTime{t1} should work.

Yeah this works. But the String method then needs an extra cast (as c.Format does not work):

func (c customTime) String() string { return time.Time(c).Format("2006-01-02T15:04:05") }

Honestly the String method is an imlem detail, it's not even necessary for the sake of the tests.
Speaking of tests, I noticed that we don't test a custom type marshaling to JSON in the final spec. This would be nice to add as well, and perhaps a mention in the README that custom types MUST implement the json.Marshaler interface.

Ohhh, I see what you mean. We had a bit different ideas on how this should work. My initial ideas was that the ParseExample would already return the example value that can go into JSON on YAML directly (hence I also wrote some of the initial tests that way). That would be a formatted string in this case.

The way you are thinking about this is slightly different: ParseExample returns a struct and then struct gets transformed into the final JSON or YAML representation through MarshalJSON() and MarshalYAML() methods, right?

Let me refactor the tests and add a note into the README.md.

ParseExample returns a struct

Not specifically a struct, it returns a value which type is customTime (in this case), but that could be any concrete type, and yes the marshaling to JSON is implemented on that type.

That may seems counter-productive to not just return a string direclty that would be used in the final JSON of the spec, but what if the custom type has a int kind for example. In this case, we most certainly would'nt want to marshal that custom type as a JSON string but as a JSON interger, most likely. Returning a concrete type from ParseExemple and leaving the marshaling implem to the implem allows this while leaving full responsibility/flexibility to the implementation.

Yes, I agree this is better.

Almost there with the test, going to push shortly.

wI2L · 2022-02-10T11:37:12Z

@nikicc One more comment, and we should be done.
Could you please squash the commits into a single one? I'll merge ASAP and release in stride.

nikicc · 2022-02-10T11:49:17Z

Could you please squash the commits into a single one?

Squashed & pushed now.

I'll merge ASAP and release in stride.

Thanks!

wI2L · 2022-02-10T14:01:17Z

README.md

@@ -344,6 +344,16 @@ Note that, according to the doc, the inherent version of the address is a semant

 To help you write markdown descriptions in Go, a simple builder is available in the sub-package `markdown`. This is quite handy to avoid conflicts with backticks that are both used in Go for litteral multi-lines strings and code blocks in markdown.

+#### Providing Examples for Structs


"for Structs" should be replaced by "custom types". They don't necesseraly have a Struct kind.

Agreed. Fixed.

wI2L · 2022-02-10T14:01:30Z

README.md

@@ -223,7 +223,7 @@ You can use additional tags. Some will be interpreted by *tonic*, others will be
 | `description` | Add a description of the field in the spec.                                                                                                                                                                                                                                           |
 | `deprecated`  | Indicates if the field is deprecated. Accepted values are `1`, `t`, `T`, `TRUE`, `true`, `True`, `0`, `f`, `F`, `FALSE`. Invalid value are considered to be false.                                                                                                                    |
 | `enum`        | A coma separated list of acceptable values for the parameter.                                                                                                                                                                                                                         |
-| `example`     | An example value to be used in OpenAPI specification.                                                                                                                                                                                                                                 |
+| `example`     | An example value to be used in OpenAPI specification. See [section below](#Providing-Examples-for-Structs) for the demonstration on how to provide example for struct types.                                                                                                                                                                                                                                |


"for custom types" as well

wI2L · 2022-02-10T14:06:04Z

openapi/generator.go

@@ -1276,6 +1276,13 @@ func parseExampleValue(t reflect.Type, value string) (interface{}, error) {
 		return strconv.ParseFloat(value, t.Bits())
 	case reflect.Ptr:
 		return parseExampleValue(t.Elem(), value)
+	case reflect.Struct:


Wondering again, since we now provide an interface, we should not restrict it to Struct kind. Instead, we should honor the ParseExemple method of every type that implement the Exampler and call it to get the example value.

For types with a Struct kind, we would default to a call to the ParseExample method, if its implemented, otherwise return an empty string to signal that there is no example.

For others kinds, we would continue with the existing switch cases.

Wondering again, since we now provide an interface, we should not restrict it to Struct kind. Instead, we should honor the ParseExemple method of every type that implement the Exampler and call it to get the example value.

Fixed.

For types with a Struct kind, we would default to a call to the ParseExample method, if its implemented, otherwise return an empty string to signal that there is no example.

Hmm, I'm not a fan of an empty string. I think it's better if we return the error (like we currently do). If someone provided an example tag on a struct field, and the struct does not implement Exampler I think an error is more appropriate than defaulting to empty string. WDYT?

Alright. The error doen't stop the spec generation anyway, so it's fine.

wI2L · 2022-02-10T14:08:45Z

openapi/generator_test.go

@@ -733,6 +734,27 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type customUnit struct {


I'd like to switch this custom type to an int or float64, to demonstrate and test that scalar go types that implement the Exampler interface can also provide their own example value.

The type could still be a struct, if we wanted to have a more complex type, such as:

type customUnit struct { value float64 currenty string }

but that would be overkill for just tests, i'm just showcasing the possibility.

Switched to float64.

but that would be overkill for just tests, i'm just showcasing the possibility.

Yes. I think it's better to use float64 to demonstrate that this also works for non-structs.

wI2L · 2022-02-10T14:11:05Z

openapi/types.go

@@ -42,6 +42,12 @@ type DataType interface {
 	Format() string
 }

+// Exampler is the interface implemented by types


wdyt of "Exampler is the interface implemented by custom types that can parse example values." ?

Sounds nice. Changed.

nikicc

@wI2L I addressed the latests comments but pushed in separate commits to ease the reviewing. Once we're happy with the implementation, I'll squash again. Let me know what you think.

nikicc · 2022-02-10T15:24:07Z

README.md

@@ -223,7 +223,7 @@ You can use additional tags. Some will be interpreted by *tonic*, others will be
 | `description` | Add a description of the field in the spec.                                                                                                                                                                                                                                           |
 | `deprecated`  | Indicates if the field is deprecated. Accepted values are `1`, `t`, `T`, `TRUE`, `true`, `True`, `0`, `f`, `F`, `FALSE`. Invalid value are considered to be false.                                                                                                                    |
 | `enum`        | A coma separated list of acceptable values for the parameter.                                                                                                                                                                                                                         |
-| `example`     | An example value to be used in OpenAPI specification.                                                                                                                                                                                                                                 |
+| `example`     | An example value to be used in OpenAPI specification. See [section below](#Providing-Examples-for-Structs) for the demonstration on how to provide example for struct types.                                                                                                                                                                                                                                |


nikicc · 2022-02-10T15:24:23Z

README.md

@@ -344,6 +344,16 @@ Note that, according to the doc, the inherent version of the address is a semant

 To help you write markdown descriptions in Go, a simple builder is available in the sub-package `markdown`. This is quite handy to avoid conflicts with backticks that are both used in Go for litteral multi-lines strings and code blocks in markdown.

+#### Providing Examples for Structs


Agreed. Fixed.

nikicc · 2022-02-10T15:25:21Z

openapi/types.go

@@ -42,6 +42,12 @@ type DataType interface {
 	Format() string
 }

+// Exampler is the interface implemented by types


Sounds nice. Changed.

nikicc · 2022-02-10T15:47:40Z

openapi/generator_test.go

@@ -733,6 +734,27 @@ func TestSetServers(t *testing.T) {
 	assert.Equal(t, servers, g.API().Servers)
 }

+type customUnit struct {


Switched to float64.

but that would be overkill for just tests, i'm just showcasing the possibility.

Yes. I think it's better to use float64 to demonstrate that this also works for non-structs.

nikicc · 2022-02-10T15:50:13Z

openapi/generator.go

@@ -1276,6 +1276,13 @@ func parseExampleValue(t reflect.Type, value string) (interface{}, error) {
 		return strconv.ParseFloat(value, t.Bits())
 	case reflect.Ptr:
 		return parseExampleValue(t.Elem(), value)
+	case reflect.Struct:


Wondering again, since we now provide an interface, we should not restrict it to Struct kind. Instead, we should honor the ParseExemple method of every type that implement the Exampler and call it to get the example value.

Fixed.

For types with a Struct kind, we would default to a call to the ParseExample method, if its implemented, otherwise return an empty string to signal that there is no example.

Hmm, I'm not a fan of an empty string. I think it's better if we return the error (like we currently do). If someone provided an example tag on a struct field, and the struct does not implement Exampler I think an error is more appropriate than defaulting to empty string. WDYT?

wI2L · 2022-02-11T09:37:20Z

@nikicc LGTM, you can squash again.

nikicc

@nikicc LGTM, you can squash again.

@wI2L squashed & pushed. Thanks for all the detailed & prompt reviews!

wI2L

@nikicc Thanks for the PR.

nikicc force-pushed the support-custom-type-examples branch 2 times, most recently from 7080bcb to ba321bc Compare February 7, 2022 17:23

wI2L requested changes Feb 7, 2022

View reviewed changes

nikicc commented Feb 7, 2022

View reviewed changes

nikicc marked this pull request as ready for review February 7, 2022 19:29

nikicc requested a review from wI2L February 8, 2022 08:58

wI2L requested changes Feb 8, 2022

View reviewed changes

nikicc commented Feb 8, 2022

View reviewed changes

nikicc requested a review from wI2L February 8, 2022 17:46

nikicc commented Feb 10, 2022

View reviewed changes

wI2L reviewed Feb 10, 2022

View reviewed changes

nikicc force-pushed the support-custom-type-examples branch from 947919a to e602795 Compare February 10, 2022 11:48

nikicc force-pushed the support-custom-type-examples branch from e602795 to 479114f Compare February 10, 2022 11:50

wI2L reviewed Feb 10, 2022

View reviewed changes

nikicc commented Feb 10, 2022

View reviewed changes

nikicc requested a review from wI2L February 10, 2022 15:54

nikicc force-pushed the support-custom-type-examples branch from 10fdc74 to 0b5d99a Compare February 11, 2022 10:00

nikicc commented Feb 11, 2022

View reviewed changes

Support providing examples for custom types

815e4ae

nikicc force-pushed the support-custom-type-examples branch from 0b5d99a to 815e4ae Compare February 11, 2022 10:02

nikicc changed the title ~~Support providing examples for custom structs~~ Support providing examples for custom types Feb 11, 2022

wI2L approved these changes Feb 11, 2022

View reviewed changes

wI2L merged commit eb08933 into wI2L:master Feb 11, 2022

nikicc deleted the support-custom-type-examples branch February 11, 2022 11:28

nikicc restored the support-custom-type-examples branch February 11, 2022 11:28

nikicc deleted the support-custom-type-examples branch February 11, 2022 11:29

		@@ -231,8 +231,8 @@ You can use additional tags. Some will be interpreted by tonic, others will be
		### Providing Examples for Structs

		@@ -344,6 +344,16 @@ Note that, according to the doc, the inherent version of the address is a semant

		To help you write markdown descriptions in Go, a simple builder is available in the sub-package `markdown`. This is quite handy to avoid conflicts with backticks that are both used in Go for litteral multi-lines strings and code blocks in markdown.

		#### Providing Examples for Structs

Support providing examples for custom types #73

Support providing examples for custom types #73

Conversation

nikicc commented Feb 7, 2022

codecov bot commented Feb 7, 2022 • edited Loading

Codecov Report

wI2L Feb 7, 2022 • 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

wI2L commented Feb 7, 2022

nikicc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

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

nikicc 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

nikicc 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

wI2L Feb 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wI2L commented Feb 10, 2022

nikicc commented Feb 10, 2022

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

codecov bot commented Feb 7, 2022 •

edited

Loading

wI2L Feb 7, 2022 •

edited

Loading

wI2L Feb 10, 2022 •

edited

Loading

wI2L Feb 10, 2022 •

edited

Loading