Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Cross-Technologies Unit & API Specifications #31

Closed
haimkastner opened this issue Mar 8, 2024 · 5 comments
Closed

Support Cross-Technologies Unit & API Specifications #31

haimkastner opened this issue Mar 8, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@haimkastner
Copy link
Owner

haimkastner commented Mar 8, 2024

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.

The API object should look similar to:

export interface LengthDto {
    value: number;
    unit: LengthUnits;
}

And this is also how it will be represented in the OpenAPI specification.

The JSON will look like this:

{
   "value":100.01,
   "unit":"Meter"
}

As part of the full JSON payload something like:

{
   "someInfo":"someValue",
   "someInfoLength":{
      "value":100.01,
      "unit":"Meter"
   }
}

Any unit class will have an API to expose and load it:

export interface LengthDto {
    value: number;
    unit: LengthUnits;
}

export  class Length {

  ...
  ...

  public toDto(holdInUnit: LengthUnits = LengthUnits.Meters): LengthDto {
        return {
            value: this.convert(holdInUnit),
            unit: holdInUnit
        } ;
    }

    public static fromDto(dtoLength: LengthDto): Length {
        return new Length(dtoLength.value, dtoLength.unit);
    }
}

See also #29 for motivation

@Shentoza
Copy link

Shentoza commented 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.

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.

haimkastner added a commit that referenced this issue Mar 8, 2024
@haimkastner
Copy link
Owner Author

@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
Copy link

Shentoza commented 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

haimkastner added a commit that referenced this issue Apr 26, 2024
@haimkastner
Copy link
Owner Author

Implemented by #32

@haimkastner
Copy link
Owner Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants