Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring Site Creation and Additions #157

Merged
merged 12 commits into from Mar 7, 2019

Conversation

@LaRuaNa
Copy link
Contributor

LaRuaNa commented Mar 1, 2019

Hi all,

happily we improved our codebase in last few days quite a lot! Though all the problems I run into while working on bugs led me to prepare this big refactoring PR. Please take a look and let me know if there is any room for improvements or if you have any concerns about new structure.

PS: Sorry about big PR I needed to approve my approach in most of the cases. After having all the code together I didn’t split them up again. :|

Closes:
#23
#106
#24

@LaRuaNa LaRuaNa requested a review from ollelauribostrom Mar 1, 2019
@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 1, 2019

Hey @ollelauribostrom since this PR touches a lot of places of your first refactoring attempt would be lovely if you can get around to look over :]

@ollelauribostrom
Copy link
Contributor

ollelauribostrom commented Mar 1, 2019

/gcbrun

@ollelauribostrom
Copy link
Contributor

ollelauribostrom commented Mar 1, 2019

@LaRuaNa At a first glance, this looks really awesome 🎉 Will look over it more closely when I have some free time tomorrow 🙂

@sagirk
sagirk approved these changes Mar 1, 2019
Copy link
Member

sagirk left a comment

Amazing job, @LaRuaNa! LGTM! 🎉

A few observations below.

gatsby-node.js Outdated Show resolved Hide resolved
gatsby-node.js Outdated Show resolved Hide resolved
gatsby-node.js Outdated Show resolved Hide resolved
src/components/navigation-section.tsx Outdated Show resolved Hide resolved
@ahmadawais
Copy link
Member

ahmadawais commented Mar 1, 2019

/gcbrun

@ahmadawais
Copy link
Member

ahmadawais commented Mar 1, 2019

All of this looks really good. Just one concern. This is a HUGE PR which I generally discourage. Lots going on in there and many decisions. Do you think we can split it?

@ahmadawais
Copy link
Member

ahmadawais commented Mar 1, 2019

@MylesBorins doesn't seem to be working on my end. The build I mean. Want to test it.

@MylesBorins
Copy link
Member

MylesBorins commented Mar 1, 2019

@ahmadawais there is something wrong with the build. The resources uploaded but there is no index.html

Perhaps a bug from the refactor? Can you test locally

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 2, 2019

@MylesBorins Seems to be a problem with redirects I'm on it.

Copy link
Contributor

ollelauribostrom left a comment

Really nice job, this is much needed and make stuff a lot more solid 👍 A few minor stuff pointed out below. You could run yarn run tslint -p ./tsconfig.json to find some minor nits (some pointed out by @sagirk below).


