You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support Cross-Technologies Unit & API Specifications #31
As part of the powerful and wide support in multiple languages in the unit definition, I think it will be a good idea to standardize the way how unit is represented in an API spec, and how it will be exposed/loaded.
that would be a great change, currently we're holding a custom LengthDto that allows us to parse to/from out c# unitsnet backend.
const LengthToString = (input: { value: number; unit: string }): string => {
const unit = getLengthUnit(input.unit);
const l = new Length(input.value, getLengthUnit(input.unit));
return l.toString(unit);
};
the one usage we're currently not doing is actually converting the data from the backend to a UnitsNetJS Length, since it's hard to map the "Meter" string coming from the backend to the actual enum value.
Currenlty (as far as I see it) a UnitsNetJS Length has no information about the unit it currently is representing, since it always has Meter as a base.
@Shentoza
In your time you can see my new PR #32 with an implementation of this and check it that can improve your use-cases.
In the meantime, I have opened a discussion angularsen/UnitsNet#1378 with the UnitsNet owner to see his opinion about such a cross-language convention.
That's awesome. The example implementation in C# is basically what we're currently doing, to support a readable API response from our backend. Once your PR completes, we can remove all the bandaid solutions and almost feel like we're using a cross-technology framework for unit handling
@Shentoza After ~ two months of waiting for progress on the UnitNet library discussion, I've decided to merge the changes into the main version. From now on, you can utilize this updated version from both JS #32 & Python (haimkastner/unitsnet-py#18)
Regardless of the final decision made in the UnitNet thread, I'll maintain backward compatibility with this merged API.
Activity
Shentoza commentedon Mar 8, 2024
that would be a great change, currently we're holding a custom LengthDto that allows us to parse to/from out c# unitsnet backend.
the one usage we're currently not doing is actually converting the data from the backend to a UnitsNetJS
Length, since it's hard to map the "Meter" string coming from the backend to the actual enum value.Currenlty (as far as I see it) a UnitsNetJS Length has no information about the unit it currently is representing, since it always has
Meteras a base.Draft of #31 implementation
haimkastner commentedon Mar 8, 2024
@Shentoza
In your time you can see my new PR #32 with an implementation of this and check it that can improve your use-cases.
In the meantime, I have opened a discussion angularsen/UnitsNet#1378 with the UnitsNet owner to see his opinion about such a cross-language convention.
Shentoza commentedon Mar 8, 2024
That's awesome. The example implementation in C# is basically what we're currently doing, to support a readable API response from our backend. Once your PR completes, we can remove all the bandaid solutions and almost feel like we're using a cross-technology framework for unit handling
API DTO Implementation (#32)
haimkastner commentedon Apr 26, 2024
Implemented by #32
haimkastner commentedon Apr 28, 2024
@Shentoza After ~ two months of waiting for progress on the UnitNet library discussion, I've decided to merge the changes into the main version. From now on, you can utilize this updated version from both JS #32 & Python (haimkastner/unitsnet-py#18)
Regardless of the final decision made in the UnitNet thread, I'll maintain backward compatibility with this merged API.