feat: paging results for the Typescript SDK #698

jkaster · 2021-06-15T03:20:54Z

This PR is for the first version of the SDK response paging prototype.

This supports the "page at a time" retrieval.

The "row at a time while paged behind the scenes" iterator will come later.

See doc/paging.md for the documentation.

Very broken right now

WIP on `Paginator` and tests

Implemented for the TS SDK first - includes unit tests

packages/sdk-rtl/src/paginator.ts

jkaster · 2021-06-15T03:26:45Z

packages/sdk-rtl/src/paginator.ts

+      this.transport.observer = (response: IRawResponse) => {
+        raw = response
+        return response
+      }


this is the cleanest way I could come up with capturing the raw request values for processing the X-Total-Count and Link headers while still allowing the consumer to just make a call to an SDK function.

jkaster · 2021-06-15T03:29:55Z

packages/sdk-rtl/src/paginator.ts

+  get page(): number {
+    if (this.limit < 1 || this.offset < 0) return -1
+    const x = this.offset / this.limit + 1
+    return Math.ceil(x)
+  }
+
+  get pages(): number {
+    if (this.total < 1 || this.limit < 1) return -1
+    const x = this.total / this.limit
+    return Math.ceil(x)
+  }


readonly properties for reporting/UI purposes. A setPage(page, limit) function would be feasible to implement once we've got any result back because we can plug in the calculated values for limit and offset into the first rel link url. If total is known, we can also reject the request immediately if the page is beyond the number of available results.

jkaster · 2021-06-15T03:31:03Z

packages/sdk-rtl/src/paginator.ts

+  items: TSuccess = [] as unknown as TSuccess
+  links: PageLinks = {}
+  total = -1
+  offset = -1
+  limit = -1


I'll eventually make these read-only

jkaster · 2021-06-15T03:31:39Z

packages/sdk-rtl/src/transport.ts

 }

+export type RawObserver = (raw: IRawResponse) => IRawResponse


new hook required for all transports

github-actions · 2021-06-15T03:34:31Z

Typescript Tests

    4 files   73 suites 3m 2s ⏱️
157 tests 139 ✔️ 0 💤 18 ❌
481 runs 463 ✔️ 0 💤 18 ❌

For more details on these failures, see this check.

Results for commit 7fc8f3b.

bryans99

I don't see any issues with this aside from the use of new in the comment.

Having said that, I haven't tested and havent looked at the helltool side.

Basically, no issues identified thus far.

packages/sdk-rtl/src/paginator.ts

github-actions · 2021-06-15T22:21:03Z

Typescript Tests

    4 files   73 suites 3m 32s ⏱️
157 tests 139 ✔️ 0 💤 18 ❌
481 runs 463 ✔️ 0 💤 18 ❌

For more details on these failures, see this check.

Results for commit 9ae801c.

github-actions · 2021-06-15T22:40:05Z

Typescript Tests

    4 files   73 suites 3m 27s ⏱️
157 tests 139 ✔️ 0 💤 18 ❌
481 runs 463 ✔️ 0 💤 18 ❌

For more details on these failures, see this check.

Results for commit 56fe422.

things were broken after pagination refactoring. Now they're fixed and improved.

github-actions · 2021-06-16T04:02:41Z

Typescript Tests

    7 files   76 suites 3m 52s ⏱️
157 tests 157 ✔️ 0 💤 0 ❌
547 runs 547 ✔️ 0 💤 0 ❌

Results for commit 24aa480.

github-actions · 2021-06-28T16:33:50Z

Typescript Tests

0 files 0 suites 0s ⏱️
0 tests 0 ✔️ 0 💤 0 ❌

Results for commit a38b963.

github-actions · 2021-06-28T18:08:39Z

Typescript Tests

    7 files   76 suites 3m 46s ⏱️
159 tests 157 ✔️ 2 💤 0 ❌
555 runs 547 ✔️ 8 💤 0 ❌

Results for commit b608855.

github-actions · 2021-06-28T20:19:59Z

Typescript Tests

    7 files   76 suites 3m 26s ⏱️
