add runtime type-checker for bigint

[sisp]

No description provided.

[netlify]

✔️ Deploy Preview for mobx-keystone ready!

🔨 Explore the source changes: c67c4e6

🔍 Inspect the deploy log: https://app.netlify.com/sites/mobx-keystone/deploys/6215521a7162960008b67fbf

😎 Browse the preview: https://deploy-preview-366--mobx-keystone.netlify.app

[codecov]

Codecov Report

Merging #366 (c45fc71) into master (0bc6a0d) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #366      +/-   ##
==========================================
- Coverage   90.93%   90.91%   -0.02%     
==========================================
  Files         179      179              
  Lines        6387     6395       +8     
  Branches     1157     1160       +3     
==========================================
+ Hits         5808     5814       +6     
- Misses        542      544       +2     
  Partials       37       37              

Impacted Files	Coverage Δ
src/types/primitiveBased/primitives.ts	94.73% <0.00%> (-3.27%)	⬇️
src/types/types.ts	86.36% <0.00%> (+0.31%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0bc6a0d...c45fc71. Read the comment docs.

[xaviergonz]

Hmm, the problem with that types.bigint implementation is that it is not serializable to json, so it would result on unseralizable snapshots/patches when JSON.parse/JSON.stringify is used.

The other option would be to define const types.bigint = typesRefinement(typesString, (n) => /* here check string is a non empty integer number */, "bigint").withTransform(stringToBigIntTransform) or similar, but that would be kind of new (there hasn't been a type with a built-in transform before), but I guess this would be as a good time as any to add it.

[sisp]

Yes, you're right. Your observation is related to #369, something I stumbled over while working on those BigInt features.

[xaviergonz]

That being said, if there's a types.bigint with a built-in transform probably there should be a types.date("timestamp" | "isoString") as well... (I'm not implying that should be part of this PR, just thinking out loud :) )

[sisp]

Something like types.<someType>.withTransform(...) is along the lines of what I was vaguely trying to say in #369 (comment). Runtime types might ultimately not only check types but form a data schema including data encoding/decoding / serialization/deserialization + while at it also default values for optional (nested) fields.

[sisp]

That being said, if there's a types.bigint with a built-in transform probably there should be a types.date("timestamp" | "isoString") as well... (I'm not implying that should be part of this PR, just thinking out loud :) )

As an additional benefit, types with built-in transforms would be awesome when used in objects/arrays and nested fields:

tProp(types.object(() => ({
  int: types.bigint,
  date: types.date("timestamp"),
})))

Currently, it would be hard to do that with the tProp(...).withTransform(...) API.

[xaviergonz]

I tried it, even had a whole branch dedicated to that idea, but in the end I got bitten by some of the same typing problems than MST (problems with recursive types mostly)...

[sisp]

Hm, do you still have that branch and would you share it?

[xaviergonz]

I will need to check if it's still alive (it was on the laptop that broke and not pushed anywhere)