return (
<Layout title={title} description={description}>
<Hero title={title} />
<Navigation sections={navigationSections} />

This comment has been minimized.

Copy link
@ollelauribostrom

ollelauribostrom Mar 2, 2019

Contributor

This removes the navigation from the 404 page, I don't think that's what we want? 🙂

This comment has been minimized.

Copy link
@LaRuaNa

LaRuaNa Mar 5, 2019

Author Contributor

I'd take care of that after refactoring the navigation if we wanna keep this. (see #169) I don't see FWIW to run a graphql request for 404 page and additionally we would need to implement same logic we have in gatsby-nodeto provide the navigation data.

This comment has been minimized.

Copy link
@ahmadawais

ahmadawais Mar 5, 2019

Member

Navigation felt like a good idea on the 404 page.

This comment has been minimized.

Copy link
@sagirk

sagirk Mar 6, 2019

Member

+1 to retaining the navigation.

The 404 page content being boxed into the navigation area looks weird design-wise on larger screens (i.e., too much whitespace on the right).

image

This is caused due to the layout grid. As a hacky stopgap measure, adding an empty div in place of <Navigation> fixes it

-       <Navigation sections={navigationSections} />
+       <div />

image

On the other hand, if we don't keep the navigation, we need to tweak the text accordingly.

- The page you're trying to access does not exist. Go back to the Homepage or find what you're looking for in the menu.
+ The page you're trying to access does not exist. Go back to the Homepage.

However, this PR has been running for long. As suggested by @LaRuaNa, we can take care of these concerns on a follow-up PR.

test/components/pagination.test.tsx Outdated Show resolved Hide resolved
test/components/author-link.test.tsx Outdated Show resolved Hide resolved
src/components/navigation.tsx Show resolved Hide resolved
src/components/article.tsx Outdated Show resolved Hide resolved
@ollelauribostrom
Copy link
Contributor

ollelauribostrom commented Mar 2, 2019

Not sure if this is the intended behaviour but the navigation items in the first section are no longer marked as done when selecting an item in the second section. Looks like this:

skarmavbild 2019-03-02 kl 22 23 22

@sagirk
Copy link
Member

sagirk commented Mar 3, 2019

Seems to be a problem with redirects I'm on it.

Could it be because of this duplicate redirect?

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 3, 2019

The problem with redirect is that gcp doesn't care about redirects we've in our config. So we've 2 possible ways to solve that problem:

  • we add redirects to firebase.json
  • or we copy paste our logic for /index and /learn

I'd go for firebase option. Thoughts?
@MylesBorins I assume gcp cares about firebase config in PRs as well? So we can test the PR properly

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 3, 2019

Not sure if this is the intended behaviour but the navigation items in the first section are no longer marked as done when selecting an item in the second section. Looks like this:

Yep, since they're different sections it was my interpretation. Though we can ofc change it. Any concrete thoughts / suggestions?

@ollelauribostrom
Copy link
Contributor

ollelauribostrom commented Mar 3, 2019

In my opinion, it would make sense to mark any previous section as done as well. Let's merge this with the current behaviour, we can open a separate issue to discuss this further 🙂

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

@MylesBorins
Copy link
Member

MylesBorins commented Mar 5, 2019

@LaRuaNa there is nothing special GCP or Firebase related for staging... it is just a CDN bucket and the output from gatsby. I've tested between this branch and master and it appears there is a regression between master and the static output of this branch... as /index.html is being creating on master and not with this branch.

Bisecting rn to see if I can narrow down which change made this happen

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

@MylesBorins This line generates /index.html in master. I tried to fix it with redirects so that we redirect / to /learn but it seems like redirects don’t work out of the box. So we need to create redirects on serverside. Another quite practical way to handle this problem without messing up with serverside redirects would be we generate a single page for / with the content from introduction-to-nodejs. I'll give it a try to see how that affects build.

@MylesBorins
Copy link
Member

MylesBorins commented Mar 5, 2019

@LaRuaNa we definitely can rely on serverside behavior for redirects but that will require us to introduce more complicated infrastructure for staging. I'm personally fond of how elegant it is that we can currently direct all traffic to index.html and it "just works". If you can replicate that behavior that would be great.

FWIW, do we need to mount everything right now on /learn? It seems premature, and something we could easily do at learn.nodejs.dev in the future without or something similar. Until we have additional material we are hosting on this site do you think there is a reason to force that path?

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

@LaRuaNa we definitely can rely on serverside behavior for redirects but that will require us to introduce more complicated infrastructure for staging. I'm personally fond of how elegant it is that we can currently direct all traffic to index.html and it "just works". If you can replicate that behavior that would be great.

@MylesBorins Totally agree with you on elegant infrastructure point. That's reasonable. I'll change the PR a bit so that it "just works" with staging. :] I wasn't aware of the opportunity i just mentioned.

FWIW, do we need to mount everything right now on /learn? It seems premature, and something we could easily do at learn.nodejs.dev in the future without or something similar. Until we have additional material we are hosting on this site do you think there is a reason to force that path?

Quite frankly, that's a good point I didn't question yet. /learn it's just a prefix we use rn and can be easily removed. I'll change that as well to see how it impacts our codebase, shouldn't be a big deal. Just to make it clear that isn't what causes staging problem we have.

