Ready, Start, and Error Functions in 1.0.0 Release Config

[kmdiogo]

First off, I just want to say I love the new release and the changes done.

In the previous release, the o.js config had the option to pass in callback functions for ready, start, and error. The 1.0.0 release does not appear to have this option. Is this a feature to be released in the future? I have made modifications locally on my end to make the ready callback function, but wasn't sure if there was anything else to account for.

[janhommes]

thanks, I appreciate that!

So basically that callbacks where removed. Why? So I thought it is not needed, as in modern javascript you can wrap it in a try-catch-finally block:

loading = true;
try {
  await o.get('smth').query();
} catch() {
 // throw some error here
} finally {
 loading = false;
}

You could put that in a class-function quite easily and just pass in the oHandler:

class myApi {
  constructor() {
    this.endpoint = 'http://smth';
    this.loading = false;
  }

  async getUsers() {
    return requestData(o(this.endpoint).get('users'));
  }

  async requestData(oHandler, query?) {
    let data;
    this.loading = true;
     try {
      data = await oHandler.query(query);
    } catch() {
      // throw some error here
     } finally {
       this.loading = false;
     }
    return data;
  }
}

And use it somehow like this: const users = await myApi.getUsers();

But if you have a good and easy approach we could add that functions again; I am open to any PR.

[kmdiogo]

Hi Jan,

Thanks for getting back to me so quickly!

Apologies for my JavaScript noobines, but how is the query parameter in requestData passed? Is it passed if you were to call:

myApi.getUsers().query({});

I would ideally like the syntax of the call to be of this form.

Thank you!

[janhommes]

So, you cannot do that and at the same time have a central try-catch-error. I would simply past it as a parameter:

myApit.getUsers({ $filter: 'Name eq "foo"'})

[kmdiogo]

That's fine, I was just wondering if there was a way.

Thanks for the help, and keep up the good work! o.js is by far my favorite client-side OData library!

EDIT: So I've created a class to wrap o.js. The try catch block is running the callbacks as intended but now I am running into another issue.

I am using Vue.js. My back-end has a lot of resources, and as such I like to import each resource I use in each component like: import {User} from 'api'

then, when I want to access the resource, User is simply a wrapper function for: o('http://userEndpoint')

and I can use it normally in my Vue component like: User.get().query({})

This syntax is impossible to have currently since o.js is wrapped in a class to allow callback functions. It is also difficult to get similar syntax. Each resource must be able to get, post, patch, and delete. I am finding myself adding code to account for all of these operations, and I feel it is redundant. Is it possible to achieve this without a callback configuration option in o.js? Thank you.

[janhommes]

sorry, I don't get what the issue is, still the start/error functions that you need to reimplement? Because the case that you are explaining, should work:

// file1 api.ts:
import { o } from 'odata';

export const User = o('http/myendpoint/user');

// file 2
import { User } from './api';

User.get().query().then((data) => console.log(data));

[kmdiogo]

Sorry, I should have been more clear. Yes, currently I have the class setup with the syntax you used above, but the issue is I can't implement start/error functions with a wrapper.

[janhommes]

So it would help you to have a generic error/start/finish function on each handler? Smth like this: export const User = o('http/myendpoint/user', { onStart: () => console.log('start' });

We can do that, but what are you expecting to happen onError? Should it just call the defined function or also throw?

[kmdiogo]

Yes, that would cover my use case perfectly!

For the error, I think running the function and throwing would suffice (and will be most likely how I will use it), though I do remember that o.js v0.4.0 had a strictMode in the configuration.

[janhommes]

Done in version 1.0.2