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

StateOption data as promise or pass through when mocks are not available #168

Open
k3nsei opened this issue Dec 3, 2018 · 5 comments · Fixed by #220
Open

StateOption data as promise or pass through when mocks are not available #168

k3nsei opened this issue Dec 3, 2018 · 5 comments · Fixed by #220
Assignees

Comments

@k3nsei
Copy link

k3nsei commented Dec 3, 2018

Currently data property in StateOption can be only (primitive | Object | Function). But I have url that is responsible for returning many variants of data based on request payload (kinda like GraphQL). So I need to have ability to serve mock when some conditions are metting my predicates in other case it need to pass through request to real backend and return data from there.

So to do that I need to be able to set data property as Promise or have some pass through option to call real backend to get data.

@dwido
Copy link
Contributor

dwido commented Jan 6, 2019

hey @k3nsei,
Thanks for bringing this up, I am thinking of a few ways to deal with this when data property is a function

  1. when returning undefined from the function it will pass to the server
  2. returning a global e.g.
    Leonardo.addState({
        name: 'Get Comments',
        verb: 'GET',
        url: 'api/comments',
        options: [{
            "name": "Success with function",
            "status": 200,
            "data": (request) => {
               // calculate response in real time
               return Leonardo.goToServer;
        }]
    }

@tsachis @MrFrankel any other ideas?

@tsachis
Copy link
Contributor

tsachis commented Jan 6, 2019

With the above solution, it will be hard to define many different states for a single url and control them from the UI\API, which is what Leonardo is all about.

I suggest we add a new match property on the state level - which is a function that gets the request and returns a boolean which determine if Leonardo should use this state or keep looking for other matching states.
It will enable defining many states with the same URL and different macth function.

example:

Leonardo.addState({
        name: 'Get Comments',
        verb: 'GET',
        url: 'api/comments',
        match: (request) => {
           // returns true is this request should be processed by the current state, 
           // otherwise Leonardo will keep looking for matching state
           return !!request.body.comments;
        },
        options: [{
            "name": "Success with function",
            "status": 200,
            "data": {
				comments: {}
			}
		]}
    })

@dwido WDYT?

@k3nsei
Copy link
Author

k3nsei commented Jan 7, 2019

I think that @tsachis approach is quite good.

@dwido
Copy link
Contributor

dwido commented Jan 27, 2019

@tsachis seems that this approach is problematic when working with Sinon, the reason is that the decision if to mock a state or let it pass through is done when the xhr.open method is being called when there are no parameters of the request

@dwido dwido closed this as completed Jan 27, 2019
@dwido dwido reopened this Jan 27, 2019
@david2tm
Copy link
Contributor

david2tm commented Nov 1, 2021

@tsachis this can be closed

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

Successfully merging a pull request may close this issue.

4 participants