Closed awatson1978 closed 5 years ago
Hi! Let’s talk about this at Dev Days next week.
I took the liberty of writing TypeScript definitions for this library that I believe also would be improved by an ES6 style import.
I won't be at Dev Days next week but wish I could be :)
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36046
I'm realizing that the additions I added, sort of limit the library to only FHIR 3 since they're based on the "fhir" types which are STU. I'm curious if there is going to be a new types added for 4. Admittedly though since the FHIR versions are generally backwards compatible and my types contemplate "CustomResources" then it's probably not that bad.
@bkaney Hi, I'm around to meet this afternoon (and tomorrow). Sitting in Kenzie doing work.
Hi @awatson1978 -- can you try the code here out to see if it works for you: https://github.com/Vermonster/fhir-kit-client/pull/112
Thanks!
With 1.4.0 release we paved the way for the library to work better on the client side. Here are a few examples: https://github.com/Vermonster/fhir-kit-client-examples
We still can work on converting to ESM, but perhaps the 1.4.0 release will work in your MeteorJS out-of-the-box?
Hey, I think I got v1.4.0 working with Meteor. :)
I want to kick the tires a bit more, but I managed to pull a CapabilityStatement using the code from the example. Looking real promising.
Okay, I am going to close this issue. If you have problems, feel free to open a new ticket. thanks!
Hello! This is Abby from Symptomatic and the Clinical Meteor project. I think we connected a few months back at the Baltimore Working Group and Application Roundtable.
Quick question: what do you all think about refactoring to use ES6 import statements? Have you given this much thought?
I ask because there’s some conversation from the FHIR-I group and others about identifying an NPM client library to rally some effort around. Most every client we’ve been tracking is a mix of some features in some areas, and not in others. But
fhir-kit-clients
seems to have decent multi-version support, ES6 classes, and test coverage. Seems like it might be an easier lift to add ES6 imports rather than adding multi-version support or dropping dependencies from the other libraries.I ask about imports in particular, since they provide the same functionality as require statements, but optimized by the V8 interpreter, and therefore accessible on both server and client.
If we could refactor to ES6 imports, I would likely add support for it in the Meteor on FHIR project.
Thanks!