Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify PropSchema and ModelSchema #120

Open
NaridaL opened this issue Feb 4, 2020 · 3 comments
Open

Unify PropSchema and ModelSchema #120

NaridaL opened this issue Feb 4, 2020 · 3 comments

Comments

@NaridaL
Copy link
Collaborator

NaridaL commented Feb 4, 2020

There's currently a weird dichotomy with ModelSchema being a "serialization descriptor" for objects and PropSchema being one for all other types of values. There's object() which converts ModelSchema -> PropSchema, and the logic which would be in ModelSchema.serializer is instead the separate function "serialize".

This would be a breaking change, but as I've already got one in after the TypeScript conversion I'm considering making this change too.

Basically it would change ModelSchema to implements PropSchema, deserialize would just create a new Context and then delegate to the passed "PropSchema". object() and createSimple/ModelSchema would be unified and contain the logic previously part of serialize and deserialize.

Any thoughts? @mweststrate @alexggordon @pyrogenic

@mweststrate
Copy link
Member

@NaridaL sounds good in the abstract, but I haven't been using or working on this package for a couple of years :) Would you mind giving a quick example of what the breaking would look like from consumer perspective?

@peey
Copy link

peey commented Mar 17, 2021

A quick note that the feature request #147 might be an easy byproduct of the proposed unification.

So in case you move ahead with the unification, please keep that feature in mind.

@peey
Copy link

peey commented Mar 17, 2021

Also this unification would enable thing like deserialize(list(A), [...stuff...]) or deserialize(reference(User, findUserById), {...some serialize representation of id...})

i.e. it'll enable re-use of already-declared logic even where you have contents of just the property with you, instead of a class that houses the property.

This re-use is incredibly useful when declaring custom serializers that want to invoke serialization/deserialization on a sub-part of the data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants