Fullstack Developer in a software team that develops information management systems.
Curious and fast learner with a desire to be up to date with tech all the time.
Hi, I have seen those features you have added and you really did a very good job. Few things I would like to recommand you to do as well are changing the names of the getUser, deleteUser and maybe even updateUser to getUserById and etc or at least give the user the option to choose its own default alias extensions which will be used for every asCrudApi function.
Second of all, let the user an option to valdiate the id he sends out to the API as param, for example to validate it represents ObjectId string or such.
Also, think about maybe splitting the api instance to services based on the DataModel of the api similirally to how you have done with the asCrudApi function but to make it actually diffrrent services in order for the user to get diffrenet autocomplete when calling api based on the service he wants and not just by url. Lastly, give the user to make his own scheme validation decisions based on the method he is calling to, for example: change only the getUsers validation to be of interface including the following keys: result of type User array scheme and amount of type number.
naming is a matter of taste, and i would prefer evoid taking decisions in the place of the end user. But i also would like to evoid making zodios asCrudApi a helper monster that tries to fit everyone needs. So maybe, i'll instead add guidance in the documentation on how to write your own helpers like asCrudApi.
As of today, i did not add runtime validation for parameters. I would prefer enforcing typescript string validation for this use case (see typescript template type literals that can typecheck for you your strings at compile time). But if you have a use case where we can't check parameters at compile time, i might change my mind.
For splitting the API, take a look at dev.to directory in examples. it's called asApi and can be used to code split your deplarations by models.
validation customization is already possible per endpoint. Just not for asCrudApi. i would also suggest the user to create is own helper if his use cases are too complex or even not use one and use zodios already generic api declaration for this use case.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello, quick update.
I like both your features of named enpoints and crud generattion.
so i added them both to zodios.
You can check it in these tests and documentation
Hi, I have seen those features you have added and you really did a very good job. Few things I would like to recommand you to do as well are changing the names of the getUser, deleteUser and maybe even updateUser to getUserById and etc or at least give the user the option to choose its own default alias extensions which will be used for every asCrudApi function.
Second of all, let the user an option to valdiate the id he sends out to the API as param, for example to validate it represents ObjectId string or such.
Also, think about maybe splitting the api instance to services based on the DataModel of the api similirally to how you have done with the asCrudApi function but to make it actually diffrrent services in order for the user to get diffrenet autocomplete when calling api based on the service he wants and not just by url. Lastly, give the user to make his own scheme validation decisions based on the method he is calling to, for example: change only the getUsers validation to be of interface including the following keys:
result
of type User array scheme andamount
of type number.Thank you for the feedback,
asCrudApi
a helper monster that tries to fit everyone needs. So maybe, i'll instead add guidance in the documentation on how to write your own helpers likeasCrudApi
.dev.to
directory in examples. it's calledasApi
and can be used to code split your deplarations by models.asCrudApi
. i would also suggest the user to create is own helper if his use cases are too complex or even not use one and use zodios already generic api declaration for this use case.