search

inrupt / generator-solid-react

Generator for Solid React applications
https://generator.inrupt.com
MIT License
43 stars 15 forks source link

Tictactoe notifications not displaying in generated app #274

Open jholleran opened 4 years ago

jholleran commented 4 years ago

Describe the bug I have setup two Pods, (User 1) and (User 2). User 1 creates a tictactoe game for User 2. When I log in a User 2 I don't get an notification that the game has been created.

To Reproduce Steps to reproduce the behavior:

  1. Register User 1
  2. Register User 2
  3. User 1 creates a game to User 2
  4. Login as User 2 and check for notifications

Expected behavior A notification should be displayed in the top right corner of the screen and when you click it it should display the notifications in a list.

Screenshots N/A

Desktop (please complete the following information):

Smartphone (please complete the following information): N/A

Additional context The requests in the Network tab are all ok (No 404 errors). The only error I see is: index.js:23236 Uncaught (in promise) Error: Expected entity but got literal on line 1. at u.value (index.js:23236) at u.value (index.js:22826) at u.value (index.js:22854) at index.js:23321 at Array.every () at u.value (index.js:23320) at index.js:101678 at w (index.js:46479) at Generator._invoke (index.js:46459) at Generator.e. [as next] (index.js:46498) at p (index.js:92343) at a (index.js:92360)

Also, I noticed that when there is a GET request to the tictactoe inbox the response is JSONLD:

{"@id":"http://localhost:8000/tom/public/games/tictactoe/inbox","contains":["http://localhost:8000/tom/public/games/tictactoe/inbox/1574256847099","http://localhost:8000/tom/public/games/tictactoe/inbox/.acl"],"@context":{"contains":{"@id":"http://www.w3.org/ns/ldp#contains","@type":"@id"},"schema":"http://schema.org/","a":"http://www.w3.org/ns/auth/acl#type","solid":"http://www.w3.org/ns/solid/terms#","owl":"http://www.w3.org/2002/07/owl#","xsd":"http://www.w3.org/2001/XMLSchema#","skos":"http://www.w3.org/2004/02/skos/core#","rdfs":"http://www.w3.org/2000/01/rdf-schema#","acl":"http://www.w3.org/ns/auth/acl#","n":"http://www.w3.org/2006/vcard/ns#","geo":"http://www.w3.org/2003/01/geo/wgs84_pos#","dc11":"http://purl.org/dc/elements/1.1/","as":"https://www.w3.org/ns/activitystreams#","rdf":"http://www.w3.org/1999/02/22-rdf-syntax-ns#","terms":"http://purl.org/dc/terms#","ldp":"http://www.w3.org/ns/ldp#","time":"http://www.w3.org/2006/time#","ws":"http://www.w3.org/ns/pim/space#","prov":"http://www.w3.org/ns/prov#","foaf":"http://xmlns.com/foaf/0.1/","dc":"http://purl.org/dc/terms/"}}

The request header for the GET request has the following:

accept: application/n-quads,application/trig;q=0.95,application/ld+json;q=0.9,application/n-triples;q=0.8,text/turtle;q=0.5,*/*;q=0.1

As you can see it has application/ld+json before text/turtle.

If the SDK generator does not support JSONLD it should not have this in the Accept header.

RubenVerborgh commented 4 years ago

Related: https://github.com/solid/ldflex-playground/issues/8

RubenVerborgh commented 4 years ago

If the SDK generator does not support JSONLD

But this request is not being made by the SDK generator; it is made by LDflex, which supports JSON-LD.

Expected entity but got literal on line 1.

This looks like a parser error from N3.js (not entirely sure). Someone is trying to parse the JSON-LD document as Turtle.

Could you please produce a stack trace with a source map, so we can find out who that is?

RubenVerborgh commented 4 years ago

Or is the server lying and presenting the JSON-LD with Content-Type: text/turtle?

james-martin-jd commented 4 years ago

For what it's worth, the SDK does assume it's a ttl response right now. I suppose it's possible if it's returning json-ld, the SDK code is attempting to use N3.js to parse something (most likely notifications) and hitting an error at that point. It sounds like we need a way to force accept: text/turtle instead of json-ld?

RubenVerborgh commented 4 years ago

Yeah but the question is: who issues the request? If LDflex issues the request, then LDflex is responsible for parsing, and it is sending the correct headers. If the SDK is responsible for the request, then the SDK controls the Accept header.

If both are fetching the same document, but the server sends improper Vary headers, then the above can also happen.

RubenVerborgh commented 4 years ago

Could I get all request and response headers please?

jholleran commented 4 years ago 
GET http://localhost:8000/tom/public/games/tictactoe/inbox/

Request Headers:

accept: application/n-quads,application/trig;q=0.95,application/ld+json;q=0.9,application/n-triples;q=0.8,text/turtle;q=0.5,/;q=0.1
Origin: http://localhost:3000
Referer: http://localhost:3000/welcome
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Response Headers:

Accept-Patch: application/sparql-update
Accept-Post: text/turtle,application/ld+json,application/n-triples,/
access-control-allow-credentials: true
access-control-allow-origin: http://localhost:3000
Allow: GET,HEAD,OPTIONS,PATCH,PUT,DELETE,POST
Cache-Control: must-revalidate, no-transform, max-age=86400
Content-Type: application/ld+json
ETag: W/"5cd9d3e4c940139756122458b575f113"
Last-Modified: Wed, 20 Nov 2019 13:34:07 GMT
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox>; rel="original timegate"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox>; rel="self"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox/?ext=acl>; rel="acl"
Vary: Accept,Accept-Datetime,Prefer
RubenVerborgh commented 4 years ago

The above headers are correct (with the exception of Vary not including Origin, but not a problem for our purposes).

RubenVerborgh commented 4 years ago

So I'd need the source-mapped stack trace.

james-martin-jd commented 4 years ago

The same call against NSS shows the accept headers as */* instead. Not sure if that is significant or not.

jaxoncreed commented 4 years ago

When you send an OPTIONS request to ESS what does it return as it's supported content types?

RubenVerborgh commented 4 years ago

Just want to add here that the Accept header sent by the client does not / should not depend on the server. The client just states what it supports; regardless of what the server has to offer.

jholleran commented 4 years ago

Yesterday, I configured the server only return turtle and the JS error went away. But the Notifications were still not working. So it looks to be some other issue than the JS error I reported above that is causing this.

Today, for some strange reason, I don't see the JS error even though the server is back returning JSON-LD.

We are still debugging this here an I will send on any update.

@james-martin-jd what do ye do to debug the solid-react-components components?

james-martin-jd commented 4 years ago

@jholleran there's actually a Demo application in the repo, if you clone it and then npm run start in the root it spins up a demo app. The app runs on the App.js file, and is a VERY rudimentary page just designed to throw raw components or class calls in there.

james-martin-jd commented 4 years ago

So, after a lot of debugging, I believe this was a bug in the code where we had mismatched PUT vs slug header values. The PUT was to notificationName.ttl with a slug of notificationName. I've corrected this so the PUT does not have a slug anymore, although it still does say .ttl I am told this should not affect ESS one way or the other, just looks weird. I have an open ticket to improve this even more.

@jholleran is it possible for you to test this against ESS?