159 tests 157 ✔️ 2 💤 0 ❌
555 runs 547 ✔️ 8 💤 0 ❌

Results for commit 8b16379.

github-actions · 2021-06-29T18:28:43Z

Typescript Tests

    7 files   76 suites 3m 32s ⏱️
159 tests 157 ✔️ 2 💤 0 ❌
555 runs 547 ✔️ 8 💤 0 ❌

Results for commit ec60987.

joeldodge79

I need more time with this but here are some random comments as I'm still grokking the code.

I need to spend more time understanding what you did with raw response parsing.

I also want to think more about the pager and pageAll interface - they just seem a little clunky because I need to pass in an sdk as well as a no-arg callback that calls an sdk.something(). I wonder if that can be simplified somehow?

I'll pick it back up first thing tomorrow

joeldodge79 · 2021-06-29T22:31:35Z

packages/sdk-rtl/src/paging.spec.ts

+const mockRawResponse = (url: string, body?: any): IRawResponse => {
+  const result = { ...mockedRawResponse, ...{ url: url } }
+  if (body) {
+    result.body = body
+  }
+  return result
+}


does this function exist only to override url and body of mockedRawResponse ? If so my brain works better with either of these alternatives:

s/mockRawResponse/customizeMockedRawResponse - I know you're not a fan of big ugly names but reading this code top to bottom it's clearer why you have both a module scope variable and a similarly named closure function that uses the module variable

put mockedRawResponse inside the mockRawResponse local scope and make the url parameter optional and always use that method to get a mocked raw response

I haven't made any changes to these unit tests. I was focusing on the functional tests instead once I had the PoC unit tests completed. There will certainly be another PR for SDK paging when the row-at-a-time iterator is added

made any changes to these unit tests

Let me know if I have this wrong - I think I'm hearing/seeing that given this PR is at least 15 days old you haven't made any changes recently to your initial PoC unittests on this branch? My perspective is that I'm reading this PR (sadly 15 days later: totally my bad!) as a complete and atomic unit of work ready to merge regardless of the eventually-to-be-deleted history of this branch.

Given that I was just reading this file top to bottom and came across a variable named mockedRawResponse and subsequently a closure named mockRawResponse that referenced mockedRawResponse and thought, "hm, why does it seem to be setup so that there are a couple different ways of getting a mock that looks like a response?" - reading the code below it seems like you use the latter when you need to override url/body and the former when you don't. I feel like a single way of getting a mocked response would be cleaner. Unless I've misread something and there's another reason (besides the url/body overrides).

I wrote the unit tests on spec while making the functional tests possible in Looker. The functional tests are what really matter more than the mocked unit tests. However, I did write the mocking override function after the initial unit tests that used the constant mocked value. They are working, and I was planning on updating the mocking when the row-at-a-time iterator has been implemented, which should have unit tests as well as functional tests.

It's a small change, so maybe I should do the reduction now instead. But it won't change the unit test logic in any way, really.

either way - I agree that it won't change the test logic, just giving my perspective as a reviewer that if I came in to read and modify this code later I'd trip for a second on why there's two. Up to you if you want to consolidate now or later or never :-)

joeldodge79 · 2021-06-29T22:43:03Z

packages/sdk-rtl/src/paging.ts

