search

Pocket / curation-tools-frontend

DEPRECATED
Mozilla Public License 2.0
10 stars 53 forks source link

define urls and implement a router #94

Closed jpetto closed 3 years ago

jpetto commented 3 years ago

based on the figma comps, determine appropriate/meaningful URLs for the application and implement those URLs in the app.

the views/components rendered for these URLs can be just simple placeholder text for now. the purpose of this ticket is only to get the router implemented and URLs decided upon.

nina-py commented 3 years ago

From what I could find, the two popular routing packages for React are React Router and Reach Router. About 18 months ago they merged back together and React Router is the one where all new development will take place: https://reacttraining.com/blog/reach-react-router-future/. So it seems like React Router is the way to go.

npm install react-router-dom @types/react-router-dom
nina-py commented 3 years ago

Here is the list of URLs I have come up with:

Entry/exit pages:

Prospects

Prospects - actions on an existing story

Prospects - actions on a new URL

Prospects - Edit & Approve form actions

New Tab

New Tab - actions

Please let me know if I've got most of these right and I can start implementing them. For now, I'll just update dependencies on the branch for this issue. Also, would ALL pages need to be implemented with placeholder components, or should this issue perhaps be kept open and URLs ticked off in batches as the actual pages are implemented (my preferred way, hence checkboxes in markdown... :smile: )?

jpetto commented 3 years ago

Here is the list of URLs I have come up with:

Entry/exit pages:

* [ ]   Login Page: `/`

User authentication will be handled outside of this application, so for now I think the root URL can simply provide a link to the home page for each feed. These feeds will be retrieved dynamically from the API (details forthcoming).

* [ ]  Home Page:  `/:feed/`, i.e. `/en-US/`, `/de-DE/`. With ability to switch between feeds for users with the right permissions. What would the home page show? Some aggregated data perhaps? Or default and redirect to, for example, Prospects?

I think for now, this URL can simply redirect to /:feed/prospects/.

* [ ]  Log Out Page: `/logout/`

* **Comment**: This route is not required because we do not have a logout page.

Prospects

* [ ]  Default page: `/:feed/prospects/`. Pagination? I.e. `/:feed/prospects/:page-number/`.

* **Comment**: For pagination, use query parameters instead i.e. `/:feed/prospects?page=:page-number`

* [ ]  Snoozed tab: `/:feed/prospects/snoozed/`. Pagination here and on other subpages?

Yeah, I think pagination is a good idea here and on the other sub pages.

* [ ]  Approved tab:  `/:feed/prospects/approved/`.

* [ ]  Rejected tab:  `/:feed/prospects/rejected/`.

Prospects - actions on an existing story

* [ ]  Reject: `/:feed/prospects/article/reject/:article-id/`.

* [ ]  Snooze: `/:feed/prospects/article/snooze/:article-id/`.

Just to call out that we should require a specific HTTP action (probably POST?) for these two URLs.

* [ ]  Edit & Approve: `/:feed/prospects/article/edit-and-approve/:article-id/`.

Prospects - actions on a new URL

* [ ]  Add story:  `/:feed/prospects/article/add/`.

* [ ]  Show Edit & Approve form (follows on from "Add story" page):  `/:feed/prospects/article/edit-and-approve/`.

I'm confused as to what this corresponds to. Can you provide details on this route? Or is this just a button linking to the URL above?

Prospects - Edit & Approve form actions

* [ ]  Reject - this appears straightforward and should be the same as Reject action above, assuming that by this stage the new article has an ID in the system: `/:feed/prospects/article/reject/:article-id/`.

* [ ]  Snooze - This, in effect, should be "Save and Snooze", not just snooze, or else all the changes to the article will be lost. URL?

I think you're right on here - the button should read "Save and Snooze". As for the URL, I'm curious to see what you think. It seems silly to create a special edit-and-snooze URL for this case. I'm wondering if edit-and-approve is too specific of a URL. Perhaps an /edit URL that can also accept a status (approve, snooze, reject) is more general purpose?

* [ ]  Approve - again, straightforward if article has an ID: `/:feed/prospects/article/approve/:article-id/`.

New Tab

* [ ]  List of live articles by default: `/:feed/new-tab/`. Or would it be better to use `/:feed/new-tab/live/`? Pagination? I.e., `:feed/new-tab/page-number`.

I think including live is a good call. Let's do pagination on these two URLs.

* [ ]  Scheduled tab: `/:feed/new-tab/scheduled/`. Pagination?

New Tab - actions

* [ ]  Remove article - `/:feed/new-tab/article/:article-id/remove`

* [ ]  Edit article - `/:feed/new-tab/article/:article-id/edit`. Will this lead to the same Edit & Approve form used elsewhere? Or another form with more/fewer fields or a different set of available actions underneath? The mobile prospects screen shows Reject/Snooze/Approve on the Live tab while the desktop version shows Remove/Edit.

I believe we can use the same Edit & Approve form, which will allow someone to edit the article as well as change its status. The "Approve" button in this case may be better off with a label of "Save" if the status is already approved.

On this note, the Edit & Approve form should probably have a label denoting the current status of the article.

Please let me know if I've got most of these right and I can start implementing them. For now, I'll just update dependencies on the branch for this issue. Also, would ALL pages need to be implemented with placeholder components, or should this issue perhaps be kept open and URLs ticked off in batches as the actual pages are implemented (my preferred way, hence checkboxes in markdown... 😄 )?

Feel free to work this issue however you see fit. 😄

nina-py commented 3 years ago

Thank you @jpetto, it all makes sense. I will post an updated URL list later today and resume working on this branch.

A couple of things: if authentication will be handled outside of this app, why do we have a login form?

I'm confused as to what this corresponds to. Can you provide details on this route? Or is this just a button linking to the URL above?

If you look at the second row of desktop-sized Figma comps, there is an "Add Story" screen followed by "Edit & Approve". It looks like curators can add an article to the database and have the API parse it for them, saving the thumbnail image, etc. Both forms have a "Cancel" button in the top right corner, suggesting that this data can be discarded at any point.

So if /:feed/prospects/article/add/ saves the article after parsing it, a separate URL to edit it /:feed/prospects/article/edit-and-approve/ is not needed: /:feed/prospects/article/edit-and-approve/:article-id/ can be used instead. If the article is only saved after it's edited first and assigned a status, there should be a path to this form that is different from the regular workflow when you edit an existing article.

jpetto commented 3 years ago

okay, i think i follow you. yes, Edit & Approve will always operate on an existing article, so the URL will always have an :article-id present.

nina-py commented 3 years ago

Please keep this issue open so that I can easily find it and tick off pages as they are implemented. I'll post the updated page list shortly.