Typescript and custom serializer support about keyv

So the function itself would do the class recognition? Ok

[wookieb]

@lukechilds No I'm not. That introduces typical data synchronization problem where you need to remember to change other file while changing the other. There is no reasonable way to handle that. I understand your decision and I accept it but I'm not going to participate.

[lukechilds]

Thanks for the offer of help with TypeScript, but it's just not something I'm interested in supporting. I don't think it would be that beneficial to a project of this size and I'm really trying to focus on simplicity.

Custom serializers are an interesting idea, although I'm not sure that that's something that belongs in Keyv. I'm already handling all of the standard JSON types (+ Buffers).

It seems like if you wanted to serialise a custom class it would make more sense to implement that in your class rather than create a custom serializer that would only work with Keyv.

e.g:

const foo = new Foo();
const fooObj = foo.toObject();
await keyv.set('foo', fooObj);

// Then in the future
const fooObj = await keyv.get('foo');
const foo = Foo.fromObject(fooObj);

[wookieb]

It seems like if you wanted to serialize a custom class it would make more sense to implement that in your class rather than create a custom serializer that would only work with Keyv.

Just having ability to set a function for serialization/deserialization is enough

new Keyv('...', {serializer: myCustomSerializerFunction, deserializer, myCustomerDeserializerFunction});

Now I can fully control how data will be serialized/deserialized.

I don't think it would be that beneficial to a project of this size and I'm really trying to focus on simplicity.

Using typescript for even small libraries have a lot of benefits:

• best autocompletion ever (right now, IDE is not even able to guess parameters used in constructor for KEYV) which also makes possible to read the docs directly in IDE without looking for README of the project.
• cleaner and better code with async/await http://wookieb.pl/7-reasons-why-you-should-use-async-await-today/
• no downsides for Javascript users - huge benefit for Typescript users

[lukechilds]

Just having ability to set a function for serialization/deserialization is enough

I suppose it would be a pretty minimal change. Ok, I'm not totally against this. Still not really convinced it belongs inside Keyv though. Is there a specific use case you have in mind for this?

Using typescript for even small libraries have a lot of benefits

Auto complete is a good point, however I disagree with your other points. Async/await is not a good reason to use TS, it could be achieved with Babel too or Vanilla JS if I dropped support for older Node.js versions.

And I think TS alienates some JS developers from getting involved. It's not a standard. I also really hate the idea of adding a build step. Vanilla JS is better IMO if you have reasonably modern targets.

Could we get the best of both worlds keeping the project vanilla JS but adding TypeScript definitions?

new Keyv('...', {serializer: myCustomSerializerFunction, deserializer, myCustomerDeserializerFunction});

And when would Key use those two functions? Does it need to recognize when an object is an instance of a certain class and when it isn't?

[lukechilds]

@MySidesTheyAreGone serialize/deserialize would be set to JSONB.stringify/JSONB.parse by default but could be overridden by the user.

[lukechilds]

@wookieb Any interest in contributing TypeScript type definitions?

[lukechilds]

@wookieb I'm gonna close this issue in favour of two new separate issues to make this easier to track.

Thanks for your input!