I encourage you to think about how much your app is like Navigator before committing further research to inspecting Daml-LF.
Navigator is an example of ledger metaprogramming; that is, it’s a tool meant for ledger inspection and interaction, with no idea of what is on the ledger, what it’s supposed to represent, or how it ought to be presented to users.
The trade-off is that it doesn’t “understand” anything about what the templates mean. A template Iou { issuer, owner, amount }
is treated exactly the same as a template Foo { bar, baz, quux }
if the fields have the same types. They have the same form fields, offer the same options, and use the same display presentation.
This is fine for a completely general ledger tool like Navigator, but is completely wrong for most applications, which ought to be written with the specific semantics of the specific templates they interact with in mind. Which means that whether this will work for your users depends on what kind of app you are building.
So the question is, are you working on a ledger metaprogramming application like Navigator?
If so, I strongly recommend that you do not write the Daml-LF inspection in JavaScript or TypeScript at all. My favored approach would be to follow @Gary_Verhaegen’s suggestion; since we do not support new ledger metaprogramming tools in general, your best chance is to follow our own approach as closely as possible, so that you can refer to our open-source code for hints on how to do things. (I discussed this a little more in a previous thread.)
If you are instead writing an application for a domain, I would suggest searching for a more indirect approach instead of inspecting Daml-LF. For example,
- even if you are not using React, it is still proper to be using
daml codegen js
; if the problem you are having is “the Daml gets updated before the JS app gets updated”, then you might be able to deal with this by inspecting the contents of the code-generated modules. - If the problem is template ID mismatches and you are hand-writing the JS interaction with
@daml/ledger
instead of taking advantage ofdaml codegen js
, then simply incorporating that into your build would fix the problem immediately, not to mention making your JS app safer.
But it’s really hard to say what would work without knowing the nature of the disconnect between Daml evolution and JS app evolution that you are experiencing.