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

Issue with the order of options #49

Closed
blittle opened this issue Jan 26, 2018 · 7 comments
Closed

Issue with the order of options #49

blittle opened this issue Jan 26, 2018 · 7 comments
Assignees
Labels

Comments

@blittle
Copy link

blittle commented Jan 26, 2018

First of all, thank you for your work on this project. Especially given that react-codemirror appears abandoned.

I encountered an odd bug with the lint plugin. Specifically, I discovered that the order of options passed the CodeMirror component matter.

For example:

<CodeMirror options={{
  lint: true,
  gutters: ["CodeMirror-lint-markers"]  
}} />

Will not render lint warnings in the gutter. It works by instead doing:

<CodeMirror options={{
  gutters: ["CodeMirror-lint-markers"],
  lint: true
}} />

I think the problem is two parts:

  1. react-codemirror2 iterates in setting options: https://github.com/scniro/react-codemirror2/blob/master/src/index.tsx#L296
  2. Codemirror immediately invokes the constructor of the LintState when the lint: true option is set. In that constructor, the hasGutter flag is defined as false because the gutters option has yet to be set: https://github.com/codemirror/CodeMirror/blob/master/addon/lint/lint.js#L62

So, we could either try and get CodeMirror to not immediately invoke the constructor, or we could some how change react-codemirror2 to not iterate in setting options, but do it all at once.

Note: this is not a problem of react-codemirror, but only in react-codemirror2

@scniro
Copy link
Owner

scniro commented Jan 26, 2018

@blittle Thank you so much for opening this up and doing most of the research on your own. This is totally valid, and now that I think about it, I'm surprised setting the options iteratively didn't jump out to me as a red flag earlier. I can definitely get a fix into this soon and will keep you posted with my findings. I hope your workaround is okay for now.

@scniro scniro added the bug label Jan 26, 2018
@scniro scniro self-assigned this Jan 26, 2018
@blittle
Copy link
Author

blittle commented Jan 26, 2018

@scniro thank you for the quick response and your maintenance of this project. If I can be of help in building a fix, please let me know!

@scniro
Copy link
Owner

scniro commented Jan 27, 2018

@blittle So I dug into this a little bit more and believe to have pinned the issue. Actually, I found a strikingly similar issue in a now older AnguarJS 1.x directive wrapper that suffered the same issue seen here. What really jumped out was the codemirror author's comment.

If you want to stick to the setOption approach, at least follow the order of the properties in CodeMirror.defaults by doing a for/in loop over that, rather than depending on the object passed by the user. But it'd be better to build up an option object and pass that to the CodeMirror constructor, since CodeMirror can initialize more efficiently if it knows its full configuration upfront.

Since this wrapper is responding to new options passed via props, I think it's best to keep this iterative approach, since we do indeed want to keep the living instance, but doing so merged with the defaults so the order is always correct, no matter what the user passed.

I have this working locally, and plan to ship it with a 4.x release that had various other chores that were lower priority. As soon as I get my changelog written these will be live, so expect to be able to pull the new package this weekend.

scniro added a commit that referenced this issue Jan 28, 2018
@scniro
Copy link
Owner

scniro commented Jan 28, 2018

@blittle This should be fixed with the 4.0.0 release. If you find the time, could you try to reproduce this error with the order of options in the example as when you first posted this? If all looks good I'll close this out.

@blittle
Copy link
Author

blittle commented Jan 29, 2018 via email

@scniro
Copy link
Owner

scniro commented Feb 2, 2018

@blittle Hey any good news on this one? Looking to close it out soon 😸

@blittle
Copy link
Author

blittle commented Feb 2, 2018 via email

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

No branches or pull requests

2 participants