3 ms·

This is a nice looking website, and I can imagine this being a really useful hook into consulting work. Some thoughts: - replace strings with enums where poss

This is a nice looking website, and I can imagine this being a really useful hook into consulting work. Some thoughts: - replace strings with enums where possible. E.g. "USD" should be from an enum - this sort of data-interop library could maybe be written in a configuration language that it uses to generate libraries for different languages - a glossary would be really helpful - a list of banks who've adopted this ISO standard might be interesting

Waterluvian 2y ago
This is one place where interop between JS and TS gets prickly. If you envision this as a Typescript library, strings are much more ergonomic, so long as you’ve got a union type for all the variants. But if you want it to be decent for non-TS, you pretty much have to concede that compromise and use an enum/object. Note how this is a typescript project and leverages a type for currency that comes from a common library, and therefore doesn’t have to do any of the work! https://github.com/Svapnil/iso20022.js/blob/main/src/lib/types.ts#L16 https://github.com/Svapnil/iso20022.js/blob/main/src/lib/typ...
- robertlagrant 2y ago
  That's a fair point. The thing I'd be more thinking about is: can I get a list of currencies? I get I have type safety, but if I want to present the user with a list of valid currencies, can I do that from the type system? Enums can make that sort of thing very straightforward.
  - Waterluvian 2y ago
    Yeah. The way I handle this is to make an array (or set) of those strings and then define a union type of that array. Which is basically just an enum of my own invention. But after years of trying different things, I find this is the most practical. Objects are uncomfortable. TS enums really suck, IMO. So maybe we’re actually in agreement. And to an extent can just have both: autocompletable, legible strings without another import or object. And also an iterable collection of the variants.
deleted 2y ago
[deleted]
svapnil 2y ago
Thanks for your feedback Robert! I think payments is an industry in general that is starving for the right information, so a free and open source package like this should have an abundance of information. I'll make sure I add it in. The configuration language sounds really interesting. What I think is special about this library is that it comes with all the Typescript furnishings one would need to have a powerful dev experience. The goal is to make it incredibly easy for a developer to use iso20022, not just another middle layer that obfuscates it
- robertlagrant 2y ago
  It's a pleasure! To be clear, I meant that you could have a repository that contains all of the information in some sort of configuration language (or maybe in Typescript; I suppose that doesn't really matter) but you use that to generate multiple libraries; one for each language you might want to support. So a single codebase (or configuration base) could generate iso20022.js, iso20022.ts, iso20022.py, etc etc. It's not simple; it might just be an interesting distant goal to keep in mind.
j16sdiz 2y ago
> - replace strings with enums where possible. E.g. "USD" should be from an enum Believe it or not, many bank use custom/non-standard currency code internally. I agree enum can be used for SWIFT, but it need to be string to be used internally in many bank.

Waterluvian 2y ago

This is one place where interop between JS and TS gets prickly. If you envision this as a Typescript library, strings are much more ergonomic, so long as you’ve got a union type for all the variants. But if you want it to be decent for non-TS, you pretty much have to concede that compromise and use an enum/object. Note how this is a typescript project and leverages a type for currency that comes from a common library, and therefore doesn’t have to do any of the work! https://github.com/Svapnil/iso20022.js/blob/main/src/lib/types.ts#L16 https://github.com/Svapnil/iso20022.js/blob/main/src/lib/typ...

robertlagrant 2y ago
That's a fair point. The thing I'd be more thinking about is: can I get a list of currencies? I get I have type safety, but if I want to present the user with a list of valid currencies, can I do that from the type system? Enums can make that sort of thing very straightforward.
- Waterluvian 2y ago
  Yeah. The way I handle this is to make an array (or set) of those strings and then define a union type of that array. Which is basically just an enum of my own invention. But after years of trying different things, I find this is the most practical. Objects are uncomfortable. TS enums really suck, IMO. So maybe we’re actually in agreement. And to an extent can just have both: autocompletable, legible strings without another import or object. And also an iterable collection of the variants.

deleted 2y ago

[deleted]

svapnil 2y ago

Thanks for your feedback Robert! I think payments is an industry in general that is starving for the right information, so a free and open source package like this should have an abundance of information. I'll make sure I add it in. The configuration language sounds really interesting. What I think is special about this library is that it comes with all the Typescript furnishings one would need to have a powerful dev experience. The goal is to make it incredibly easy for a developer to use iso20022, not just another middle layer that obfuscates it

robertlagrant 2y ago
It's a pleasure! To be clear, I meant that you could have a repository that contains all of the information in some sort of configuration language (or maybe in Typescript; I suppose that doesn't really matter) but you use that to generate multiple libraries; one for each language you might want to support. So a single codebase (or configuration base) could generate iso20022.js, iso20022.ts, iso20022.py, etc etc. It's not simple; it might just be an interesting distant goal to keep in mind.

j16sdiz 2y ago

> - replace strings with enums where possible. E.g. "USD" should be from an enum Believe it or not, many bank use custom/non-standard currency code internally. I agree enum can be used for SWIFT, but it need to be string to be used internally in many bank.