Consider lazy response processing

[alien-mcl]

There is an option of having a lazy payload processing implementation that would carry a response object received from the 'fetch' API and use the client's facilities to process that response on demand once proper properties or methods are invoked.
This may delay or in some cases prevent unnecessary processing.

[asbjornu]

As discussed in HydraCG/Specifications#138, a Promise (i.e. callback) based way to handle responses would be nice, so we don't hard code the response expectation into the request side of the client code, but instead can handle that in a decoupled way in a more generalised response handler.

[tpluscode]

Well, fetch is already promise-based so it's a natural pattern to follow with any deferred processing. I'd even use async/await...

And about processing itself, yes the client cannot assume what would be returned from an endpoint. That information must be determined only after receiving the bits.

[asbjornu]

Well, fetch is already promise-based so it's a natural pattern to follow with any deferred processing. I'd even use async/await...

With async/await, the coupling between the request and response has come full circle, I feel. That's why I originally suggested a callback approach, so that the response was explicitly decoupled from the request. With async/await, the asynchronicity and decoupling is reduced to syntactic sugar with the very purpose of making it appear like synchronous code.

How do we reap the benefits of the event/callback approach being decoupled without using an event/callback approach, but Promises that naturally leads to async/await?

And about processing itself, yes the client cannot assume what would be returned from an endpoint. That information must be determined only after receiving the bits.

Exactly. I therefore find that getCollection() is a bit too specific about the expected result.

[elf-pavlik]

If we look at the current snippet with getCollection()

var operation = client.get("http://example.com")
    .getApiDocumentation()
    .getEntryPoint()
    .getCollection({
      property: "http://www.w3.org/1999/02/22-rdf-syntax-ns#type",
      object: "http://schema.org/Event"
      })
    .getOperationOfType('http://schema.org/CreateAction');

we can see that it does not take an IRI as parameter but ?s, p, o pattern to match on the data present in the entry point.

{
    "@context": "/api/context.jsonld",
    "@id": "/api",
    "@type": "hydra:EntryPoint",
    "collection": {
        "@id": "/api/events",
        "title": "List of events",
        "@type": "hydra:Collection",
        "manages": [
            {
                "property": "rdf:type",
                "object": "schema:Event"
            }
        ],
        "operation": [
            {
                "@type": ["hydra:Operation", "schema:CreateAction"],
                "title": "Create new event",
                "method": "POST",
                "expects": "schema:Event"
            }
        ]
    }
}

Maybe name selectCollection() would cause less confusion here, client could implement it as synchronous method on EntryPoint object.

function selectCollection (pattern) {
  return this.collection.find(col => col.manages.includes(pattern))
}

[alien-mcl]

With async/await, the coupling between the request and response has come full circle, I feel. That's why I originally suggested a callback approach, so that the response was explicitly decoupled from the request.
As for JS, async/await is only syntactic sugar on top of promises, which are somehow callback-driven (function passed to the then). I'm not sure what's wrong with async/await. That coupling is only a feeling - it's still non-blocking, lazy resolved operation.

we can see that it does not take an IRI as parameter but ?s, p, o pattern to match on the data present in the entry point.
Oh, that's the worst - way to RDF'ish. We can go that way if we want to scare developers off.

Exactly. I therefore find that getCollection() is a bit too specific about the expected result.
I agree

[elf-pavlik]

we can see that it does not take an IRI as parameter but ?s, p, o pattern to match on the data present in the entry point.

Oh, that's the worst - way to RDF'ish. We can go that way if we want to scare developers off.

I would see it appropriate for the client to besides generic selectCollection() which takes triple pattern, also provide more specific selectCollectionByMembersType() which would simply take IRI (or CURIE once we clarify how to manage JSON-LD context used by cilent). I consider it a much cleaner approach than trying to add some more specific handling of manages with rdf:type to the vocabulary itself.

function selectCollectionByMembersType (membersType) {
  return this.selectCollection({
    property: "http://www.w3.org/1999/02/22-rdf-syntax-ns#type",
    object: membersType
  }))
}

To get back on my point about selectCollection(), it wouldn't actually fetch the resource but only acts as helper on EntryPoint. Implementation could stay synchronous so I don't see it directly related to this issue.

[lanthaler]

I filed a separate issue for the collection selection discussion. Let's keep this issue focus on the lazy processing aspect. Please also keep in mind that lazy processing is not about asynchronous network requests. If we need discussions for that too, please file a separate one.