talha-t / neistion Goto Github PK

The parametersSchema could accept a string for a class name, then it could match it's classes for one with the same name as that string that way you wouldn't need to import or call the getSandhandsSchema method

Allow using app.get('/url', {...nestionOptions})

Instead of writing

class RandomParameters {
  @sandhandsProp
  public min!: number;
  @sandhandsProp
  public max!: number;
}

It could be written as

class RandomParameters extends NeistionParameters {
  public min!: number;
  public max!: number;
}

TransformParameters:
Allows you to modify your parameters after they are sanitized before they are passed to call. It could accept either the synchronous return, a promise to await to the output, or the call of a provided callback. It would merge the returned value with the existing ones. This could be useful for something like this

transformParameters: (parameters, next) => {
     bcrypt.hash(parameters.password, (error, hash) =>{
          if (error) return next(error)
          next({hash})
     })
}

NormalizeParameters
Almost exactly the same as transformParameters except it would happen before sanitation so you could normalize it before it's sanitized.

normalizeParameters: parameters => ({email: parameters.email.toLowerCase()})

There could be an option called autoSetup which could be true by default

There should be an option to get the parameters to be sanitized and be passed to the call function. It could accept any one of the following

• A function for getting them from the express request object (it wouldn't supply the response object)

getParameters: req => req.get('Accept')

• A string for using a preset (example "body" for HTTP Body, or "basic" for Basic Authentication)

getParameters: 'Basic'

• An object of the above for interpreting multiple parameter sources (example below)

getParameters: {
     auth: 'basic',
     body: 'body'
}

Then the user could fashion their schema based on that object so there wouldn't be any changes necessary to the schema system.

{
    auth: ['username', 'password'],
    body: {age: Number}
}

Use this library I created today to setup file/directory based routing paths.
https://github.com/L1lith/Directory-Routes

The verify function should also provide a "authorized" callback like this, because sometimes you will be forcing users to make their code by wrapping their code that only works with callbacks into a promise constructor.

verify: authorized => setTimeout(authorized, 1000)

Just an idea

The routerFolder in the Neiston options will automatically deeply require all files in that folder and their outputs will be treated as routes. This way you can cleanly organize all of your routes without needing to create a huge array of require statements. I recommend Require Directory for this, and you can create behavior with this where the folder names are treated as part of the path.

the verify function could be allowed to output Strings for the HTTP response text, or the HTTP status code, like this.

return "Incorrect Password"

or like this, and we could change the default status text mechanism to be based on the status code and automatically overiden by a custom status text.

return 500

return [500, "Database Error"]

Add a configuration option to use Fastify instead of Express under the hood. One way to achieve this could be to create a new Server class or something to act as a proxy between the Neiston logic and the http framework of choice.

I think when been introduced to this library the amount of information in the readme is overwhelming. I think it could be moved to it's own documentation and the readme made much more simple and comprehensible

I think there could be a prompt after you install to automatically ask to update the TypeScript config to add the required options so people didn't have to do it manually

I think you should be able to not supply an app instance, then have it default to express EDIT: or fastify if its installed