Complete Gatsby MaterialUI installation plus 'Add Feeds' page wireframing

[Silvyre]

Issue This PR Addresses

Addresses #730 - Pick a React component library as our base UI toolkit
Resolves #725 - Prototype the Add Feed view in React

Type of Change

• Bugfix: Change which fixes an issue
• New Feature: Change which adds functionality
• Documentation Update: Change which improves documentation
• UI: Change which improves UI

Description

• Addresses Pick a React component library as our base UI toolkit #730 by completing our frontend's installation of MaterialUI with gatsby-theme-material-ui. The remainder of the MaterialUI installation was previously done by @miggs125.
  • (It is worth noting that, by default, the installation of gatsby-theme-material-ui enforces some global styling changes to the frontend, e.g. changing the default font to Roboto. This default styling can be overwritten, if we'd prefer.)
  • (AFAIK, we're keeping Pick a React component library as our base UI toolkit #730 open for the purposes of discussion.)
• Resolves Prototype the Add Feed view in React #725 by adding a 'My Feeds' Gatsby Page (accessed via /myfeeds) wireframed with MaterialUI components.
  • This is just a wireframe; none of the implied functionality has been implemented (and I suggest that we finalize the component's design before putting major work into its implementation).

Preview of 'My Feeds' component:

• It is worth noting that this component currently ends up being rendered quite small due to styling enforced by src/frontend/src/pages/index.css:
  

  telescope/src/frontend/src/pages/index.css

  Lines 9 to 13 in 9dc8564

  	html {
  	/*assuming browser font default is 16px*/
  	font-size: 62.5%;
  	/*translates to 10px -> root font*/
  	}

Checklist

• Quality: This PR builds and passes our npm test and works locally
• Tests: This PR includes thorough tests or an explanation of why it does not
• Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not (if applicable)
• Documentation: This PR includes updated/added documentation to user exposed functionality or configuration variables are added/changed or an explanation of why it does not(if applicable)

[Grommers00]

Do we want to keep styles located in the react component? Is there a way to store this in the css file that should be located with the page to keep with the current format of the front end?

[Silvyre]

Yes, it is technically possible to replace this instance of makeStyles with pure CSS, i.e.

.MuiContainer-root {
  position: relative;
  top: 16px;
}

.MuiIconButton-root {
  padding: 3px 0 3px 0;
}

Relying more on MaterialUI's styling solutions may become more useful in the future if/when we want to incorporate more MUI functionalities, such as customized theming.

However, since I'm still pretty new to MUI, I'd like to defer to @miggs125 and @humphd regarding whether it would be better, in this case, to embrace or move away from MUI styling solutions.

[Grommers00]

I agree - not sure if having each react component contain our materialUI solutions or if we should grab it from a separate page that would house all the material UI.

I do think we should keep anything CSS related outside of the functionality part. Perhaps we could import it and have a different file such as myFeedsCss.js? (or materials not sure what to call this file)

This would allow the CSS developers to quickly locate where the CSS is that would need to be changed, and not get them stuck in reading everything within a component?

Thoughts @humphd ?

[humphd]

Depending on the outcome of #730, it looks like we might use MUI as a base. If we do, then I think moving toward the MUI style approach is nice, because it takes less work to translate what their examples in the docs to to what we'll have. Doing CSS-in-JS this way is kind of nice.

I think do whatever you want in this PR, and we'll change it to match #730. I'll add a note about this topic there.

[Grommers00]

Looks good,

We can switch CSS later if we notice an issue or decide to go another route.

[Grommers00]

Can we also add another option for the main page to navigate here :D. Perhaps in the nav bar?

[Silvyre]

Can we also add another option for the main page to navigate here :D. Perhaps in the nav bar?

In my opinion, a higher priority would be to enable route guarding for this component. However, both of these functionalities would be more appropriately handled within separate issues.

[Grommers00]

Can we also add another option for the main page to navigate here :D. Perhaps in the nav bar?

In my opinion, a higher priority would be better to enable route guarding for this component. However, both of these functionalities would be more appropriately handled within separate issues.

Agreed, However nav bar is rendered in a way that we only want this page shown in logged in mode anyways.

As I don't know if we are adding in protected routes this way..or necessarily how as we don't have a state manager given that it's a simple application having the link only show up when logged in the navbar I think could suffice?

[Silvyre]

Can we also add another option for the main page to navigate here :D. Perhaps in the nav bar?

In my opinion, a higher priority would be better to enable route guarding for this component. However, both of these functionalities would be more appropriately handled within separate issues.

Agreed, However nav bar is rendered in a way that we only want this page shown in logged in mode anyways.

As I don't know if we are adding in protected routes this way..or necessarily how as we don't have a state manager given that it's a simple application having the link only show up when logged in the navbar I think could suffice?

That's a good point, especially coupled with the fact that there is talk of designing Telescope as a single page site.

[cindyorangis]

This looks good. CSS can be filed as another issue or if it needs to be discussed some more, it can be done in the frontend discussion. You can bug @agarcia-caicedo about the navbar in #588