-
Notifications
You must be signed in to change notification settings - Fork 30
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
Consider dropping the shield concept and suggest that developers use validation libraries #42
Comments
Telefunc already automatically runtime checks the telefunction arguments' types. So the only thing left for the user to do is semantic validation (e.g. I think the main problem today is that the docs don't reflect the fact that you don't need I'm waiting for #40 to be reviewed to improve the docs. |
Just saw this old issue and politely chiming in: I wonder more and more why we'd need the auto runtime checks which costs perf b/c I'd claim that you need always a val lib, why:
=> so the most simple form should be validated Think this is really a missed opportunity (being able to bring your own val instead of the default one). |
I ain't categorically against allowing users to use a validation library like But, so far, I actually like the separation of concerns between type validation (TypeScript) and semantic validation (e.g. email). The vast majority of runtime validation is about types, which TypeScript and therefore For semantic validation, it's often cleaner to use tailored solution instead a general-purpose tool such as By a matter of fact, other than email validation, it seems that only few people use the semantic validations provided by |
Good points. But even if one don't need any semantic val, just having zod (or whatever lib) for unified error management in multiple langs is important Nobody wants to reinvent the wheel and some good error management which knows when to throw or return undefined, which works on the client in notifications, in modals, does redirects or not needs a solid foundation and better, a good ecosystem. Ofc you can try to hack your own and ship 2030. However, maybe this convo should be rather about generic middlewares with shield as default but where users can do whatever they want and stay DRY. A proper middleware b/c there are many more concerns which run on a request but not on every, e.g. authc, authr, caching, logging, generic error management, throw or redirect and so on. Check out https://github.com/giuseppelt/httpc which has a nice middleware concept in its kit version. But again, telefunc shines b/c of its simplicity, there's is so much potential and the need for a solution (which isn't trpc). Also look, integrating any of those solutions incl Telefunc is not a small decision, once you are on it you can't easily migrate away and hence, the solution must satisfy some minimal requirements. |
I'm also not against a middleware system, I'm just waiting for a concrete use case for it with a user that actually needs it. If we can keep things simple, then let's keep them simple. |
Telefunc seems the most straightforward lib out there for RPC in Javascript; which i find the selling point of telefunc.
Validation is obviously important but I believe it would be worthwhile to point people to projects like AJV(JSON-schema) which are specialized in the validation issue.
In that case telefunc would need something like (validation) middleware or just show examples of function composition to enable validation using a third-party validation library.
The text was updated successfully, but these errors were encountered: