Comments (5)
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.
from bs-decode.
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. :)
from bs-decode.
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.
from bs-decode.
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. 😉
from bs-decode.
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!
from bs-decode.
Related Issues (20)
- Plan for v2 HOT 11
- Report errors as JSON HOT 1
- Implement MonadThrow
- Deprecate tuple decoders HOT 1
- Rethink custom/extensible validations HOT 1
- Deprecate mapN, NonEmptyList, ParseError.ResultOf
- Add a null decoder HOT 1
- Add dictJson and arrayJson
- Delete all deprecated features
- Add letops support HOT 1
- Add odoc comments
- Change the implementation of optional
- optionalField produces wrong error on non-object JSON HOT 1
- Int decoders succeed on out-of-range numbers
- Order of `fallback` arguments should be switched
- Needs bs-abstract upgrade HOT 4
- mention bs-bastet as a peer dependency over bs-abstract in the docs HOT 2
- decoding-variants#complex-variants HOT 3
- bs-decode no longer compiles v0.11.1 HOT 2
- Production users, roadmap? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bs-decode.