This monorepo contains all modules relevant for odata2ts to realize data type conversions: From OData types to native JS types or third-party types and back:
- the
converter-runtime
package realizes the loading process of converters - the
converter-api
package specifies converters and serves as contract between odata2ts and any converter implementation
It also contains converters you can use:
- V2-to-V4 Converters
- V2 numeric types are converted from
string
tonumber
Edm.Int64
andEdm.Decimal
are not converted and remain typestring
Edm.DateTime
is converted toEdm.DateTimeOffset
, i.e. proper ISO 8601 date and time presentationEdm.Time
is by default converted toEdm.TimeOfDay
(ISO 8601 time), but can also be relabeled asEdm.Duration
- V2 numeric types are converted from
- Common Converters
Edm.DateTimeOffset
: JavaScriptDate
typeEdm.Duration
: simple duration objectEdm.Int64
: JavaScriptbigint
type
- Luxon Converters
Edm.DateTimeOffset
: Luxon'sDateTime
typeEdm.Date
: Luxon'sDateTime
typeEdm.TimeOfDay
: Luxon'sDateTime
typeEdm.Duration
: Luxon'sDuration
type
- UI5 V2 Converters
- type alignment with UI5 V2 ODataModel (
sap.ui.model.odata.v2.ODataModel
)
- type alignment with UI5 V2 ODataModel (
Converters can be picked as a package (using the default converter set) or individually by specifying each converter. If different converters handle the same data type, then the last converter wins.
Converters are chainable. This makes the v2-to-v4 converter
utterly useful, because it spares
other converters the work and headaches to cope with V2 types and lets them focus on converting V4 data types.
For example, every Edm.DateTime
gets converted to Edm.DateTimeOffset
, so that the Luxon and the common converter
only need to handle Edm.DateTimeOffset
.
While some OData types (Edm.String
, Edm.Boolean
, ...) can easily and perfectly be mapped to native JS types,
more advanced types are simply strings:
Edm.DateTimeOffset
:"1999-31-12T23:59:59Z"
Edm.Duration
:"PT10H"
As you can imagine, there are countless third-party libs and custom data structures which could be used in these cases. Thus, the choice of how to map data types must be left open to the user.
So either use an existing converter or roll your own.
Main Documentation of odata2ts: https://odata2ts.github.io/
If you have any sorts of questions use GitHub Discussions
of the main odata2ts
repository.
This project is open to feature requests, suggestions, bug reports, and the like
via GitHub issues of the main odata2ts
repository.
Contributions and feedback are encouraged and always welcome.
See the contribution guidelines for further information.
This project has been created and is maintained in the following spirit:
- adhere to the OData specification as much as possible
- support any OData service implementation which conforms to the spec
- allow to work around faulty implementations if possible
- stability matters
- exercise Test Driven Development
- bomb the place with unit tests (code coverage > 95%)
- ensure that assumptions & understanding are correct by creating integration tests
MIT - see License.