StateOption data as promise or pass through when mocks are not available about leonardo

[tsachis]

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?

[dwido]

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?

[k3nsei]

I think that @tsachis approach is quite good.

[dwido]

@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

[david2tm]

@tsachis this can be closed