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

HTML Wrapper: bind react router history to links under innerHTML #244

Closed
wants to merge 1 commit into from

Conversation

cusspvz
Copy link

@cusspvz cusspvz commented Apr 15, 2016

If you place ordinary links on your .html file they will load trough
the browser history, which takes an initial loading of the entire page.

I've rewritten the HTML on ES2015 and added the feature of binding
clicks on ordinary links to the react router's history.

Tested and working.

If you place ordinary links on your .html file they will load trough
the browser history, which takes an initial loading of the entire page.

I've rewritten the HTML on ES2015 and added the feature of binding
clicks on ordinary links to the react router's history.

Tested and working.
@KyleAMathews
Copy link
Contributor

Hey @cusspvz, thanks for the PR. We've discussed this issue in the past in #93 and decided that it wasn't something we wanted built into Gatsby core as there's valid reasons for wanting a page refresh e.g. you're messing with page styles on one page. I'd love though to see something like this as an NPM module that could be easily added to a Gatsby site. If you write something like that, add a mention of it to the README here in the FAQ.

@cusspvz
Copy link
Author

cusspvz commented Apr 22, 2016

Where can I find documentation on how to make a pluggable module on gatsby?

@cusspvz
Copy link
Author

cusspvz commented Apr 22, 2016

  • Wrappers are being picked up just from ./wrappers/*, should we create a pre-defined npm module prefix as well? Such as gatsby-wrapper-*
  • staticFileTypes is static and cannot be modded? It should be exposed as well to allow injection of external wrappers such as ejs, ect, jade and so on (believe me, this would make it different and would bump its popularity).

@KyleAMathews
Copy link
Contributor

I've actually been working on designing the plugin API :-) Right now Gatsby is fairly monolithic and hard to modify but that will be changing soon. I'd love to hear your feedback once I've posted the issue!

I'd love to let you create plugins for ejs, ect, jade, wrappers, etc.

@rileyjshaw
Copy link
Contributor

@KyleAMathews a more pluggable API would be great! Off the top of my head, an optional parsers folder could override Gatsby's parsers for filetypes that are included — similar to how wrappers works.

For this specific link-replacement change, React Markdown may be better-suited than markdown-it. For that reason, it's probably best to send the raw markdown string into parsers/md.js.

@KyleAMathews
Copy link
Contributor

@rileyjshaw the plugin api should come out in the next alpha release of Gatsby! If you haven't checked out the writeup on the graphql work — that's coming out too in the next alpha — I've been basing my markdown processing work on http://remark.js.org/ as it provides a Markdown AST that makes it really easy to make modifications but with the graphql data layer, you can easily add plugins to support other markdown parsers.

I'm also working on a way to compile markdown to a react component (several clients want this) so that will be supported as well.

@rileyjshaw
Copy link
Contributor

@KyleAMathews 😻 exciting, thanks! Great writeup on the GraphQL data layer, I hadn't seen that.

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.

3 participants