Skip to content

Conversation

@heruka-urgyen
Copy link
Collaborator

@heruka-urgyen heruka-urgyen commented Oct 21, 2020

Scope

  • add front-end dependencies
  • add front-end dev mode
  • render articles
  • resolve questions regarding data presentation (see below)
  • add login flow
  • fetch and store labels
  • refactor
  • add build mode integrated with backend (web server improvements #20)
  • update readme

Run in dev mode

  1. cd frontend
  2. npm i
  3. npm run dev
  4. open localhost:9000 in browser

Questions

  1. Get data for unread emails?
  2. What is read / unread in data and how to move articles between them?
  3. What are unique paper titles?
  4. How should refs be rendered? It's returned as a list, but all examples have only one. What is the number inside parentheses? Again, in all examples it's always 1.
  5. What is Freq in data?
  6. How should we approach bundling everything together? I can build to a dir with all assets and scripts. Perhaps we need a higher level automation that will trigger front-end build.
  7. Shall we update readme with info about front-end, e.g. how to run it in dev / prod mode? Or shall I make a separate readme under frontend dir?

Preview

poc

Copy link
Owner

@bzz bzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome 😍

I will try to answer all questions about data-model (1-5) in a simple doc a bit later.

On 6: IMO ATM in this or subsequent PRs it would be enough to have a frontend build profile in npm that outputs all nessesary resources to a dir.
I.e. it's totally fine to expect having everyone to run it locally in the dev mode for now.
As soon as we remove all impediments for having an actual deployment (#20 ) - I will add a build.sh that triggered it and a backend build, bundles all the resources into the single binary and add a route serving them.

On 7: We definitely should have a readme inside the frontend dir, with the dev mode instructions.

We should also add a section to the root readme, pointing to the frontend dir and mentioning the status (experiential) of our new, awesome, interactive GUI.

@heruka-urgyen
Copy link
Collaborator Author

heruka-urgyen commented Oct 22, 2020

I will try to answer all questions about data-model (1-5) in a simple doc a bit later.

I'm waiting on this to finalize the page.

Also, let me know if you want any changes in front-end before that. Shall we consider simple UI enhancements? Maybe we could make a short roadmap?

@bzz
Copy link
Owner

bzz commented Oct 23, 2020

Shall we consider simple UI enhancements?

yes!

make a short roadmap

yes, that would be awesome! So far #19 has several thoughts on that, as well as #32 proposes improvements with regards to the source of citations.

Most probably, we should talk to @jzuken to get his ideas for immediate improvements.

What I think would be great is to follow the same pattern as we did with CLI, where ALL improvements of the template of the report (now the UI) were first introduced behind a feature flags.

So basically, there were no surprises for the users until and they can try a new feature by adding the flags e.g --new-template to server CLI, that would start serving the a new feature. IDK if that is a be big enough change to more it to a separate discussion though.

I will try to answer all questions about data-model (1-5) in a simple doc a bit later.

I'm waiting on this to finalize the page.

got it, will do that today ASAP.

One more thing, do you think it would make sense to include a script for static page generation here as well?

@bzz
Copy link
Owner

bzz commented Oct 23, 2020

I will try to answer all questions about data-model (1-5) in a simple doc a bit later.

I'm waiting on this to finalize the page.

got it, will do that today ASAP.

Done at #39

@bzz
Copy link
Owner

bzz commented Oct 23, 2020

New fixtures forth, read and unread messages were added in #40 and merged to master.

@heruka-urgyen
Copy link
Collaborator Author

New fixtures forth, read and unread messages were added in #40 and merged to master.

On master, I'm getting

> go run main.go -test
flag provided but not defined: -test

Am I missing something?

@bzz
Copy link
Owner

bzz commented Oct 23, 2020

New fixtures forth, read and unread messages were added in #40 and merged to master.

On master, I'm getting

> go run main.go -test
flag provided but not defined: -test

Am I missing something?

No, you are not. Sorry for the confusion, but as mentioned elsewhere, CLI does not yet support the -test, only the server does. At least until this todo is addressed (which is also a message fetching part of the #20).

The only way to test CLI is to configure and subscribe for some alerts from scholar.

Hopefully going to add it soon.

@heruka-urgyen
Copy link
Collaborator Author

@heruka-urgyen heruka-urgyen force-pushed the frontend branch 2 times, most recently from d542511 to 2f48232 Compare October 23, 2020 18:19
@bzz
Copy link
Owner

bzz commented Oct 23, 2020

I tried this branch on the real data and got a blank page with that in the console

Screenshot 2020-10-23 at 23 39 35

and server logs

go run ./cmd/server
2020/10/23 23:37:18 starting the web server at http://localhost:8080
2020/10/23 23:37:25 GET - /?json
2020/10/23 23:37:25 Redirecting to /login as three is no session

the reason is that GET request did not have access token and was answered with the redirect to /login

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /login
Date: Fri, 23 Oct 2020 21:38:35 GMT
Content-Length: 29

@heruka-urgyen
Copy link
Collaborator Author

The error in console is due to cors not being enabled for normal mode. Ideally, cors only makes sense in dev mode, because normal mode should bundle front-end code, eliminating the need for cors. However, if you see a use case for dev mode with real data, then sure, we need cors.

That said, we still need to redirect to login screen. I will trigger it automatically when session cookie is missing.

@bzz
Copy link
Owner

bzz commented Oct 24, 2020

The error in console is due to cors not being enabled for normal mode.

Right now, CORS is always enabled, but only for the JSON responses. The error is due to the 304 response not having CORS.

After #43 \w CORS enabled for all the routs the error is different now
Screenshot 2020-10-24 at 11 51 59

That said, we still need to redirect to login screen. I will trigger it automatically when session cookie is missing.

sounds good 👍 feel free to merge #43 as you see fit

@heruka-urgyen
Copy link
Collaborator Author

heruka-urgyen commented Oct 24, 2020

EDIT: It's more confusing actually. It redirects in private window and in my old session it throws an error as below

I haven't figured out how to make this work. When I pass "Access-Control-Allow-Origin" header, I'm getting

Cross-Origin Request Blocked: 
The Same Origin Policy disallows reading the remote resource at http://localhost:8080/?json. 
(Reason: CORS request external redirect not allowed)

(Some information about it)

What we could do, is disable backend redirect and instead make an authorization routine. I think I will need to query the server for client_id, and then trigger redirect.

@bzz
Copy link
Owner

bzz commented Oct 24, 2020

I see.

make an authorization routine

Isn't that what /login is for, in a way?

I guess, Instead of re-direct (302) to /login I can send back 200 with a JSON containing the external URL user needs to be sent to 🤔

Most probably the simplest way instead of refactoring existing logic on the backend - start creating new endpoints for that under /json/*

query the server for client_id

I'm not 100% sure what do you mean by that as the server is stateless.

@bzz
Copy link
Owner

bzz commented Oct 26, 2020

#44 introduces proper /json/* endpoints that can be used for the frontend auth flow.

Now any request without a token will result in

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Date: Mon, 26 Oct 2020 17:39:55 GMT
Content-Length: 354

{"error":{"status":"Unauthorized","Redirect":"https://accounts.google.com/o/oauth2/auth?...."}}

@heruka-urgyen
Copy link
Collaborator Author

Seems like rebase went a little wrong :/

@heruka-urgyen
Copy link
Collaborator Author

heruka-urgyen commented Oct 27, 2020

We have a problem with oauth. Currently, the redirect_uri is localhost:8080, which should be fine in production mode, when code is bundled. In development mode, however, we have to then manually go to localhost:9000, which isn't a big deal, but still differs from expected behavior. Perhaps, we could trigger another redirect from server (to :9000) in development mode?

@bzz
Copy link
Owner

bzz commented Oct 27, 2020

Perhaps, we could trigger another redirect from server (to :9000) in development mode?

Add a server-side re-direct to the backed from what route to what route?

We could add -dev and ask google to re-direct the user to :9090 instead, if that would help 🤔

@bzz
Copy link
Owner

bzz commented Oct 27, 2020

Seems like rebase went a little wrong :/

yes, it seems like when re-writing a history - a number of commits from master were re-written as well.

You need to remove those from this branch and rebase it on the latest master again.

@heruka-urgyen
Copy link
Collaborator Author

Add a server-side re-direct to the backed from what route to what route?

We could add -dev and ask google to re-direct the user to :9090 instead, if that would help thinking

Here's what's happening step by step.

  1. Client sends get / post to server
  2. Server returns 401 unauthorized
  3. Client redirects to google
  4. Google redirects to localhost:8080
  5. After that, manually navigating to localhost:9000 shows 401 and triggers same loop again

auth

You can try it, I just committed this

@bzz
Copy link
Owner

bzz commented Oct 27, 2020

With #46

go run ./cmd/server -cors -dev

redirects to :9000 after successful auth.

+ italicize author names
+ show number of refs for each paper
+ show ref author's names in refs
@bzz
Copy link
Owner

bzz commented Nov 6, 2020

Works like a charm, after #32 was merged.
Is there anything left here, before merging?

May be adding /static/ prefix to work with the #47

@heruka-urgyen
Copy link
Collaborator Author

heruka-urgyen commented Nov 6, 2020

May be adding /static/ prefix to work with the #47

Should work as npm run build -- --env baseUrl=/json

+ npm run prod --env baseUrl=xyz/abc
+ this will set the base url for REST endpoints
@heruka-urgyen heruka-urgyen merged commit f968286 into master Nov 6, 2020
@heruka-urgyen heruka-urgyen deleted the frontend branch November 6, 2020 23:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants