GitHub user DadiBit added a comment to the discussion: Better type safety
schemas
_First of all, thanks for the crazy quick reply: first time that happens to me
in an open source project!_
I like that DuckDB allows me to access static datasets, however as domortiz
stated, the moment I started working on my frontend I realized I had no
typescript checking (just the good old `tsc` blindly using `any` type).
I have very little knowledge on the underlying library structure, but I'm
pretty sure some refactoring will be required. I would start by proposing a
change that shouldn't brake anything, and is super easy to implement: let the
`Schema` constructor accept a typed dictionary like:
```typescript
const schema = new Schema({
'name': new AnonymousField(...args...),
'age': new AnonymousField(...args...),
}, ...args...)
```
This would simply call `new Field(key, ...args...)` under the hood, just like
my example.
This is simple and won't need much testing, but next part is better, if it gets
properly tested (as it's a bit more complex).
---
Checking the Field class:
https://github.com/apache/arrow-js/blob/90c1db18cff5755b586bd8978c73aaa990770626/src/schema.ts#L106-L146
It looks to me we could get away with a simple dictionary with a `{...args...}
as const as IAnonField`:
```
interface IAnonField<T> {
name: string,
type: T,
nullable?: boolean,
// This also is a bit sus, Why allow null *and* udnefined? Is it intended?
Idk...
metadata?: Map<string, string> | null
}
const x = { type: arrow.Int32 } as const satisfies IAnonField;
x.type; // this should show arrow.Int32 when hovering over it in vscodium
```
This means we let typescript know the field type, which is actually a value
available at runtime in the javascript engine. I'll try working on this
tomorrow instead, looks super promising :smile:
GitHub link:
https://github.com/apache/arrow-js/discussions/232#discussioncomment-14060153
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
