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

Support compiling to raw JS #46

Open
L1lith opened this issue Jun 14, 2022 · 0 comments
Open

Support compiling to raw JS #46

L1lith opened this issue Jun 14, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@L1lith
Copy link
Owner

L1lith commented Jun 14, 2022

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

export function sanitize(data) {
      if (typeof data != 'string') throw new Error("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

@L1lith L1lith added the enhancement New feature or request label Jun 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

1 participant