> None of this matters most of the time, but yeah it's still funny.
Implicit type coercion doesn't matter most of the time? You don't often have bugs because of it?
Implicit type coercion doesn't matter most of the time? You don't often have bugs because of it?
Whenever I kick off a new npm init, it's always followed by installing typescript, eslint, and usually Zod before I even write the first line of code. If double equals was removed from ECMAScript, I would likely never notice.
It would have made more sense to throw an exception, but JavaScript at it's origin was meant to be a simple scripting language. Nowadays with TypeScript it's much less of an issue.
On the backend all requests and database values are similarly validated and sanitized before any logic occurs.
Anything less is bad code regardless of what languages are used.
Good thing there are never any bugs in validation and sanitization code!
First, for the APIs, you need documentation: https://swagger.io/
From which you can generate JSON schemas and use those to validate in the browser and on the backend. https://www.npmjs.com/package/jsonschema
As well you should be writing a few more schemas for your application state and leverage the regex validation of your input components...
Speaking of which, you also need to sanitize out some potentially nasty input. https://www.npmjs.com/package/dompurify
Obviously this isn't everything and not perfect, but a lot of this tedium can be automated away if you have a few good examples of the happy path and some basic tests in place to prevent quick and dirty changes from poking holes in these layers.