3 ms·

This works quite well actually: https://github.com/mikew/transmission-material-ui/blob/master/src/api/index.ts#L39-L42 https://github.com/mikew/transmission-ma

This works quite well actually: https://github.com/mikew/transmission-material-ui/blob/master/src/api/index.ts#L39-L42 https://github.com/mikew/transmission-material-ui/blob/maste... https://github.com/mikew/transmission-material-ui/blob/master/src/api/types.d.ts#L15-L259 https://github.com/mikew/transmission-material-ui/blob/maste...

yencabulator 3y ago
That's seems to be completely missing validation. Typescript types are at their worst when they are lies, and the actual shape of the data is something completely different.
- c-hendricks 3y ago
  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

yencabulator 3y ago

That's seems to be completely missing validation. Typescript types are at their worst when they are lies, and the actual shape of the data is something completely different.

c-hendricks 3y ago
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