@LaRuaNa LaRuaNa force-pushed the LaRuaNa:refactor-site-creation branch from e34f476 to 9b0e891 Mar 5, 2019
@LaRuaNa LaRuaNa requested review from sagirk and ollelauribostrom Mar 5, 2019
@ahmadawais
Copy link
Member

ahmadawais commented Mar 5, 2019

I agree with @MylesBorins assessment on the learn/ slug. Removing it would make things easier for staging infra to work. I vote for removing it altogether. Adding it later in the form of a redirect or subdomain won't be an issue.

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

PTAL @ollelauribostrom @sagirk

@MylesBorins Can you please check staging

Copy link
Contributor

ollelauribostrom left a comment

LGTM, lets get this merged and we can adress some of the above discussions later on. Would be great if you could run yarn run tslint -p ./tsconfig.json and fix a few lint issues before merging this 🙂

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

Argh! I messed up my tslint config while working on prettier integration. That explains why they slipped my attention :]

@MylesBorins
Copy link
Member

MylesBorins commented Mar 5, 2019

@ahmadawais
Copy link
Member

ahmadawais commented Mar 5, 2019

@MylesBorins we can handle that with a redirect file, not sure how it works with GCP, but for Netlify it's just a simple netlify.toml file with old to new link mapping with 301 status. Without breaking any links.

@LaRuaNa
Copy link
Contributor Author

LaRuaNa commented Mar 5, 2019

@MylesBorins I googled before I removed the rewrites. There are 2-3 links shared with /learn route. If that's really all, I think that's a bearable pain if they break. But ofc I can also rewrite /learn to / to have fallback.

@sagirk
sagirk approved these changes Mar 6, 2019
Copy link
Member

sagirk left a comment

Looks good, @LaRuaNa! 🎉

A few observations below (mostly nits; fixes are tiny, but no worries if we want to take care of these on a follow-up PR).


return (
<Layout title={title} description={description}>
<Hero title={title} />
<Navigation sections={navigationSections} />

This comment has been minimized.

Copy link
@sagirk

sagirk Mar 6, 2019

Member

+1 to retaining the navigation.

The 404 page content being boxed into the navigation area looks weird design-wise on larger screens (i.e., too much whitespace on the right).

image

This is caused due to the layout grid. As a hacky stopgap measure, adding an empty div in place of <Navigation> fixes it

-       <Navigation sections={navigationSections} />
+       <div />

image

On the other hand, if we don't keep the navigation, we need to tweak the text accordingly.

- The page you're trying to access does not exist. Go back to the Homepage or find what you're looking for in the menu.
+ The page you're trying to access does not exist. Go back to the Homepage.

However, this PR has been running for long. As suggested by @LaRuaNa, we can take care of these concerns on a follow-up PR.

parent: { relativePath },
} = node;

let previousNodeData = undefined;

This comment has been minimized.

Copy link
@sagirk

sagirk Mar 6, 2019

Member

nit: Can we initialize it with null instead of undefined. That way, the intent is more explicit — assigning a deliberate non-value.

let previousNodeData = null; //null - deliberate non-value

Or if we need it to be initialized with undefined, we can just leave it uninitialized.

let previousNodeData; //undefined - unintentional value

+same throughout.

test/components/pagination.test.tsx Show resolved Hide resolved
@sagirk
Copy link
Member

sagirk commented Mar 7, 2019

This PR has been open for a while now. And, #172, #168, #166 and #97 are, in fact, waiting on it to be landed.

Since it looks good for the most part, I'm merging it in its current state. We can spin up #157 (comment), #157 (comment) and #157 (comment) into new issues later.

@sagirk sagirk merged commit e7574b8 into nodejs:master Mar 7, 2019
1 check passed
1 check passed
Travis CI - Pull Request Build Passed
Details
@sagirk
Copy link
Member

sagirk commented Mar 7, 2019

Since it looks good for the most part, I'm merging it in its current state. We can spin up #157 (comment), #157 (comment) and #157 (comment) into new issues later.

#157 (comment): Issue #176
#157 (comment): Issue #177
#157 (comment): PR #178

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.