Comparison to existing methods?

[evbo]

Hi,

Love the motivation behind this project! Scalajs code is sooo much more beautiful when you get case classes.

That said, I just heard about this and prior I've been using Circe and Slinky for conversion. Would be awesome having a comparison documented:

• Circe uses JSON as the intermediary; First it encodes the case class as json, then convertS json to js
• Slinky has inlined and Scala2 quasi quote expressions for converting to Scalajs types, perhaps very similar to this repo?

[evbo]

One benefit to Slinky is you had to explicitly define a converter as either a Reader (converts to Scala type) or a Writer (converts to js type), which meant you could have generic Reader[T] and Writer[U] in scope together.

With nativeconverter, this causes an ambiguity since there's no differentiation reading and writing (and it's very common to need both).

Could that be a useful feature enhancement for NativeConverter have higher order kind like that?

[AugustNagro]

Love the motivation behind this project

Thanks :)

Would be awesome having a comparison documented:

That would be a good addition to the readme.

Circe works on the JVM, whereas NativeConverter only works with JS. This library is optimized for Javascript, and should be very fast. It's also a Scala 3 only library, supporting auto-derivation. It has a very small codebase. Finally, NativeConverter has built-in support for JS-native types, like Date and Map.

I'm not sure what slinky does exactly.

One benefit to Slinky is you had to explicitly define a converter as either a Reader (converts to Scala type) or a Writer (converts to js type), which meant you could have generic Reader[T] and Writer[U] in scope together.

Is that really a benefit? A NativeConverter instance is both a Reader and Writer; it has methods toJson, fromJson, toNative, fromNative, etc. Additionally, because it supports automatic derivation, users should never have to manually implement the trait.

Also, I see efforts towards a future release were last committed in June 2022. What's the road map look like?

This is a small library that's pretty stable. I'd like to add some more NativeConverter instances to ESConverters.scala, and also revisit Scala 3's explicit nulls.

[evbo]

@AugustNagro Thank you! Just to clarify my point about Slinky (scala2):

val reader = implicitly[Reader[X]]
val writer = implicitly[Writer[Y]]
callThisFunctionWithoutTypesDeclared()

vs NativeConverter (unless I'm missing a more concise way):

given NativeConverter[X] = NativeConverter.derived
given NativeConverter[Y] = NativeConverter.derived
callThisFunctionDisambiguatingBothGivens[X, Y]()

// e.g. callThisFunctionDisambiguatingBothGivens[T, U]()(using NativeConverter[T], NativeConverter[U]): U = {}

So all I'm saying is would be nice if there was a built-in way to disambiguate without having to explicitly declare generic types like that - not a big deal just ergonomics that Slinky does pretty well ;)

[AugustNagro]

Could you share a bigger example? I'm sure we can get it to a more ergonomic state.

[AugustNagro]

With classes X and Y defined please :)

[evbo]

I will definitely get back to you with a scala sandbox, but essentially I do not use derives but instead the alternative derived

The reason I do this is to avoid all dependencies for NativeConverter. This is because I'm using NativeConverter in a cross project and the JVM doesn't know about NativeConverter this way. I realize, now, that you provide stubs for that purpose, but it's also nice being completely decoupled ;)

Then again, there's no way to be decoupled from JSExportAll, so I'm using stubs anyway