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

React 0.12 will remove the pragma. #19

Closed
BerkeleyTrue opened this issue Oct 17, 2014 · 12 comments
Closed

React 0.12 will remove the pragma. #19

BerkeleyTrue opened this issue Oct 17, 2014 · 12 comments

Comments

@BerkeleyTrue
Copy link

React 0.12 will remove the jsx pragma.

react 0.12-rc

I think possible solutions to detecting a jsx file without the jsx ext should be discussed.

One possible solution is to grep the doc for React. I am not the greatest at vimscript so I don't know how feasible this would be.

@ruyadorno
Copy link

👍

@ruyadorno
Copy link

I gave it a try on my own fork: https://github.com/ruyadorno/vim-jsx/tree/detect-filetype

I'm not 100% sure about the implementation but I got it working for my projects :)

@BerkeleyTrue
Copy link
Author

Are you just using jsx ext?

@ruyadorno
Copy link

yeah... is it bad? 😊 like very, very bad?

now that you mentioned I just saw that in your first message you did stated without the jsx ext. what are the problems in doing this naive implementation?

@BerkeleyTrue
Copy link
Author

I had a bunch of compatibility problems using jsx ext and my vim setup. If I can't figure out how to get this to work I will add a custom pragma.

@jkimbo
Copy link

jkimbo commented Oct 31, 2014

The way I got around this was to set let g:jsx_pragma_required = 0. Means its run on every javascript file but it seems to work so far.

@BerkeleyTrue
Copy link
Author

@jkimbo Good idea. I will try that.

@mxw
Copy link
Owner

mxw commented Nov 3, 2014

Presumably grepping for React may not work for files that, e.g., just contain functions which return React components, without defining any? The extension support has been added with the most recent commit.

@BerkeleyTrue
Copy link
Author

Is there an harm in having it always on?

@mxw
Copy link
Owner

mxw commented Nov 3, 2014

@BerkeleyTrue—The syntax regexes are fairly simple and will highlight the latter portion of, e.g., if (w<u) { as a JSX tag, which breaks highlighting for the rest of the document. I think it's reasonable to "force" a better whitespace style for JSX files for vim-jsx users, but I don't want that to be the default for users who sometimes deal with grungy whitespaceless JS codebases.

It's easy enough to always-enable vim-jsx by just adding let g:jsx_ext_required = 0 somewhere in your ~/.vimrc or elsewhere in your runtimepath.

@lencioni
Copy link
Contributor

Here's what I am using for jsx detection (borrowed mostly from @wincent): https://github.com/lencioni/dotfiles/blob/891897374e096b3f250840f3283033f2b7d8310a/.vim/ftdetect/jsx.vim

Similarly to the ftdetect that comes with vim-jsx, it assumes that .js.jsx files (could just as easily be .jsx) are jsx. However, there are some key differences:

  1. For .js and .html files, it searches through the beginning of the file for React. to determine if it uses jsx.
  2. For .js files that use React, it sets the filetype to javascript.jsx which allows you to have jsx-specific configuration while inheriting javascript configuration.
  3. For .html files that use React, it sets the filetype to html.jsx.
  4. If the filename ends in _spec, Spec, or -test, it sets the filetype to javascript.jasmine.jsx, which allows you to have jasmine-specific configuration as well.

What do you think about using this approach? It would allow you to change all of the files in this package from javascript.vim to jsx.vim, which would be more nicely scoped.

@BerkeleyTrue
Copy link
Author

Facebook is recommending .jsx and are using it internally. I am going to spend a couple of hours getting my vimrc working right with jsx. facebook/react#832

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

No branches or pull requests

5 participants