Encoding?

[mrmurphy]

Just a thought, it might be great to have Encoding in this library, even if it exactly matches the design of bs-json, so that we can have a one-stop shop for JSON decoding & encoding.

But that might necessitate a name change, too :o.

bs-jaysawn 😆.

bs-codec 😴

bs-dragonglasses 🔥 🤓

[johnhaley81]

I always just add this in with every project 😁

Big 👍 to this. I can open a PR if you have an idea for where to put this stuff.

[mlms13]

I admit I've only really used Js.Json directly for encoding. But this has come up enough that I'm definitely not opposed to adding useful utilities here.

I'm not quite sure what the API should look like, because I don't even know what I'd want out of it, but I'm curious to see what the rest of your are doing, and I'll happily accept PRs that the two of you find useful.

It's true that library naming starts to become an issue. 😉

[TomiS]

This might be obvious, but in case anyone proceeds with this, I just want to say that it's probably not a good idea to assume decoding and encoding are symmetric in any way.

As we know, decoding is usually done when data is fetched from the API and encoding just before posting it back. In my experience, while the payloads might seem mostly similar, it's also often necessary to have some differences between the data you post to API and the data you receive. There can also be differences between post/put/patch methods and between response payloads from individual and "query" APIs. So basically sooner or later one ends up in a situation where each API method has a separately defined request and response payloads and thus separately defined decoders and encoders for each one of them.

[mlms13]

Just an update on this one:

• I agree that symmetric encoding/decoding is not always what you want. In fact, in our application (which has a Reason frontend but a Scala backend), we often don't have much need for symmetric encoding because our client-side types don't exactly match the data the server expects.
• However, I also understand that, especially in cases where both the client and server are written in Reason, having shared encoders and decoders on the client and server that work consistently is super valuable.

My plan at the moment is to do a tiny bit more cleanup with module naming and monadic/applicative let operators (once those land in BuckleScript), then release a v1.0 and start focusing on the next major milestone of bs-decode.

I hope that the next major version after v1 will inherit the error handling and much of the API, but it will be based on defining a schema (via Relude's FreeApplicative), which can be used to both encode and decode, as well as produce generators for random values, and probably a lot more.

I hope to start work on this fairly soon, and I'll keep y'all posted. :)

[mlms13]

Clearly I did not start working on this "soon." 🙈 While I have recently started working on bs-decode again, my immediate focus is going to be:

• taking advantage of newer OCaml features available through Melange
• cleaning up cruft and confusing things in the core library
• deriving decoders via ppx_deriving

That means I'm unlikely to work on encoders or codecs in the immediate future. In the meantime, Relude's JSON module has a JE submodule with lots of encoding helpers.

I still eventually want to tackle something more schema-like, but since it's not something I'm working on right now, and it's likely to be a separate library if it ever happens, I'm going to close this issue for now. If anyone reading this ever wants to brainstorm schema/codec stuff, definitely let me know, though!