Just wanted to say, I went through the implementations on theo's try-catch gist and have to say I like yours a lot. It's clean and simple and works even if it's early on. They should have a kudos page instead of just an issues page in github! Appreciate you releasing it.
Hope you keep it up, these are only suggestions because it's your library but perhaps something helpful while you are building things to get some early feedback. Maybe worth opening discussions tabs for this type of general feedback rather than real a real issue (which these aren't)
-
Eslint vs Language extensions -- I totally see why you would want an extension but for adoption the lint rule might be easier to adopt. Language extensions are just a bit less common imho. https://typescript-eslint.io/ shows us how some features of ts can be leveraged so maybe that's helpful? It might be just in my head but I see this type of thing as linting because it's syntactically correct but it's preferred to manage the error. Lint rules like this are relatively easy to generate these days so maybe for developer experience choosing the one that fits the toolchain might be an option? Either way I really appreciate that you've included this as a part of the packages. This can be something you consider once the api is stabilized as well or take contributions.
-
I personally like the go data, err syntax and since this form of error handling is really appealing to go devs it seems to make sense to keep it that way as well so I like that you chose that order
-
Maybe just lean into the try-catch name? try-catch-tuple is just a little more of a mouthful and if it's namespace scoped to you already it's probably ok?
-
object notation - I did like how czy-js had both object and tuples but the types did not work for me so maybe the complexity of the dual typing isn't worth it. It's easier to have a single api to document and support anyways.
Really looking forward to see where you take this!
Just wanted to say, I went through the implementations on theo's try-catch gist and have to say I like yours a lot. It's clean and simple and works even if it's early on. They should have a kudos page instead of just an issues page in github! Appreciate you releasing it.
Hope you keep it up, these are only suggestions because it's your library but perhaps something helpful while you are building things to get some early feedback. Maybe worth opening discussions tabs for this type of general feedback rather than real a real issue (which these aren't)
Eslint vs Language extensions -- I totally see why you would want an extension but for adoption the lint rule might be easier to adopt. Language extensions are just a bit less common imho. https://typescript-eslint.io/ shows us how some features of ts can be leveraged so maybe that's helpful? It might be just in my head but I see this type of thing as linting because it's syntactically correct but it's preferred to manage the error. Lint rules like this are relatively easy to generate these days so maybe for developer experience choosing the one that fits the toolchain might be an option? Either way I really appreciate that you've included this as a part of the packages. This can be something you consider once the api is stabilized as well or take contributions.
I personally like the go
data, errsyntax and since this form of error handling is really appealing to go devs it seems to make sense to keep it that way as well so I like that you chose that orderMaybe just lean into the
try-catchname?try-catch-tupleis just a little more of a mouthful and if it's namespace scoped to you already it's probably ok?object notation - I did like how czy-js had both object and tuples but the types did not work for me so maybe the complexity of the dual typing isn't worth it. It's easier to have a single api to document and support anyways.
Really looking forward to see where you take this!