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

Add serve --one-page option to live preview a single page #475

Merged
merged 2 commits into from Dec 23, 2018
Merged

Add serve --one-page option to live preview a single page #475

merged 2 commits into from Dec 23, 2018

Conversation

Xenonym
Copy link
Contributor

@Xenonym Xenonym commented Dec 18, 2018

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Resolves #441.

What is the rationale for this request?
Authors may want to preview only a single page in their website, that also includes changes from other parts of the website (eg. changes from an included page). We can allow them the option of just rendering that one page itself without having to render the entire website on each change, speeding up preview times.

What changes did you make? (Give an overview)
I added a --one-page <file> option to the CLI that allows an author to specify a single page to preview. Site() and Site.js#generatePages() was then modified to only render that page when a page has been specified via --one-page. Finally, live-server was configured to open the specified page directly.

Testing instructions:

  1. Choose a specific page in a Markbind website to serve with --one-page eg. markbind serve --one-page userGuide/components.md.
  2. Note that only _site/userGuide/components.html and its required files are rendered.
  3. Note that the browser opens to that specific page.
  4. Note that changes to the site are detected and rendered, including those not in components.md.

Copy link
Member

@yamgent yamgent left a comment

Choose a reason for hiding this comment

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

Need you to resolve conflict in your PR; there has been a recent change in the project's folder structure, so lib/Site.js -> src/Site.js

index.js Outdated
if (options.onePage) {
// replace slashes for paths on Windows
// eslint-disable-next-line no-param-reassign
options.onePage = options.onePage.replace('\\', '/');
Copy link
Member

Choose a reason for hiding this comment

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

On Windows nodejs supports both / and \. Is there any particular reason why this was done?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On PowerShell and cmd.exe, paths are normally written with \. However, we internally normalise all paths to use / as the separator (including when storing the value of pages.src in siteData.json). Since the value passed to --one-path is directly used to look up which page to serve, I believe it would be better to allow users to enter \ as the path separator when specifying the file path to --one-page, which would be less confusing than if an error was emitted when \ is used.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, please use path.normalize(p) during file comparison then. We don't use the regex technique in our codebase, instead we use path.normalize().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replacing options.onePage.replace('\\', '/') with path.normalize() actually breaks the lookup. This is because the default site.json uses paths with /. While we use path. functions for filesystem operations, page.src is still written with / into siteData.json.

path.normalize() on a Windows system converts all path seperators to \, which breaks the lookup since pages are located by page.src, which needs / to match.

Copy link
Contributor

Choose a reason for hiding this comment

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

How about path.posix.normalize?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@acjh thank you for the suggestion! Unfortunately, path.posix.normalize on Windows-style paths does nothing:

> path.posix.normalize('userGuide\\userQuickStart.md')
'userGuide\\userQuickStart.md'

This is because, according to the Node.js docs for path.normalize, only / is considered a path separator under POSIX, and thus \ will not be replaced.

(The phrasing is clearer in the original PR for this section nodejs/node#12700, but was subsequently changed.)

Copy link
Contributor

Choose a reason for hiding this comment

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

Understood. Let's add a function in utils similar to ensure-posix-path's ensurePosix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@acjh Sure, that will work!

index.js Outdated Show resolved Hide resolved
docs/userGuide/developingASite.md Show resolved Hide resolved
lib/Site.js Outdated Show resolved Hide resolved
@damithc
Copy link
Contributor

damithc commented Dec 20, 2018

Good job tackling this feature request @Xenonym
Is the rendering faster when this feature is used on big sites such as https://github.com/se-edu/se-book ?

@Xenonym
Copy link
Contributor Author

Xenonym commented Dec 20, 2018

No problem @damithc!

Initial rendering times of se-edu/se-book averaged over 5 runs:
markbind serve: 59.872s
markbind serve --one-page gitAndGithub/index.md: 14.115s

On average, there should be ~4x speedup during the initial render.
Changes made during the live preview when using serve --one-page will pretty much be instantaneous compared to just using serve.

@damithc
Copy link
Contributor

damithc commented Dec 20, 2018

On average, there should be ~4x speedup during the initial render.
Changes made during the live preview when using serve --one-page will pretty much be instantaneous compared to just using serve.

Nice. Looking forward to using this feature. 👍

@yamgent yamgent merged commit 660b924 into MarkBind:master Dec 23, 2018
@yamgent yamgent added this to the v1.14.3 milestone Dec 23, 2018
@Xenonym Xenonym deleted the serve-one-page branch December 30, 2018 09:57
@damithc
Copy link
Contributor

damithc commented Jan 2, 2019

This feature is saving me a lot of time when updating a massive site such as the CS2103 website :-) 💯

@Xenonym
Copy link
Contributor Author

Xenonym commented Jan 2, 2019

Glad to hear it @damithc! :D

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.

Allow live previewing a single page in force-rebuild mode
4 participants