[Update][Ease of Use] TypeScript Client Update

[atroyn]

TypeScript Client Update

Chroma's first-party TypeScript client is not very idiomatic / nice to use out of the box with TypeScript projects. The documentation also needs and overhaul to make it clearer.

As we ship features into the Local Chroma v.0.6 milestone, we will also want to make sure that we maintain parity with the JS client.

[Complexity] Subtask

• [Low] Clean up the TypeScript client and make it more idiomatic.
• [Med] (Ongoing) Keep the JS client in parity as new features are released for this milestone.

[AlabasterAxe]

Quick update here: I've started to ramp back up on the Javascript client / describe the scope of work. I've started to block out a shape of the client that would be more idiomatic IMO but don't have anything concrete to share yet. Shooting to have a project breakdown by EOD Monday.

[AlabasterAxe]

@atroyn I've fleshed out phase 1 for this work which is the work to make the client more idiomatic: https://docs.google.com/document/d/1DH9Gl5UQeuDr6vyGgoYUw0TkBxITgXIutZSU-ZYdP_E/edit

For the feature parity work, I just have placeholders while I work on understanding the new requirements better. If you're happy to leave that underspecified while I start work on the JS client improvements, I'll get started. Otherwise, I'll spend more time to understand the scope of the work more completely.

Regardless, it would be useful to understand the roadmap on the Python side and for me to see examples of how these features work in Python. I'd appreciate any additional places you can point me to to learn more.

Thanks!

[atroyn]

@AlabasterAxe I think we can get started on the improvements, and discuss runway along the way. Regarding the python roadmap, the milestone this issue is in (https://github.com/chroma-core/chroma/milestone/1) contains the planned work; I would be happy to provide more color about any of these / jump on a call.

[atroyn]

@AlabasterAxe

Have reviewed the proposed changes.

• Single collection() method: For now let's not deviate from the python API. The reason that get does not supply a default EF is because we do not currently store EFs together with collections. Shortly that's going to change (https://github.com/chroma-core/chroma/issues/2287) which will considerably simplify all of this. At that point, simplifying down to getOrCreateCollection probably makes sense.

• Flat Client: I think the flat client is a good idea and does seem more JS-ey, let's go ahead with that.

• Include Types Declaration: Definitely want the types declaration so we get the TS badge

• JS Doc Cleanup: Yes please

-Document Object: row-wise and column-wise layouts are something we've gone back and forth on a lot, and we've decided to stick with columns for the time being. We might revise this in a future release; one piece of info which would be useful here is to take a look at how / where Chroma is being integrated in other OSS projects, and if we find they are often doing this transform, we might want to do it for them.