You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could create our own file extension for formats, then when the user imports that file they get a file containing a bunch of "hand-optimized" functions for data sanitation.
How do our type checks become hand-optimized?
Well lowerString.sand.js
{_: String,lowercase: true}
becomes
exportfunctionsanitize(data){if(typeofdata!='string')thrownewError("Data is not a string")}// ... and more methods (we could actually split them into multiple files at build time for tree-shaking possibly but this is an implementation details)
This could have a massive performance payoff as it prevents us from needing to parse and recursively traverse the format at run-time. Instead we can let the formats define their own source code using some kind of API standard. It also can save significant amounts of time for formats which have a lot of possible options.
{symbol: String,validate: ['typeof data != "string"','Expected a string'],options: {lowercase: ['data !== data.toLowerCase())','String must be lowercase']}}// Note the "array of strings" syntax makes it easy for us to compile our functions differentially
One downside is this wouldn't have good support for contexts, but arguably that's a good thing in most cases, but it could still be limiting for specific use cases, and push people towards doing global stuff. We might benefit users by making the compilation step completely optional for end-users.
Edit: We should also support nested formats which means using import order to re-assemble the format structures
The text was updated successfully, but these errors were encountered:
We could create our own file extension for formats, then when the user imports that file they get a file containing a bunch of "hand-optimized" functions for data sanitation.
How do our type checks become hand-optimized?
Well lowerString.sand.js
becomes
This could have a massive performance payoff as it prevents us from needing to parse and recursively traverse the format at run-time. Instead we can let the formats define their own source code using some kind of API standard. It also can save significant amounts of time for formats which have a lot of possible options.
One downside is this wouldn't have good support for contexts, but arguably that's a good thing in most cases, but it could still be limiting for specific use cases, and push people towards doing global stuff. We might benefit users by making the compilation step completely optional for end-users.
Edit: We should also support nested formats which means using import order to re-assemble the format structures
The text was updated successfully, but these errors were encountered: