Open cs opened 4 years ago
If you are open to the idea, I would be happy to look into it myself OR to provide a small bounty for someone already familiar with the codebase.
@cs Thank you for sharing the idea. I don't have the know-how regarding the Grammarly plugin so can't really tell if it can be implemented easily.
If you would like give implementing it a try, go ahead. Some things you'd like to know:
site.config
from Jekyll propagates into just the sidebar and the header.MarkdownEditor
and its styles are in the mdeditor.scss
partial.It would be dope if the Grammarly plugin can be tested using the existing set up for the frontend layer.
@ashmaroli Thank you for the quick response. The way Grammarly's Google Chrome extension works is actually quite simple:
It scans the page for visible <textarea>
s and inserts the Grammarly icon on the elements' bottom-right corner. That's it. It already works for the title <textarea>
within Jekyll Admin, because in this case, the <textarea>
is visible.
Regarding the propagation of site.config
: Maybe my second idea (part of the UI) is actually simpler then since it requires fewer changes. The whole switching mechanism could be fully encapsulated in the MarkdownEditor
component.
Maybe my second idea (part of the UI) is actually simpler then since it requires fewer changes.
I agree in principle. But then it would confuse users who don't use the Grammarly plugin as why there's a toggle to a simple <textarea>
without the whistles of SimpleMDE.. :thinking:
Maybe my second idea (part of the UI) is actually simpler then since it requires fewer changes.
I agree in principle. But then it would confuse users who don't use the Grammarly plugin as why there's a toggle to a simple
<textarea>
without the whistles of SimpleMDE.
That's, of course, true. Hmm.
Here's a proposal for the _config.yml
changes:
jekyll_admin:
hidden_links: [posts]
markdown_editor: default # => using SimpleMDE
or
jekyll_admin:
hidden_links: [posts]
markdown_editor: textarea # => using plain <textarea>, supports Grammarly
Would that be acceptable?
As far as the textarea itself goes, I think https://github.com/andreypopp/react-textarea-autosize would work nicely. I've already confirmed that Grammarly works with this component.
I think https://github.com/andreypopp/react-textarea-autosize would work nicely
This is exactly what Jekyll Admin is using to render the textarea to input title and path attributes..
Work in progress. So far, I managed to expose to new config option, so that it is always available in the MarkdownEditor
component. The code is slightly repetitive.
@ashmaroli I'm not a React guy, so please don't hesitate to point out if I'm doing something wrong.
Woah! this was an issue ticket hours ago.. how did it transform into a pull request?!?! :open_mouth:
Couple of tips on the work so far (mainly to be DRY, reduce the diff and ease review..)
package.json
and yarn.lock
. You should be able to continue work with existing modules (even if you're on Node v12 and above) as long as you don't run yarn
or npm install
.src/utils/helpers.js
and import that helper into the view-components.@ashmaroli, I integrated your suggestions. Maybe it makes more sense to change the new configuration option to be a boolean? I don't see the need to plan for a third editor option?
Hopefully, I get to the meat of this later today and build the switch between SimpleMDE and react-textarea-autosize
.
I don't see the need to plan for a third editor option
At the moment I don't see the need either..
Regarding the commit you just pushed (ref: logic in sidebar), I'd prefer that you do not include changes outside the scope of this PR.
I don't see the need to plan for a third editor option
At the moment I don't see the need either..
Regarding the commit you just pushed (ref: logic in sidebar), I'd prefer that you do not include changes outside the scope of this PR.
Too many good intentions... fair enough, I remove these changes again. Whatever it takes to get Grammarly support is fine with me ;)
I will test this a bit to make sure everything works as expected, but at least for the Grammarly use-case, this should be enough. This has been easier than expected ...
Let me know once you've finished working on this completely. Since I don't intend to install the grammarly plugin on my browser, I have no sane way to confirm the final render. You could leave a screenshot to give an idea to users that visit this thread in the future.
Regarding styling, I think just using the field
classname for the textarea should give you the base styles used in the metadata fields. Then your custom styles can be adjusted accordingly..
In certain situations, for instance, when you want to use the Google Chrome plugin from Grammarly.com, the use of editors based on
contenteditable
is not supported. Therefore, I'd like Jekyll Admin to offer the possibility to fall back to plain<textarea>
s. I see two ways to implement this:Make it a configuration option (i.e.,
_config.yml
) where the user can pick between SimpleMDE and<textarea>
. SimpleMDE could be the default so that existing users wouldn't even notice the change unless they mess with their configuration.Make this part of the UI, so that users can click some sort of button/icon to toggle between SimpleMDE and
<textarea>
.My preference would be
1.
. What do you think?