3 ms·

It's copied and adapted directly from their RPC docs, validation would just be busy work. https://github.com/transmission/transmission/blob/main/docs/rpc-spec.

It's copied and adapted directly from their RPC docs, validation would just be busy work. https://github.com/transmission/transmission/blob/main/docs/rpc-spec.md https://github.com/transmission/transmission/blob/main/docs/...

yencabulator 3y ago
For Transmission, maybe. In general, validation is very much not "busywork".
- c-hendricks 3y ago
  On top of automatically generated types (eg. openapi, graphql), I would say it is. Seems like you're just inserting yourself and ranting about typescript where it's not really applicable.
  - yencabulator 3y ago
    Lovely attitude, you have a nice day too. There's others expressing the same concerns, for example https://news.ycombinator.com/item?id=37101393 https://news.ycombinator.com/item?id=37101393
    - c-hendricks 3y ago
      What's your solution though? To me, if the server has updated it's schema and the client has old code, the server responds with an error, the user sees "something went wrong". And if the validation fails on the client side, the user sees "something went wrong" And if the client isn't doing validation of what's returned, and an error gets thrown because it tried to access a now missing field, the user sees ... "something went wrong" Intentionally maintaining multiple versions of an API, or making sure your API changes are backwards compatible (like adding new fields and marking old ones as deprecated), those are solutions but definitely require organizational effort. All totally expressible via Typescript though!
      - yencabulator 3y ago
        With an explicit error you get from validation (like Zod, as used in tRPC), you could notice that your client is out of date and either refresh automatically or prompt the user to refresh[1]. The benefit from validation is that the error is easily recognizable & can be handled nicely, even in just one place. Without validation, you get things that Typescript claims are impossible, for example exceptions on code paths that look like they cannot throw, and you can't easily tell why any of that happened -- that's a recipe for miserable debugging. Of course, with less busy, less critical, sites you might not notice or care. [1]: Refresh could cause loss of user input (e.g. text just entered), depending on the app that might matter and need browser-side storage or something along the lines of the "local first" manifesto. Easy kludge for simple apps with smart users is to make the user copy the text, click refresh, paste.
        c-hendricks 3y ago
        Isn't that only for one case of errors though (server not matching expected response)? One solution I thought was clever, was a friend's single-page app would hard-reload on navigation, if there was an update to the assets. Not sure how feasible that would be for schema errors though.
        yencabulator 3y ago
        Between that and catching 400 Bad Requests coming back from the server, you're pretty much catching any communication errors resulting from version skew. SvelteKit can poll to check server version and refresh, both on timer and if assets are 404. But as you implied, that doesn't help with API evolution and e.g. users interacting with a form (apart from increasing the likelihood the page will refresh soonish due to navigation).

yencabulator 3y ago

For Transmission, maybe. In general, validation is very much not "busywork".

c-hendricks 3y ago
On top of automatically generated types (eg. openapi, graphql), I would say it is. Seems like you're just inserting yourself and ranting about typescript where it's not really applicable.
- yencabulator 3y ago
  Lovely attitude, you have a nice day too. There's others expressing the same concerns, for example https://news.ycombinator.com/item?id=37101393 https://news.ycombinator.com/item?id=37101393
  - c-hendricks 3y ago
    What's your solution though? To me, if the server has updated it's schema and the client has old code, the server responds with an error, the user sees "something went wrong". And if the validation fails on the client side, the user sees "something went wrong" And if the client isn't doing validation of what's returned, and an error gets thrown because it tried to access a now missing field, the user sees ... "something went wrong" Intentionally maintaining multiple versions of an API, or making sure your API changes are backwards compatible (like adding new fields and marking old ones as deprecated), those are solutions but definitely require organizational effort. All totally expressible via Typescript though!
    - yencabulator 3y ago
      With an explicit error you get from validation (like Zod, as used in tRPC), you could notice that your client is out of date and either refresh automatically or prompt the user to refresh[1]. The benefit from validation is that the error is easily recognizable & can be handled nicely, even in just one place. Without validation, you get things that Typescript claims are impossible, for example exceptions on code paths that look like they cannot throw, and you can't easily tell why any of that happened -- that's a recipe for miserable debugging. Of course, with less busy, less critical, sites you might not notice or care. [1]: Refresh could cause loss of user input (e.g. text just entered), depending on the app that might matter and need browser-side storage or something along the lines of the "local first" manifesto. Easy kludge for simple apps with smart users is to make the user copy the text, click refresh, paste.
      - c-hendricks 3y ago
        Isn't that only for one case of errors though (server not matching expected response)? One solution I thought was clever, was a friend's single-page app would hard-reload on navigation, if there was an update to the assets. Not sure how feasible that would be for schema errors though.
        yencabulator 3y ago
        Between that and catching 400 Bad Requests coming back from the server, you're pretty much catching any communication errors resulting from version skew. SvelteKit can poll to check server version and refresh, both on timer and if assets are 404. But as you implied, that doesn't help with API evolution and e.g. users interacting with a form (apart from increasing the likelihood the page will refresh soonish due to navigation).