-
Notifications
You must be signed in to change notification settings - Fork 394
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
Docs SSR #834
Docs SSR #834
Conversation
@iAdramelk I think we are fine w/o either of those for now. In case of network failure it will show an error, right? if smooth scroll is not something hard to do - let's do this please, resolve the conflicts - merge/rebase |
Smooth scrolling should have been easy, but wasn't for some reason. System method to do it using Will text for network failure, but it should work. |
yep, sounds like a strange problem to have ... let's not waste time on this - I think it's totally ok w/o smooth anchors if it works fine across different browsers let's merge |
if (res.status !== 200) { | ||
return { | ||
errorCode: res.status | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just return a 504 here. Or some other generic status code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe with an error message including the res.status
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not leave actual code there? It can help us debug things. Do you see some case there showing real code can be bad?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this fetch is for the internal document? Not some sort of gateway? In that case I think returning actual code makes sense indeed. Although a generic code with a message explaining what happened (and the source error code) would make ever more sense I think. This is merged and works though, so whatevs.
pages/doc.js
Outdated
} catch (e) { | ||
return { | ||
errorCode: 404 | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. what kind of errors can fetch
throw that would get caught here? Can't easily tell from https://github.com/matthew-andrews/isomorphic-fetch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fetch
is a promise. It can return either Promise.resolve
or Promise.reject
. Resolve is the thing that we will receive in the most cases. It have response
object and we can check it's status
field. But if, for example, your internet connection is lost, the browser will not resolve it, but will instead throw error which we are catching there.
Try to set connection to offline in Network tab of Developers Tools and then try to click on the internal link, it will throw error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm OK but why 404? I see this is changed though... Will re-ask.
UPDATE: See #834 (review)
Sorry, can you briefly explained how this is achieved by this PR? Sounds great but I'm not easily getting it from browsing through the file changes and clicking around the nav inside https://dvc-org-pr-834.herokuapp.com/doc seems completely dynamic to me. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few comments/questions. PTAL.
Basically how it worked before:
What changed:
|
This comment has been minimized.
This comment has been minimized.
@iAdramelk LGTM! Anything else to be fixed or ready to merge? Have you checked it on different devices/browsers? |
This comment has been minimized.
This comment has been minimized.
Fixed error on mobile. Tested in Edge. We can merge it. |
Thanks for the explanation Alex. Very interesting. And sorry took me a long time to get back to this haha. I see it's merged. I may have a couple questions left... |
} catch { | ||
window.location.reload() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't this go into an infinite loop? (Blocked by the browser probably.)
Continuation of #834 (review)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If page loads again then yes, but this error usually means that the internet is down and we will just show browser error page there. Maybe there are cases then this error is thrown in other situations, but I don't know about them.
UPDATE: See longer explanation in #834 (comment).
TODOS:- [ ] Add smooth scroll for anchors- [ ] Add preloaders on page change (not sure if we want them now)