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

Proposal: Separating Fetch Layer and Query Builder within ODataQuery Class #27

Closed
mildronize opened this issue Jan 9, 2024 · 5 comments

Comments

@mildronize
Copy link
Contributor

mildronize commented Jan 9, 2024

Overview

This work is fantastic work for make a query builder for Odata Specification. Moreover, the current implementation of the ODataQuery class is a significant step in providing a type-safe query builder for OData specifications. However, there are specific use cases where direct request execution with query parameters from the fetch function is not desirable. This enhancement aims to split the Fetch layer and Query Builder functionalities within the ODataQuery class to cater to diverse usage scenarios.

Background

During my research on OData-related npm libraries, I found that this library is one of the most type-safe methods for generating OData queries. However, my use case involves working with the Azure Table Storage library, which requires filter expressions in a specific format.

Existing Solutions

There are existing npm libraries, such as bodia-uz/odata-filter-builder and jaredmahan/odata-query-builder, that generate filter expressions. However, both lack type safety.

Proposed Changes

The proposed enhancement involves splitting the Fetch layer and Query Builder functionalities. The goal is to maintain the type safety provided by the existing query builder while allowing users more flexibility in constructing and handling requests.

Expected Behavior

// Create a type-safe filter expression
const result = ODataExpression.forV4<User>()
    .filter((p) => p.firstName.$equals("john"))
    .build();

console.log(results); 
// Output: { "$filter": "firstName eq 'john'", ... }

This enhancement aims to provide a cleaner separation of concerns within the ODataQuery class, facilitating a more modular and adaptable architecture.

@mildronize
Copy link
Contributor Author

Due to PR #28 is already merged, this issue should be closed.

@mildronize
Copy link
Contributor Author

@cbrianball do you have any chance to release this PR.

@mildronize mildronize reopened this Feb 5, 2024
@cbrianball
Copy link
Owner

@mildronize I released it about 3 weeks ago, are you not able to use it? https://www.npmjs.com/package/ts-odata-client/v/2.0.2

@mildronize
Copy link
Contributor Author

Sorry, i confuse it thank you.

@mildronize
Copy link
Contributor Author

I can use it now, thank you,

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

No branches or pull requests

2 participants