+  const obj: PageLinks = {}
+  let arrRes
+
+  links.forEach((link) => {


I know there's a lot of this callback style iteration in sdk-codegen but I sure do prefer the for (const link of links) {...} syntax: easier to reason about variable scope, and easier to step through with an interactive debugger imo. But since you're the primary TS contributor I'll defer to your preference :-)

I think I mentioned somewhere that row-at-a-time iteration will be in a subsequent PR. The generic iterator interface is complicated and taking too long to figure out for the link processing prototype that fulfills the page-at-a-time need right now.

my comment here wasn't about "row-at-a-time"/generic iterator - more just a mundane style comment about using Array.forEach vs (for const foo of Array) style syntax

Oh, I understand. In our internal codebase I think we use .forEach() more frequently unless it's an async block

got it, that's fine. I don't like it but I'll take it :-)

packages/sdk-rtl/src/paging.ts

joeldodge79 · 2021-06-29T22:49:54Z

packages/sdk-rtl/src/paging.spec.ts

+const lastLink = `< ${lastUrl} >; rel="\tlast (end of line!)\t"`
+const prevLink = `<\t${prevUrl}\n>;\nrel="prev"`


what's with the \ts and \ns and the (end of line!) ?

Checking pattern recognition variance tolerance.

that's what I figured but wanted to check.

Would you consider any of the following?

code comment here to that effect

larger code comment here, or above the describe('linkHeaderParser' line, or maybe even above the actual implementation showing the "common" string value of the Links header and potentially variants you want to account for (I think you have it in the readme - maybe also including examples with explicit \n or CRLF or \tchars)

docs/paging.md

joeldodge79 · 2021-06-29T23:42:57Z

packages/sdk-rtl/src/paging.ts

+    this.transport = sdk.authSession.transport as BaseTransport
+  }
+
+  private async rawCatch(func: () => any) {


maybe?

Suggested change

private async rawCatch(func: () => any) {

private async rawCatch(func: PagingFunc<TSuccess, TError>) {

rawRequest is generic and that constraint would be too strict.

joeldodge79 · 2021-06-29T23:45:30Z

packages/sdk-rtl/src/paging.ts

+      this.transport.observer = (response: IRawResponse) => {
+        raw = response
+        return response
+      }


feels like this should be before the try (doesn't seem like you'd expect any kind of exception just assigning a function to this.transport.observer. moving it out focuses the attention on the next line which is where things might go badly

I wonder if this class should maybe just build its own transport with the observer it wants instead of going through the hassle of saving, substituting, and restoring one?

The TypeScript pattern I've found (and used from before TypeScript) is to do resource assignments that will be closed/restored inside the try section, which IMO helps clarify that finally is intended to restore or close them. Happy to discuss further.

The only thing happening is the capture of the observer from whatever transport is used for resolving the initial SDK call (functional or monolithic). I think we need to capture the SDK function's transport and intercept the call rather than creating a different transport that may be completely missing some of the configuration of the SDK's transport object.

to do resource assignments that will be closed/restored inside the try section

then I'd argue that perhaps const saved = this.transport.observer belongs inside the try?

resolving the initial SDK call

ah, right - there's this asymmetry between the implementation of the initial call and subsequent nextPage()-and-friends calls. I feel like I want to think about that a little more.

possibly related is the asymmetry you see in my example code: I need to have an initial "get the items" block of code before I can launch into a while loop of retrieving the remaining items from subsequent pages if there are any. Maybe there's a smoother way to write that example? or maybe that will come with the "row-at-a-time"/generic iterator? just thinking out loud for our in-person chat on this

The problem with having to capture the first set of items outside the loop is that we won't have any Link header until we make the initiating request that causes paging. However, this means that we will also be sure to get the requested rows for any SDK method that does not include the paging headers. Having to init a stateful object for subsequent paging requests is a necessary evil.

Maybe there's a cleaner way to do it, but I haven't figured one out yet.

Reminds me we should make sure pageAll works with a non-paging sdk request, too. I'll add a functional test for that right now.

packages/sdk-rtl/src/paging.ts

joeldodge79 · 2021-06-29T23:59:25Z

packages/sdk-rtl/src/paging.ts

+  /**
+   * Create an API paginator
+   * @param sdk functional AuthSession or full SDK implementation
+   * @param func sdk function to call


I started to get lost - coming back to this comment header helped but I think I wouldn't have gotten lost if the param was named sdkFunc or sdkMethod

on that note, why do we need both sdk and func? it seems like the func is a first class object (not a string method name that you call on sdk) and that sdk only is used to access sdk.authSession.transport and sdk.authSession.authenticate. Perhaps the constructor should be changed to take a transport and an authenticate? or just an authSession?

how would a user of the functional sdk use this?

sdk needs to be a separate argument so we can capture the transport. We have no reliable way to capture the transport from the PagingFunc call. (Which already works for either functional or monolithic SDK calls.)

async function dashboardSearchResultsByPage(inTitle: string) { const sdk = new LookerSDK(session) return await pager(sdk, () => search_dashboards(sdk, {title: inTitle, limit: 2}) ) }

right, we need the transport and the authenticate ... I want to chat in person about this. I don't have a good answer but I'd love for the interface to be simpler if possible so as a consumer I could just do:

OO sdk:

const pagedDashboards = await pager(sdk.search_dashboards(...))

Functional sdk:

const pagedDashboards = await pager(search_dashboards(sdk, ...))

I understand that there are technical limitations given the current implementation you have but I'm wondering if there's a way we can get there?

What you show above is what I originally tried to do. I don't know a way to extract the values needed from an anonymous function call. Even if we figure out an introspection trick for Typescript, will other languages support something similar?

github-actions · 2021-06-30T02:16:55Z

Typescript Tests

    4 files   73 suites 1m 21s ⏱️
159 tests 157 ✔️ 0 💤 2 ❌
483 runs 481 ✔️ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit d37062f.

joeldodge79

A response to your response! Still haven't reviewed your changes to node/browserTransport but getting a better idea of what I want to discuss in person (in the interface and asymmetry between initial sdk call and subsequent paging calls).

Also, I was getting tired last night and forgot to include this in my initial review: Great work John! 🥇 📟

joeldodge79 · 2021-06-30T14:10:21Z

packages/sdk-rtl/src/paging.ts

+  const obj: PageLinks = {}
+  let arrRes
+
+  links.forEach((link) => {


my comment here wasn't about "row-at-a-time"/generic iterator - more just a mundane style comment about using Array.forEach vs (for const foo of Array) style syntax

joeldodge79 · 2021-06-30T14:20:42Z

packages/sdk-rtl/src/paging.spec.ts

+const mockRawResponse = (url: string, body?: any): IRawResponse => {
+  const result = { ...mockedRawResponse, ...{ url: url } }
+  if (body) {
+    result.body = body
+  }
+  return result
+}


made any changes to these unit tests

Let me know if I have this wrong - I think I'm hearing/seeing that given this PR is at least 15 days old you haven't made any changes recently to your initial PoC unittests on this branch? My perspective is that I'm reading this PR (sadly 15 days later: totally my bad!) as a complete and atomic unit of work ready to merge regardless of the eventually-to-be-deleted history of this branch.

Given that I was just reading this file top to bottom and came across a variable named mockedRawResponse and subsequently a closure named mockRawResponse that referenced mockedRawResponse and thought, "hm, why does it seem to be setup so that there are a couple different ways of getting a mock that looks like a response?" - reading the code below it seems like you use the latter when you need to override url/body and the former when you don't. I feel like a single way of getting a mocked response would be cleaner. Unless I've misread something and there's another reason (besides the url/body overrides).

docs/paging.md

joeldodge79 · 2021-06-30T14:29:36Z

packages/sdk-rtl/src/paging.spec.ts

+const lastLink = `< ${lastUrl} >; rel="\tlast (end of line!)\t"`
+const prevLink = `<\t${prevUrl}\n>;\nrel="prev"`


that's what I figured but wanted to check.

Would you consider any of the following?

code comment here to that effect

larger code comment here, or above the describe('linkHeaderParser' line, or maybe even above the actual implementation showing the "common" string value of the Links header and potentially variants you want to account for (I think you have it in the readme - maybe also including examples with explicit \n or CRLF or \tchars)

packages/sdk-rtl/src/paging.ts

joeldodge79 · 2021-06-30T14:36:43Z

packages/sdk-rtl/src/paging.ts

+  /**
+   * Create an API paginator
+   * @param sdk functional AuthSession or full SDK implementation
+   * @param func sdk function to call


right, we need the transport and the authenticate ... I want to chat in person about this. I don't have a good answer but I'd love for the interface to be simpler if possible so as a consumer I could just do:

OO sdk:

const pagedDashboards = await pager(sdk.search_dashboards(...))

Functional sdk:

const pagedDashboards = await pager(search_dashboards(sdk, ...))

I understand that there are technical limitations given the current implementation you have but I'm wondering if there's a way we can get there?

joeldodge79 · 2021-06-30T14:44:38Z

packages/sdk-rtl/src/paging.ts

+      this.transport.observer = (response: IRawResponse) => {
+        raw = response
+        return response
+      }


to do resource assignments that will be closed/restored inside the try section

then I'd argue that perhaps const saved = this.transport.observer belongs inside the try?

resolving the initial SDK call

ah, right - there's this asymmetry between the implementation of the initial call and subsequent nextPage()-and-friends calls. I feel like I want to think about that a little more.

possibly related is the asymmetry you see in my example code: I need to have an initial "get the items" block of code before I can launch into a while loop of retrieving the remaining items from subsequent pages if there are any. Maybe there's a smoother way to write that example? or maybe that will come with the "row-at-a-time"/generic iterator? just thinking out loud for our in-person chat on this

Also added functional test to verify pageAll works with non-paging endpoints

github-actions · 2021-06-30T17:09:56Z

Typescript Tests

    4 files   73 suites 1m 29s ⏱️
160 tests 158 ✔️ 0 💤 2 ❌
484 runs 482 ✔️ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit ca6618a.

joeldodge79

some more questions for ya. I think I'm done now till we meet

joeldodge79 · 2021-06-30T16:36:49Z

docs/paging.md

+  )
+}
+
+const pagedDashboards = await dashboardSearchResultsByPage('JOEL')


you stinker

joeldodge79 · 2021-06-30T16:39:34Z

docs/paging.md

+For the functional SDK, the syntax is almost identical (the imports will vary). The search function can be changed to:
+
+```ts
+// Functional SDK search function


not actually sure on the syntax here but something like this might make it more clear what you mean by "Functional SDK" w/out sending the reader elsewhere to do research.

Suggested change

// Functional SDK search function

// Functional SDK search function

import {Looker40SDK, search_dashboards} from '@looker/sdk'

joeldodge79 · 2021-06-30T16:48:48Z

packages/sdk-rtl/src/paging.spec.ts

+const mockRawResponse = (url: string, body?: any): IRawResponse => {
+  const result = { ...mockedRawResponse, ...{ url: url } }
+  if (body) {
+    result.body = body
+  }
+  return result
+}


either way - I agree that it won't change the test logic, just giving my perspective as a reviewer that if I came in to read and modify this code later I'd trip for a second on why there's two. Up to you if you want to consolidate now or later or never :-)

joeldodge79 · 2021-06-30T16:54:35Z

packages/sdk-node/src/nodeTransport.ts

+    return this.observer ? this.observer(rawResponse) : rawResponse
+  }
+
+  async parseResponse<TSuccess, TError>(res: IRawResponse) {


it looks like you moved this function from above to below and changed it? It's hard to tell what changed - blurring my eye's I can tell it's a bit longer but can you give me an overview of how/why parseResponse changed?

joeldodge79 · 2021-06-30T17:09:29Z

packages/sdk-rtl/src/paging.ts

+  const obj: PageLinks = {}
+  let arrRes
+
+  links.forEach((link) => {


got it, that's fine. I don't like it but I'll take it :-)

joeldodge79 · 2021-06-30T17:17:07Z

packages/hackathon/src/authToken/extensionProxyTransport.ts

+    }
+    return Promise.resolve(result)
+  }
+
  async rawRequest(


why doesn't this class use the RawObserver hook?

github-actions · 2021-06-30T17:33:25Z

Typescript Tests

    7 files   76 suites 3m 40s ⏱️
160 tests 157 ✔️   3 💤 0 ❌
559 runs 547 ✔️ 12 💤 0 ❌

Results for commit 2a84405.

joeldodge79

looks good. let's ship this and then I'll muddle around with the python version and see if I can convince you about tweaking the pager signature.

nice work and thanks for your patience

jkaster added 6 commits May 20, 2021 01:02

WIP TS SDK pagination implementation

06de862

Very broken right now

Merge branch 'main' into jk/pagination

f399f10

linkHeaderParser() works

062309a

WIP on `Paginator` and tests

feat: paged SDK results via Link header

a51e9ca

Implemented for the TS SDK first - includes unit tests

corrected comment example

d1da812

improved paging function names, added comments

7fc8f3b

jkaster added the enhancement New feature request label Jun 15, 2021

jkaster requested review from bryans99, joeldodge79, josephaxisa, a user and noahamac June 15, 2021 03:20

google-cla bot added the cla: yes label Jun 15, 2021

jkaster marked this pull request as draft June 15, 2021 03:21

jkaster commented Jun 15, 2021

View reviewed changes

packages/sdk-rtl/src/paginator.ts Outdated Show resolved Hide resolved

jkaster commented Jun 15, 2021

View reviewed changes

bryans99 reviewed Jun 15, 2021

View reviewed changes

packages/sdk-rtl/src/paginator.ts Outdated Show resolved Hide resolved

Added pagination.md and cleaned up some code

9ae801c

doc tweak

56fe422

improved node transport error handling

24aa480

things were broken after pagination refactoring. Now they're fixed and improved.

jkaster added 2 commits June 17, 2021 16:49

Merge remote-tracking branch 'origin/main' into jk/pagination

e2abd40

Merge branch 'main' into jk/pagination

129e3bb

Skip pagination tests until headers are available

b608855

Merge branch 'main' into jk/pagination

8b16379

jkaster added 2 commits June 29, 2021 18:15

Change "pagination" to "paging"

f12337e

Merge remote-tracking branch 'origin/jk/pagination' into jk/pagination

ec60987

jkaster changed the title ~~feat: pagination for the Typescript SDK~~ feat: paging results for the Typescript SDK Jun 29, 2021

joeldodge79 suggested changes Jun 30, 2021

View reviewed changes

jkaster added 2 commits June 30, 2021 00:41

Merge remote-tracking branch 'origin/main' into jk/pagination

5035439

Address PR feedback

d37062f

jkaster requested a review from joeldodge79 June 30, 2021 02:10

joeldodge79 reviewed Jun 30, 2021

View reviewed changes

PR feedback for unit test clarifications

ca6618a

Also added functional test to verify pageAll works with non-paging endpoints

Skip functional tests relying on unreleased features

2a84405

joeldodge79 reviewed Jun 30, 2021

View reviewed changes

ghost removed their request for review June 30, 2021 18:12

joeldodge79 self-requested a review June 30, 2021 18:34

joeldodge79 approved these changes Jun 30, 2021

View reviewed changes

jkaster merged commit 537eb57 into main Jun 30, 2021

jkaster deleted the jk/pagination branch June 30, 2021 18:40

This comment has been minimized.

Sign in to view

		}

		export type RawObserver = (raw: IRawResponse) => IRawResponse

		const lastLink = `< ${lastUrl} >; rel="\tlast (end of line!)\t"`
		const prevLink = `<\t${prevUrl}\n>;\nrel="prev"`

	private async rawCatch(func: () => any) {
	private async rawCatch(func: PagingFunc<TSuccess, TError>) {

	// Functional SDK search function
	// Functional SDK search function
	import {Looker40SDK, search_dashboards} from '@looker/sdk'

feat: paging results for the Typescript SDK #698

feat: paging results for the Typescript SDK #698

Conversation

jkaster commented Jun 15, 2021 • 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

github-actions bot commented Jun 15, 2021

Typescript Tests

bryans99 left a comment

Choose a reason for hiding this comment

github-actions bot commented Jun 15, 2021

Typescript Tests

github-actions bot commented Jun 15, 2021

Typescript Tests

github-actions bot commented Jun 16, 2021

Typescript Tests

github-actions bot commented Jun 28, 2021

Typescript Tests

github-actions bot commented Jun 28, 2021

Typescript Tests

github-actions bot commented Jun 28, 2021

Typescript Tests

github-actions bot commented Jun 29, 2021

Typescript Tests

joeldodge79 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

github-actions bot commented Jun 30, 2021

Typescript Tests

joeldodge79 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

github-actions bot commented Jun 30, 2021

Typescript Tests

joeldodge79 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

github-actions bot commented Jun 30, 2021

Typescript Tests

joeldodge79 left a comment

Choose a reason for hiding this comment

This comment has been minimized.

jkaster commented Jun 15, 2021 •

edited

Loading